[Home]

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-0600Date Closed:2009-08-23 09:38:32
Priority:MajorRegression?No
Status:Closed/CompleteComponents: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