Summary:	ASTERISK-04308: # transfers on SIP UA do not work after call is placed on hold
Reporter:	David Gomillion (dgomil)	Labels:
Date Opened:	2005-05-31 20:04:15	Date Closed:	2005-08-17 10:48:55
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) bad_transfer_with_moh.txt ( 1) trace_good.txt
Description:	Completely reproducable, running Asterisk Stable, latest CVS. When users press # on a Polycom IP 300 or 600 to transfer a call, it works.  If they place the call on hold, pick it back up, and press #, the caller hears the DTMF. This is major because transfers are a normal part of PBX functionality, and the Transfer key does not work due to bug ASTERISK-4273.  Once a call has been placed on hold, there is no way to reliably transfer the call. ****** ADDITIONAL INFORMATION ****** SoundPoint IP phones, models 300 and 600, running 1.4.1 software.
Comments:	By: David Gomillion (dgomil) 2005-05-31 20:05:38 Don't know why this was reclassified as Code Formatting... hmmm. By: Brian West (bkw918) 2005-05-31 22:01:32 why wouldn't you just use the native sip transfer?   /b By: David Gomillion (dgomil) 2005-06-01 08:54:46 Please educate me.   As I said, the Transfer button on the phone doesn't work, as the channel becomes a zombie.  But that issue is being addressed in the bug number referenced above. This ticket is trying to address the only other way I know of to transfer calls not working, which is using the # key. How can I access the "native sip transfer" other than the two ways described above, neither of which work reliably? By: Brian West (bkw918) 2005-06-01 10:11:55 Well on my 7960's transfer button and my sipura (flash key) both work without fail.  If its not working on your polycom we need to get a sip trace and figure out what is up.  And the Zombie thing is normal it happens when the channel is masqueraded during the transfer. Check channel.c ast_do_masquerade snprintf(zombn, sizeof(zombn), "%s<ZOMBIE>", orig); /b By: Michael Jerris (mikej) 2005-06-19 09:02:47 Polycom bug reportedly fixed in new polycom firmware.  Where do we stand on the # transfer after hold issue? By: drmac (drmac) 2005-06-19 15:00:54 bkw918, we have all 7960's too and are plagued with the problem described in ASTERISK-4273 (which uses the built-in transfer key on the 79XX series).  this bug (4418) also sounds familiar to what some of the office workers have reported. yes, i understand that sip debugs are necessary but when (in my case) the problem happens purly random, its hard to get a debug without running debug all day long. By: Michael Jerris (mikej) 2005-06-19 15:24:55 do the steps to reproduce (hold, off hold, # transfer) have the same result?  If so, then you could  provide a debug, if not, it is potentially a different bug. By: Brian West (bkw918) 2005-06-19 20:38:04 I have never once had an issue on my 7960's or sipura's using the sip transfers. /b By: Kevin P. Fleming (kpfleming) 2005-07-05 22:28:28 Russell, let's try to duplicate this one tomorrow with our Polycom phones. If we can't then we have to write this one off as 'unreproduceable', otherwise we can fix it. By: Russell Bryant (russell) 2005-07-06 10:46:52 I have tried to reproduce this using a Polycom 300 and a Cisco 7960, with 1.0 and HEAD and have been unable to do so.  If we don't get some debug of this problem happening soon, we will have to close it out as unable to reproduce. By: drmac (drmac) 2005-07-06 15:13:23 Finally. Finally got a trace of this. Incomming Zap call. Rings 3033. 3033 answers and talks with Zap. 3033 places Zap on hold; waits a few seconds. Zap hears MoH 3033 resumes call. Zap and 3033 talk. 3033 presses 'More' then 'Transfr' (3033 is a Cisco 7960 SIP 7.4) Zap hears MoH. 3033 dial 3069. 3069 answers. 3033 and 3069 talk. 3033 presses 'Transfr' to complete the transfer. 3069 hears MoH. Zap hears 3069 saying "Why am I hearing MoH?" 3069 cannot hear anything Zap is saying due to hearing MoH. Zap can hear everything 3069 is saying. This is not 100% reproducable. We reprocuded it about 7 times in the last 10 attempts. By: dbruce (dbruce) 2005-07-07 22:45:31 It appears, from the SIP debug posted and from testing i've done, that the bug is with the Cisco SIP firmware (tested with v6.03 and v7.04). The Cisco sends an INVITE with c=IN IP4 0.0.0.0 to the transfer target, effectively placing the target phone on hold, before it sends the REFER to complete the transfer. So, after the REFER is processed, the target channel will will need to be taken off hold... I haven't yet been able to accomplish this... By: Michael Jerris (mikej) 2005-07-31 18:47:32 any update on this.  Has anybody reported the bug to cisco?  Is there a way to get around this on the asterisk side without creating a compatability problem with other phones? By: Michael Jerris (mikej) 2005-07-31 18:48:26 oej, can you verify that this is an issue with cisco being non rfc compliant please. By: Olle Johansson (oej) 2005-08-01 01:38:01 In this case I believe that Asterisk is the culprit. I don't see why you can't transfer a call that was previously put on hold. Normally a REFER results in a new INVITE/200 OK with a brand new SDP, especially when you have a REPLACES option in the refer-to header. Asterisk does not handle SIP transfers very well, which is something I've been trying to solve for some time. I am marking this as related to 3710 since it's an attended transfer and we'll wait until I have something working there. Right now, I'm waiting for feedback on Kevin on some complex issues. By: dbruce (dbruce) 2005-08-02 01:34:37 I just tried the latest CVS STABLE.... The Cisco problem (transfer destination placed on hold) no longer occurs, and builting transfer on the Polycom also works as expected (regardless of the call being placed on hold or not). I suspect that the issue can be closed as already resolved. dgomil and drmac: Please upgrade to latest CVS STABLE and let us know if the problem still occurs. By: Michael Jerris (mikej) 2005-08-03 13:30:59 This issue appears to be resolved.  Please re-open if ou continue to have the issue with most recent stable or head.  Thanaks By: drmac (drmac) 2005-08-10 16:42:16 I guess since the problem persists you need another trace? I will try and get one asap. By: Michael Jerris (mikej) 2005-08-17 08:44:25 drmac, any update on that trace? By: drmac (drmac) 2005-08-17 10:42:54 hmm..must have been the combo of asterisk update and Cisco 7.5 update cause I can't reproduce it anymore. Tried about 10 times. I've told everyone to go back to using the 'Transf' button on the phones to see if I can't get it to happen somewhere. I guess if no one else has reported, then u can close. By: Michael Jerris (mikej) 2005-08-17 10:48:55 reopen if you have this issue again.