Summary: | ASTERISK-13115: Blind transfer does not work upgrade to 1.4.23-rc1 | ||
Reporter: | Francesco Romano (francesco_r) | Labels: | |
Date Opened: | 2008-11-24 18:12:14.000-0600 | Date Closed: | 2009-08-23 09:38:32 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Channels/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 13962.patch ( 1) full.txt | |
Description: | Blind transfer does not work after i upgraded to 1.4.23-rc1. The same with 1.4 r158629. I have tested sip to sip and misdn to sip, with dtmf and native sip transfer but is the same. I have attached a full debug of a transfer but there are no error or notice in the log. I tried to put the chan_sip.c of 1.4.22 in the source of 1.4.23 and recompile but the problem remains, so i think that is not related to chan_sip. | ||
Comments: | By: Terry Wilson (twilson) 2008-11-25 13:30:38.000-0600 I just tried a 1.4.23-rc1 on my machine and both SIP blind transfer (polycom) and builtin blind transfer (#) worked fine for me. We're going to need a little bit more information about your setup to reproduce this issue. If you could lab up the simplest set of config files that reproduce the problem and post them here, it would help a lot. By: Francesco Romano (francesco_r) 2008-11-25 14:23:04.000-0600 I have tried in two different machines both with FreePBX gui (version 2.3 and latest 2.5.1). So perhaps is something related with macro depth or agi. Now i can't upload the configs but i think you can test in AsteriskNow 1.5. By: Julian Yap (jyap) 2008-12-02 14:51:01.000-0600 I've seen this exact same issue on 1.4.23-rc2. By: Francesco Romano (francesco_r) 2008-12-14 10:29:10.000-0600 I have tried 1.4 r163785 and this bug it's still here, any news? thank you By: Russell Bryant (russell) 2008-12-15 16:32:14.000-0600 Leif, could you take a look and see if you can reproduce this? If transfer is broken, that would be a blocker for 1.4.23 By: Mark Michelson (mmichelson) 2008-12-16 10:59:27.000-0600 I gave this a shot in 1.4.23-rc1. Blind transfer worked for me, but there is something a bit disconcerting about my test. In my test, Alice calls Bob. Bob then uses a blind transfer to transfer Alice to Carol. Bob presses the feature code for a blind transfer. Bob dials Carol's extension. This is where things get a bit fishy. Once this happens, the h extension is run on Alice's channel. It is not until after this processing completes that the new call is placed to Carol. I added things like a Wait(3) to my h extension and found that it added an uncomfortable delay to things. This suggests to me that depending on the content of the h extension, it may contribute negatively to the success of an attempted blind transfer. I would suggest to jyap and francesco_r as a test to temporarily remove the h extension from your dialplan and attempt a blind transfer. If it succeeds, then it is likely that something being run in your h extension is to blame for the blind transfer failing. If I am correct about this, please let us know and upload the contents of your h extension so that we can possibly figure out where the problem lies. By: Francesco Romano (francesco_r) 2008-12-16 12:11:12.000-0600 You are right putnopvut. In FreePBX there is a context for the transfers (TRANSFER_CONTEXT = from-internal-xfer): [from-internal-xfer] include => parkedcalls include => from-internal-custom include => ext-fax include => ext-local-confirm include => findmefollow-ringallv2 include => from-internal-additional exten => s,1,Macro(hangupcall) exten => h,1,Macro(hangupcall) If i remove exten => h,1,Macro(hangupcall) the transfers work again. This is [macro-hangupcall] exten => s,1,ResetCDR(w) exten => s,n,NoCDR() By: Mark Michelson (mmichelson) 2008-12-16 13:22:48.000-0600 It took a little bit of work, but I have now reproduced the problem. First of all, the problem only seems to manifest if the h extension calls a macro. If you transplant the code from the macro directly into the h extension, then all is well. Second, I saw that from your debug output, the Hangup application is being called in the macro called from the h extension. It is this that is causing a non-zero return value to occur and therefore causing things to go wrong. By: Mark Michelson (mmichelson) 2008-12-16 13:39:31.000-0600 I've uploaded 13962.patch. It's a simple one-liner that fixed the problem locally. I'd like it more though if someone more familiar with the macro application could comment on whether the fix is valid, though. By: Tilghman Lesher (tilghman) 2008-12-16 14:31:42.000-0600 Issue ASTERISK-12632 contains a better fix that is unlikely to cause a crash, which is what this patch will do. By: Mark Michelson (mmichelson) 2008-12-16 14:31:51.000-0600 It has been pointed out to me that the patch on issue ASTERISK-12632 should fix this problem and is much safer than what I have posted here. Please give the patch attached there a try and report results from testing it. Thanks! By: Mark Michelson (mmichelson) 2008-12-16 14:46:00.000-0600 I did some testing and it appears that the patch on issue ASTERISK-12632 does not actually fix the issue here. I am removing the duplicate relationship from this issue. By: Mark Michelson (mmichelson) 2008-12-16 15:35:41.000-0600 Corydon-76 uploaded a new patch onto ASTERISK-12632, and I can verify that it fixed this issue for me in my test setup. Sorry to keep directing you around, but if you could test the latest patch on issue ASTERISK-12632 and report if it fixes the problem for you, it would be much appreciated. By: Francesco Romano (francesco_r) 2008-12-17 06:30:23.000-0600 I have applied the latest patch from ASTERISK-12632 and now blind transfers work again. Thank you. By: Digium Subversion (svnbot) 2008-12-17 15:14:54.000-0600 Repository: asterisk Revision: 165317 U branches/1.4/apps/app_macro.c ------------------------------------------------------------------------ r165317 | tilghman | 2008-12-17 15:14:53 -0600 (Wed, 17 Dec 2008) | 4 lines Reverse the fix from issue ASTERISK-6019 and add proper handling for that issue. (Closes issue ASTERISK-13115, closes issue ASTERISK-12632) Fixed by myself (license 14) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=165317 By: Digium Subversion (svnbot) 2008-12-17 15:18:53.000-0600 Repository: asterisk Revision: 165319 _U trunk/ U trunk/apps/app_macro.c ------------------------------------------------------------------------ r165319 | tilghman | 2008-12-17 15:18:52 -0600 (Wed, 17 Dec 2008) | 11 lines Merged revisions 165317 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r165317 | tilghman | 2008-12-17 15:14:37 -0600 (Wed, 17 Dec 2008) | 4 lines Reverse the fix from issue ASTERISK-6019 and add proper handling for that issue. (Closes issue ASTERISK-13115, closes issue ASTERISK-12632) Fixed by myself (license 14) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=165319 By: Digium Subversion (svnbot) 2008-12-17 15:21:15.000-0600 Repository: asterisk Revision: 165321 _U branches/1.6.0/ U branches/1.6.0/apps/app_macro.c ------------------------------------------------------------------------ r165321 | tilghman | 2008-12-17 15:21:14 -0600 (Wed, 17 Dec 2008) | 18 lines Merged revisions 165319 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r165319 | tilghman | 2008-12-17 15:18:57 -0600 (Wed, 17 Dec 2008) | 11 lines Merged revisions 165317 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r165317 | tilghman | 2008-12-17 15:14:37 -0600 (Wed, 17 Dec 2008) | 4 lines Reverse the fix from issue ASTERISK-6019 and add proper handling for that issue. (Closes issue ASTERISK-13115, closes issue ASTERISK-12632) Fixed by myself (license 14) ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=165321 By: Digium Subversion (svnbot) 2008-12-17 15:22:34.000-0600 Repository: asterisk Revision: 165323 _U branches/1.6.1/ U branches/1.6.1/apps/app_macro.c ------------------------------------------------------------------------ r165323 | tilghman | 2008-12-17 15:22:33 -0600 (Wed, 17 Dec 2008) | 18 lines Merged revisions 165319 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r165319 | tilghman | 2008-12-17 15:18:57 -0600 (Wed, 17 Dec 2008) | 11 lines Merged revisions 165317 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r165317 | tilghman | 2008-12-17 15:14:37 -0600 (Wed, 17 Dec 2008) | 4 lines Reverse the fix from issue ASTERISK-6019 and add proper handling for that issue. (Closes issue ASTERISK-13115, closes issue ASTERISK-12632) Fixed by myself (license 14) ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=165323 By: Digium Subversion (svnbot) 2009-02-11 14:54:19.000-0600 Repository: asterisk Revision: 174885 U branches/1.4/apps/app_macro.c U branches/1.4/main/pbx.c ------------------------------------------------------------------------ r174885 | tilghman | 2009-02-11 14:54:19 -0600 (Wed, 11 Feb 2009) | 13 lines Restore a behavior that was recently changed, when we fixed issue ASTERISK-13115 and issue ASTERISK-12632 (related to issue ASTERISK-6019). When a hangup occurs during a Macro execution in earlier 1.4, the h extension would execute within the Macro context, whereas it was always supposed to execute only within the main context (where Macro was called). So this fix checks for an "h" extension in the deepest macro context where a hangup occurred; if it exists, that "h" extension executes, otherwise the main context "h" is executed. (closes issue ASTERISK-13256) Reported by: wetwired Patches: 20090210__bug14122.diff.txt uploaded by Corydon76 (license 14) Tested by: andrew ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174885 By: Digium Subversion (svnbot) 2009-02-11 14:55:47.000-0600 Repository: asterisk Revision: 174886 _U trunk/ ------------------------------------------------------------------------ r174886 | tilghman | 2009-02-11 14:55:47 -0600 (Wed, 11 Feb 2009) | 19 lines Blocked revisions 174885 via svnmerge ........ r174885 | tilghman | 2009-02-11 14:54:18 -0600 (Wed, 11 Feb 2009) | 13 lines Restore a behavior that was recently changed, when we fixed issue ASTERISK-13115 and issue ASTERISK-12632 (related to issue ASTERISK-6019). When a hangup occurs during a Macro execution in earlier 1.4, the h extension would execute within the Macro context, whereas it was always supposed to execute only within the main context (where Macro was called). So this fix checks for an "h" extension in the deepest macro context where a hangup occurred; if it exists, that "h" extension executes, otherwise the main context "h" is executed. (closes issue ASTERISK-13256) Reported by: wetwired Patches: 20090210__bug14122.diff.txt uploaded by Corydon76 (license 14) Tested by: andrew ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174886 |