Summary:	ASTERISK-06146: [patch] parked calls can't come completely out of the parking lot!
Reporter:	Steve Murphy (murf)	Labels:
Date Opened:	2006-01-20 09:00:36.000-0600	Date Closed:	2006-05-03 16:39:41
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) patch.parking
Description:	If I park an incoming call (on my system, with # 700), it announces the parking lot stall (usually 701 here), and caller gets MOH as usual. When I pick up an extension, and dial 701, I am "half" connected to the caller... The caller continues to get MOH, but I can hear them. They hear nothing but Music On Hold. If no-one picks up 701, the original extension rings, and when you pick up, all is well again. both parties can hear and speak to each other.
Comments:	By: Olle Johansson (oej) 2006-01-20 14:42:53.000-0600 you have to provide much more information. What technologies/channel drivers are used? How are you parking? If SIP, add protocol debug. By: Steve Murphy (murf) 2006-01-20 18:48:48.000-0600 More info: just svn updated the zaptel dir; installed, rmmod'd and then re-modprobed the wctdm, wcfxo, and zaptel mods. Same behavior. Incoming call comes in on zap fxo card (from phone lines), and the two other extensions involved are both on a tdm 4-port card. zap interface. I park with # 700, and pick up by dialing the 701 given by the parking operation. By: Steve Murphy (murf) 2006-01-20 19:07:27.000-0600 Oh, and maybe it's my imagination, but the sound made on the extension that picks up the parked call, seems to create gaps in the MOH heard by the incoming caller. And did I really hear sudden noises made on the picked up side, transmitted very quietly in the background on the caller's side? By: Steve Murphy (murf) 2006-01-29 21:16:32.000-0600 Been keeping the project area up-to-date, tried to see if something might have spontaneously healed the broken "parking" problem. Nope! Is the fact that parking is broke on head, worth anyone's attention? Here's from verbose output on the console (my comments with //) // Incoming call on FXO card, Zap/1, rings TDM extensions Zap/3 and Zap/5:    -- Zap/5-1 answered Zap/1-1    -- Hungup 'Zap/3-1'    -- Stopped music on hold on Zap/1-1 // Then, Zap/5 hits # and then, 700 (the parking number)    -- Started music on hold, class 'random', on channel 'Zap/1-1'    -- Playing 'pbx-transfer' (language 'en')    -- Stopped music on hold on Zap/1-1    -- Started music on hold, class 'random', on channel 'Zap/1-1'  == Parked Zap/1-1 on 701. Will timeout back to extension [homeline] 1, 3 in 60 seconds    -- Added extension '701' priority 1 to parkedcalls    -- Playing 'digits/7' (language 'en')    -- Playing 'digits/0' (language 'en')    -- Playing 'digits/1' (language 'en')    -- Hungup 'Zap/5-1' // Zap/5 got "congestion", and is hung up...    -- Hungup 'Zap/5-1' // I'd have to investigate to see if this is a factor-- Zap/5 was dialed via a macro...  == Spawn extension (macro-std-priv-exten, s, 7) exited KEEPALIVE in macro 'std-priv-exten' on 'Zap/1-1'  == Spawn extension (homeline, 1, 3) exited KEEPALIVE on 'Zap/1-1' // Extension Zap/3 picks up and dials "701"... all extensions via a macro...    -- Starting simple switch on 'Zap/3-1'    -- Executing ParkedCall("Zap/3-1", "701") in new stack    -- Channel Zap/3-1 connected to parked call 701 // At this point, Zap/1 can hear only music. Zap/3 can hear everything Zap/1 is // saying, but Zap/1 hears nothing from Zap/3, just the MOH. Zap/3 can hear a // faint trace of the MOH... maybe an echo issue, or something. A minute or so // of making noises and other experiments either way ensues, and then the // lines are hung up. // Zap/6 is the phone calling out via VOIP, that created the incoming call to // Zap/1. At this point, it hangs, and the incoming call is dead...  == Spawn extension (macro-ciddial2, s, 10) exited non-zero on 'Zap/6-1' in macro 'ciddial2'  == Spawn extension (workext, 97545675, 1) exited non-zero on 'Zap/6-1'    -- Hungup 'Zap/6-1'    -- Stopped music on hold on Zap/1-1 // Why didn't it stop the MOH on Zap/1 when they were connected via unparking?    -- Hungup 'Zap/1-1' // And the picking-up extension hangs up then, too...  == Spawn extension (homeext, 701, 1) exited non-zero on 'Zap/3-1'    -- Hungup 'Zap/3-1' Looking at the code in res_features.c, I see that a path does indeed in the code where the MOH is not shut off, if no "courtesytone" is specified in the config file for parking!!#@$*#. By default, the config file has those directives commented out!! So, I see that parking is broken for all those folks that don't specify a "courtesytone" and at least use Zap interfaces, perhaps others will be broken also... By: Steve Murphy (murf) 2006-01-29 21:48:20.000-0600 OK, I guessed at what should be there, added the code, and tried it out. Parking works like normal now. Whoever added the "courtesytone" stuff forgot to code up what to do if none is specified, which by the way, is the DEFAULT! I've attached the patch. I suggest all who use the parking feature and haven't specified any "courtesytone", might wish to apply it to their head version, or have problems. I think this deserves some KARMA!!! ;^) By: Steve Murphy (murf) 2006-02-28 16:51:45.000-0600 Checking back on the status of this bug after a month... evidently, this is not a high-priority bug, as I don't see anyone agreeing/disagreeing/etc, but it's still there, as best I can tell... By: wephyte (wephyte) 2006-04-02 06:51:04 I had the same problem with unparking calls. The patch adding the moh stopping with no courtesytone fixed the problem for me. By: Serge Vecher (serge-v) 2006-05-03 15:36:28 marking confirmed as there is a report of attached patch fixing the issue. By: BJ Weschke (bweschke) 2006-05-03 16:39:40 Committed to /trunk. Thanks!