Summary:	ASTERISK-13472: SIP attended transfer cannot re-transfer a caller after a call forward no answer rule returns call to original extension
Reporter:	David Brillert (aragon)	Labels:
Date Opened:	2009-01-28 10:04:58.000-0600	Date Closed:	2009-02-02 09:36:38.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) *1then*2debug.txt ( 1) *2then*2.txt ( 2) attended_sip_transfer_fail_cli.txt ( 3) attended_sip_transfer_fail_ngrep.txt ( 4) blind_sip_transfer_success_cli.txt ( 5) blind_sip_transfer_sucess_ngrep.txt
Description:	Here is setup: 6011 will call 6002 6002 will transfer to 6010 6010 has forward no answer rule to 6002 6002 must answer and try to transfer caller to another extension using SIP attended transfer (Polycom phone firmware 3.1.1 Result: after timeout to 6010 caller is sent to vm6002 instead of transferred back to 6002 (core show channels does not show 6002 on call after transfer completion. Note: The only workaround for this is to use SIP blind transfer. Native *1 Asterisk transfer will follow the call forward no answer rule on 6010 to transfer to 6002, but once the caller is returned to 6002 then 6002 cannot use the blind transfer feature again ****** ADDITIONAL INFORMATION ****** I'll upload the following: Asterisk CLI and ngrep capture using Polycom blind SIP transfer (which will provide success) Asterisk CLI and ngrep SIP capture using Polycom attended SIP transfer (which will provide failure)
Comments:	By: Terry Wilson (twilson) 2009-01-28 18:55:34.000-0600 This sounds like the Dial() to 6010 has a timeout value shorter than the amount of time that 6010 has set to consider it a "no answer" so the dialplan continues on to voicemail.  My gut reaction is that this isn't a bug.  I haven't looked at the attached files, yet, so I'll try to look at them a little later if you conclude that I am wrong. By: David Brillert (aragon) 2009-01-28 20:18:00.000-0600 This ticket is definitely related to http://bugs.digium.com/view.php?id=14274 otherwiseguy has posted a patch there and you can see test results there. By: David Brillert (aragon) 2009-01-29 08:24:04.000-0600 If anyone else is following I have requested 14274 to be closed so we can follow up here. By: Terry Wilson (twilson) 2009-01-29 09:38:01.000-0600 I'm not in the office, yet, but will try to lab something up to reproduce when I can.  BTW, the -Wbyline option to ngrep is your friend!  :-)  Also, for something this involved having a wireshark capture would be nice so I could get a graphical view of what is going on. By: Terry Wilson (twilson) 2009-01-29 10:59:49.000-0600 What this amounts to is the polycom calling itself, which anytime I have ever tried to do results in the polycom hanging up on itself. For the case where it goes to voicemail when it shouldn't, that is almost certainly the Dial() timeout being less than the amount of time that the polycom is set for detecting a no answer.  The ngrep output confirms this becuase there is no 302 from the Polycom, there is a CANCEL sent by Asterisk,which is what should happen.  Either make the Dial timeout longer, or scroll down and set the number of rings for a call forward no answer something less than what it is (the default I think is 10 rings). For the case where the call is in fact 302 redirected back to the caller, the phone will have 1 call up to the original caller, one call up for the consultative transfer, then will be receiving yet another call from asterisk for the redirect.  Often times the max calls per line is set to two, so the incoming call would fail. Neither of the above cases is a bug. The built-in blind transfer issue you refer to is a bug, but should be fixed by the patch in 14274. After I have a couple of other people look at it and test it out, I'll get that committed to the 1.4 branch and merged to the other branches. By: David Brillert (aragon) 2009-01-29 12:46:25.000-0600 otherwiseguy these ngreps and cli logs were posted to this ticket before the patch was available. I will have to provide you with new logs after I apply the patch and have time to test. I'll post SIP traces for you soon. By: David Brillert (aragon) 2009-01-29 13:40:27.000-0600 Also, Thanks for the info... Max calls is set to 8 and I will definitely increase the timeout and decrease the forward no answer timer for my tests My biggest concern over the patch is that the SIP blind transfer feature on Polycom phones is now completely broken after patching. Cheers By: Terry Wilson (twilson) 2009-01-29 13:48:40.000-0600 aragon: I don't see how that is possible.  I didn't touch any SIP transfer code whatsoever--and have done many SIP blind transfers since applying the patch (and I test with Polycom phones).  When you say "completely broken", what do you mean, exactly--what is the test case?  I'm confused, since I only touched the code for builtin features...  Something else has to have changed. By: David Brillert (aragon) 2009-01-29 14:53:50.000-0600 I'll run the blind transfer test on another server to confrim the behavior. But when I press transfer on the Polycom then press blind then enter extension number instead of transferring the call the phone calls itself. By: Terry Wilson (twilson) 2009-01-29 15:27:45.000-0600 This has to be a dialplan issue.  If it is a SIP blind transfer, the code calls a ast_async_goto to whatever extension it gets from the phone, which essentially means that we pass the info on to the dialplan.  If it is calling itself, then it would have to be the dialplan that is doing a Dial() to the phone.  It's always possible that I'm missing something or misinterpreting what you are saying, but it really should be completely impossible for the patch to make a difference in where a SIP blind transfer ends up. By: David Brillert (aragon) 2009-01-29 17:17:39.000-0600 I just got home and ran the test on my home system. I retested your patch on Polycom blind SIP transfers and they work fine. Sorry for the fog... I'll have a good look at my deployment server tomorrow and run a bunch of new tests. By: David Brillert (aragon) 2009-01-29 18:47:56.000-0600 otherwiseguy There are definitely some minor issues with the patch which I have no issues reproducing. Both issues are related to *1 or *2 transfers And use "silly" call forward no answer rule ;) I set up a call forward no answer rule on 220 to return transfers from 233 back to 220 after a few seconds User makes steps to reproduce 222 calls 233 233 *1220 220 does a call forward no answer to 233 233 answers then *2220 and caller is sent to voicemail It appears that the from extension after 233 answers and *2220 is rewritten to 220 and not 233 and loops to voicemail -- <SIP/233-09472ff8> Playing 'pbx-transfer' (language 'en')    -- Executing [220@commzilla-super:1] GotoIf("Local/220@commzilla-super-b94a,2", "0?3") in new stack  -- Executing [s@macro-commzilla-dial:1] NoOp("Local/220@commzilla-super-b94a,2", ""CALL TO LOCAL EXTENSION FROM 220()"") in new stack   This problem only exists when you transfer a call twice and use *1 during the first transfer attempt and *2 for the second transfer attempt. The test seems horribly improbable in any real world scenario but I can reproduce. As I said this is a minor problem and I don't give it much thought... If *1 is used repetitively to re-transfer caller then everything works fine. Things are a little more dicey with *2 because *2 cannot be re-used for multiple transfers on the original caller. User makes steps to reproduce 222 calls 233 233 *2220 220 does a call forward no answer to 233 233 answers then *2220 but gets no response from Asterisk Therefore *2 cannot be reused after the call forward no answer returns the caller ext 222, from 220, back to 233 I know the call forward no answer rule sounds silly but the customer demands that it work. I don't have any problems with SIP transfers with patch from 14274; only the issues stated above. By: David Brillert (aragon) 2009-01-29 19:07:46.000-0600 new ngreps attached (sorry no wireshark) By: David Brillert (aragon) 2009-01-30 19:02:37.000-0600 otherwiseguy A great job overall on the patch... I really appreciate the hard work and creativity. I opened another ticket for the *2 problem after applying the official patch. http://bugs.digium.com/view.php?id=14374 IMHO the segfaults and *2 issues there are a result of the patch. Therefore 14356 could probably be closed because the *2 and SIP transfer problems are not related. Besides I think if the *2 problem was fixed my outstanding issue in this bug would be fixed and the segfault problem in the other bug would also be fixed. By: David Brillert (aragon) 2009-01-30 19:28:27.000-0600 In fact I would say that revision 172517 fixed the reported issue here. By: Terry Wilson (twilson) 2009-02-02 09:36:38.000-0600 closing as per aragon