[Home]

Summary:ASTERISK-13929: Background application executed in post-Dial Application Macro terminates call
Reporter:Philippe Lindheimer (p_lindheimer)Labels:
Date Opened:2009-04-20 11:37:48Date Closed:2010-01-04 12:30:54.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20090420__bug14940.diff.txt
Description:Note: I have not had access to a system to further isolate and run some further tests yet but am providing some details of this issue as requested on #asterisk-bugs channel. As a result, I can not conclusively say if this is reproducible on a regular basis or if there are specific circumstances that must be presented to create the problem.

This dialplan is from FreePBX 2.5 base.

This issue appears to have started at about Asterisk 1.4.24 where it was first reported on the following two thread and then observed on a customer's system who was running SVN r177786:

http://freepbx.org/forum/freepbx/users/call-confirmation-fails-after-asterisk-1-4-24-upgrade
http://freepbx.org/forum/freepbx/users/confirm-calls-hang-up

The crux of the issue is that macro-confirm is executed as a post dial macro in a dialplan that would look something as follows:

Dial(Local/7365924@from-internal/n,30,M(confirm^^^222)tTwWr))

The macro-confirm code is as follows:

[macro-confirm]
include => macro-confirm-custom
exten => s,1,Set(LOOPCOUNT=0)
exten => s,n,Set(__MACRO_RESULT=ABORT)
exten => s,n,Set(MSG1=${IF($["foo${ARG1}" != "foo"]?${ARG1}:"incoming-call-1-accept-2-decline")})
exten => s,n(start),Background(${MSG1},m,${CHANNEL(language)},macro-confirm)
exten => s,n,Read(INPUT,,1,,,4)
exten => s,n,GotoIf($[${LEN(${INPUT})} > 0]?${INPUT},1:t,1)
exten => 1,1,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" = "0"]?toolate,1)
exten => 1,n,dbDel(RG/${ARG3}/${UNIQCHAN})
exten => 1,n,dbDel(${BLKVM_OVERRIDE})
exten => 1,n,Set(__MACRO_RESULT=)
exten => 1,n(exitopt1),MacroExit()
exten => 2,1,Goto(noanswer,1)
exten => 3,1,SayDigits(${CALLCONFIRMCID})
exten => 3,n,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" = "0"]?toolate,1:s,start)
exten => t,1,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" = "0"]?toolate,1)
exten => t,n,Set(LOOPCOUNT=$[ ${LOOPCOUNT} + 1 ])
exten => t,n,GotoIf($[ ${LOOPCOUNT} < 5 ]?s,start:noanswer,1)
exten => _X,1,Background(invalid,m,${CHANNEL(language)},macro-confirm)
exten => _X,n,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" = "0"]?toolate,1)
exten => _X,n,Set(LOOPCOUNT=$[ ${LOOPCOUNT} + 1 ])
exten => _X,n,GotoIf($[ ${LOOPCOUNT} < 5 ]?s,start:noanswer,1)
exten => noanswer,1,Set(__MACRO_RESULT=ABORT)
exten => noanswer,n(exitnoanswer),MacroExit()
exten => toolate,1,Set(MSG2=${IF($["foo${ARG2}" != "foo"]?${ARG2}:"incoming-call-no-longer-avail")})
exten => toolate,n,Playback(${MSG2})
exten => toolate,n,Set(__MACRO_RESULT=ABORT)
exten => toolate,n(exittoolate),MacroExit()
exten => h,1,Macro(hangupcall,)

If the user presses a DTMF digit while the message is playing (typically "1" to confirm and accept the call) then the call is failing with a log file entry as shown below.

If they allow the message to play to completion, thus allowing the dialplan to progress to the subsequent Read() application, then the dialplan works as expected.

In one reported instance the log file reported the following:

[Apr 2 21:30:21] WARNING[12523] file.c: Unexpected control subclass '-1'
[Apr 2 21:30:27] DEBUG[12523] app_macro.c: Oooh, got something to jump out with ('1')!
[Apr 2 21:30:27] DEBUG[12523] app_dial.c: Macro exited with status 49
[Apr 2 21:30:27] VERBOSE[12527] logger.c: -- Executing [h@macro-dialout-trunk:1] Macro("Local/xxxxxxx@from-internal-182b,2", "hangupcall|") in new stack

In another instance the following was reported:

[Apr 3 10:34:59] DEBUG[17927] app_macro.c: Oooh, got something to jump out with ('1')!
[Apr 3 10:34:59] DEBUG[17927] app_dial.c: Macro exited with status 49
[Apr 3 10:34:59] DEBUG[17927] channel.c: Hanging up channel 'Local/xxxxxxx@from-internal-d163;1'
[Apr 3 10:34:59] DEBUG[17931] channel.c: Didn't get a frame from channel: Local/xxxxxxx@from-internal-d163;2
[Apr 3 10:34:59] DEBUG[17931] channel.c: Bridge stops bridging channels Local/xxxxxxx@from-internal-d163;2 and SIP/vitel-outbound-08632ed8

As can be seen for the dialplan, the background command is properly directing back to the macro-confirm context. This dialplan has been working flawlessly for 1-2 years on Asterisk 1.4 and it's variant on Asterisk 1.2 (the variant adjusting for Channel(language) that changed on 1.4).

Comments:By: Philippe Lindheimer (p_lindheimer) 2009-04-20 17:16:31

More data related to this. There is a macro that allows for a recording to be listened to and re-recorded in FreePBX that uses a similar Background() command within a macro, it is here:

[macro-systemrecording]
include => macro-systemrecording-custom
exten => s,1,Set(RECFILE=${IF($["${ARG2}" = ""]?/tmp/${AMPUSER}-ivrrecording:${ARG2})})
exten => s,n,ExecIf($["${ARG3}" != ""],Authenticate,${ARG3})
exten => s,n,Goto(${ARG1},1)
exten => dorecord,1,System(rm ${ASTVARLIBDIR}/sounds/${RECFILE}.*)
exten => dorecord,n,Record(${RECFILE}:wav)
exten => dorecord,n,Wait(1)
exten => dorecord,n,Goto(confmenu,1)
exten => docheck,1,Playback(beep)
exten => docheck,n(dc_start),Background(${RECFILE},m,${CHANNEL(language)},macro-systemrecording)
exten => docheck,n,Wait(1)
exten => docheck,n,Goto(confmenu,1)
exten => confmenu,1,Background(to-listen-to-it&press-1&to-rerecord-it&press-star&astcc-followed-by-pound,m,${CHANNEL(language)},macro-systemrecording)
exten => confmenu,n,Read(RECRESULT,,1,,,4)
exten => confmenu,n,GotoIf($["x${RECRESULT}"="x*"]?dorecord,1)
exten => confmenu,n,GotoIf($["x${RECRESULT}"="x1"]?docheck,2)
exten => confmenu,n,Goto(1)
exten => 1,1,Goto(docheck,dc_start)
exten => *,1,Goto(dorecord,1)
exten => t,1,Playback(goodbye)
exten => t,n,Hangup
exten => i,1,Playback(pm-invalid-option)
exten => i,n,Goto(confmenu,1)
exten => h,1,Hangup

You will notice that it has a valid option "1" as one of the menu items. In the CLI of a 1.4.24 system, that is verified:

pbx72*CLI> show dialplan 1@macro-systemrecording
[ Context 'macro-systemrecording' created by 'pbx_config' ]
 '1' =>            1. Goto(docheck|dc_start)                     [pbx_config]

-= 1 extension (1 priority) in 1 context. =-

As expected. Now, when going into that macro and trying to choose option 1, note the behavior:

[Apr 20 22:00:11] VERBOSE[9969] logger.c:     -- Executing [confmenu@macro-systemrecording:1] BackGround("DAHDI/1-1", "to-listen-to-it&press-1&to-rerecord-it&press-star&astcc-followed-by-pound|m|en|macro-systemrecording") in new stack
[Apr 20 22:00:11] VERBOSE[9969] logger.c:     -- <DAHDI/1-1> Playing 'to-listen-to-it' (language 'en')
[Apr 20 22:00:12] VERBOSE[9969] logger.c:     -- <DAHDI/1-1> Playing 'press-1' (language 'en')
[Apr 20 22:00:13] DEBUG[9969] app_macro.c: Oooh, got something to jump out with ('1')!
[Apr 20 22:00:18] VERBOSE[9969] logger.c:     -- Invalid extension '1' in context 'from-internal' on DAHDI/1-1
[Apr 20 22:00:18] VERBOSE[9969] logger.c:   == CDR updated on DAHDI/1-1
[Apr 20 22:00:18] VERBOSE[9969] logger.c:     -- Executing [i@from-internal:1] Playback("DAHDI/1-1", "privacy-incorrect") in new stack

Note that is got a '1' to jump out with, but then it reports that there is no valid extension '1' in from-internal and in this case, goes on to play the invalid extensions since defined.

from-internal is the context that macro-systemrecording was called from. However, you will note the explicit directive to use macro-systemrecording in the context:

exten => confmenu,1,Background(to-listen-to-it&press-1&to-rerecord-it&press-star&astcc-followed-by-pound,m,${CHANNEL(language)},macro-systemrecording)

So there seems to be something clearly broken with Background()
By: Tilghman Lesher (tilghman) 2009-04-20 19:26:43

See related issue for the cause.  I have uploaded a patch, and testing would be appreciated.
By: Philippe Lindheimer (p_lindheimer) 2009-04-22 18:43:31

Just tested, and it appears to have fixed both scenarios reported here. Thanks!
By: Digium Subversion (svnbot) 2009-05-07 18:41:12

Repository: asterisk
Revision: 193119

U   branches/1.4/main/pbx.c

------------------------------------------------------------------------
r193119 | tilghman | 2009-05-07 18:41:11 -0500 (Thu, 07 May 2009) | 19 lines

Fix Background within a Macro for FreePBX.
If the single digit DTMF is an extension in the specified context, then
go there and signal no DTMF.  Otherwise, we should exit with that DTMF.
If we're in Macro, we'll exit and seek that DTMF as the beginning of an
extension in the Macro's calling context.  If we're not in Macro, then
we'll simply seek that extension in the calling context.  Previously,
someone complained about the behavior as it related to the interior of a
Gosub routine, and the fix (ASTERISK-13159) inadvertently broke FreePBX
(ASTERISK-13929).  This change should fix both of these situations, but with the
possible incompatibility that if a single digit extension does not exist
(but a longer extension COULD have matched), it would have previously
gone immediately to the "i" extension, but will now need to wait for a
timeout.
(closes issue ASTERISK-13929)
Reported by: p_lindheimer
Patches:
      20090420__bug14940.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=193119
By: Digium Subversion (svnbot) 2009-05-07 18:42:30

Repository: asterisk
Revision: 193120

_U  trunk/
U   trunk/main/pbx.c

------------------------------------------------------------------------
r193120 | tilghman | 2009-05-07 18:42:29 -0500 (Thu, 07 May 2009) | 26 lines

Merged revisions 193119 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r193119 | tilghman | 2009-05-07 18:41:11 -0500 (Thu, 07 May 2009) | 19 lines
 
 Fix Background within a Macro for FreePBX.
 If the single digit DTMF is an extension in the specified context, then
 go there and signal no DTMF.  Otherwise, we should exit with that DTMF.
 If we're in Macro, we'll exit and seek that DTMF as the beginning of an
 extension in the Macro's calling context.  If we're not in Macro, then
 we'll simply seek that extension in the calling context.  Previously,
 someone complained about the behavior as it related to the interior of a
 Gosub routine, and the fix (ASTERISK-13159) inadvertently broke FreePBX
 (ASTERISK-13929).  This change should fix both of these situations, but with the
 possible incompatibility that if a single digit extension does not exist
 (but a longer extension COULD have matched), it would have previously
 gone immediately to the "i" extension, but will now need to wait for a
 timeout.
 (closes issue ASTERISK-13929)
  Reported by: p_lindheimer
  Patches:
        20090420__bug14940.diff.txt uploaded by tilghman (license 14)
  Tested by: p_lindheimer
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=193120
By: Digium Subversion (svnbot) 2009-05-07 18:43:24

Repository: asterisk
Revision: 193121

_U  branches/1.6.0/
U   branches/1.6.0/main/pbx.c

------------------------------------------------------------------------
r193121 | tilghman | 2009-05-07 18:43:23 -0500 (Thu, 07 May 2009) | 33 lines

Merged revisions 193120 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r193120 | tilghman | 2009-05-07 18:42:28 -0500 (Thu, 07 May 2009) | 26 lines
 
 Merged revisions 193119 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r193119 | tilghman | 2009-05-07 18:41:11 -0500 (Thu, 07 May 2009) | 19 lines
   
   Fix Background within a Macro for FreePBX.
   If the single digit DTMF is an extension in the specified context, then
   go there and signal no DTMF.  Otherwise, we should exit with that DTMF.
   If we're in Macro, we'll exit and seek that DTMF as the beginning of an
   extension in the Macro's calling context.  If we're not in Macro, then
   we'll simply seek that extension in the calling context.  Previously,
   someone complained about the behavior as it related to the interior of a
   Gosub routine, and the fix (ASTERISK-13159) inadvertently broke FreePBX
   (ASTERISK-13929).  This change should fix both of these situations, but with the
   possible incompatibility that if a single digit extension does not exist
   (but a longer extension COULD have matched), it would have previously
   gone immediately to the "i" extension, but will now need to wait for a
   timeout.
   (closes issue ASTERISK-13929)
    Reported by: p_lindheimer
    Patches:
          20090420__bug14940.diff.txt uploaded by tilghman (license 14)
    Tested by: p_lindheimer
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=193121
By: Digium Subversion (svnbot) 2009-05-07 18:44:21

Repository: asterisk
Revision: 193122

_U  branches/1.6.1/
U   branches/1.6.1/main/pbx.c

------------------------------------------------------------------------
r193122 | tilghman | 2009-05-07 18:44:20 -0500 (Thu, 07 May 2009) | 33 lines

Merged revisions 193120 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r193120 | tilghman | 2009-05-07 18:42:28 -0500 (Thu, 07 May 2009) | 26 lines
 
 Merged revisions 193119 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r193119 | tilghman | 2009-05-07 18:41:11 -0500 (Thu, 07 May 2009) | 19 lines
   
   Fix Background within a Macro for FreePBX.
   If the single digit DTMF is an extension in the specified context, then
   go there and signal no DTMF.  Otherwise, we should exit with that DTMF.
   If we're in Macro, we'll exit and seek that DTMF as the beginning of an
   extension in the Macro's calling context.  If we're not in Macro, then
   we'll simply seek that extension in the calling context.  Previously,
   someone complained about the behavior as it related to the interior of a
   Gosub routine, and the fix (ASTERISK-13159) inadvertently broke FreePBX
   (ASTERISK-13929).  This change should fix both of these situations, but with the
   possible incompatibility that if a single digit extension does not exist
   (but a longer extension COULD have matched), it would have previously
   gone immediately to the "i" extension, but will now need to wait for a
   timeout.
   (closes issue ASTERISK-13929)
    Reported by: p_lindheimer
    Patches:
          20090420__bug14940.diff.txt uploaded by tilghman (license 14)
    Tested by: p_lindheimer
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=193122
By: Digium Subversion (svnbot) 2009-05-07 18:44:39

Repository: asterisk
Revision: 193123

_U  branches/1.6.2/
U   branches/1.6.2/main/pbx.c

------------------------------------------------------------------------
r193123 | tilghman | 2009-05-07 18:44:38 -0500 (Thu, 07 May 2009) | 33 lines

Merged revisions 193120 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r193120 | tilghman | 2009-05-07 18:42:28 -0500 (Thu, 07 May 2009) | 26 lines
 
 Merged revisions 193119 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r193119 | tilghman | 2009-05-07 18:41:11 -0500 (Thu, 07 May 2009) | 19 lines
   
   Fix Background within a Macro for FreePBX.
   If the single digit DTMF is an extension in the specified context, then
   go there and signal no DTMF.  Otherwise, we should exit with that DTMF.
   If we're in Macro, we'll exit and seek that DTMF as the beginning of an
   extension in the Macro's calling context.  If we're not in Macro, then
   we'll simply seek that extension in the calling context.  Previously,
   someone complained about the behavior as it related to the interior of a
   Gosub routine, and the fix (ASTERISK-13159) inadvertently broke FreePBX
   (ASTERISK-13929).  This change should fix both of these situations, but with the
   possible incompatibility that if a single digit extension does not exist
   (but a longer extension COULD have matched), it would have previously
   gone immediately to the "i" extension, but will now need to wait for a
   timeout.
   (closes issue ASTERISK-13929)
    Reported by: p_lindheimer
    Patches:
          20090420__bug14940.diff.txt uploaded by tilghman (license 14)
    Tested by: p_lindheimer
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=193123
By: Digium Subversion (svnbot) 2010-01-04 12:19:02.000-0600

Repository: asterisk
Revision: 237405

U   branches/1.4/include/asterisk/channel.h
U   branches/1.4/main/pbx.c
U   branches/1.4/res/res_agi.c

------------------------------------------------------------------------
r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines

Add a flag to disable the Background behavior, for AGI users.
This is in a section of code that relates to two other issues, namely
issue ASTERISK-13159 and issue ASTERISK-13929), one of which was the behavior of
Background when called with a context argument that matched the current
context.  This fix broke FreePBX, however, in a post-Dial situation.
Needless to say, this is an extremely difficult collision of several
different issues.  While the use of an exception flag is ugly, fixing all
of the issues linked is rather difficult (although if someone would like
to propose a better solution, we're happy to entertain that suggestion).
(closes issue ASTERISK-15306)
Reported by: rickead2000
Patches:
      20091217__issue16434.diff.txt uploaded by tilghman (license 14)
      20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
Tested by: rickead2000

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=237405
By: Digium Subversion (svnbot) 2010-01-04 12:28:30.000-0600

Repository: asterisk
Revision: 237406

_U  trunk/
U   trunk/include/asterisk/channel.h
U   trunk/main/pbx.c
U   trunk/res/res_agi.c

------------------------------------------------------------------------
r237406 | tilghman | 2010-01-04 12:28:29 -0600 (Mon, 04 Jan 2010) | 23 lines

Merged revisions 237405 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines
 
 Add a flag to disable the Background behavior, for AGI users.
 This is in a section of code that relates to two other issues, namely
 issue ASTERISK-13159 and issue ASTERISK-13929), one of which was the behavior of
 Background when called with a context argument that matched the current
 context.  This fix broke FreePBX, however, in a post-Dial situation.
 Needless to say, this is an extremely difficult collision of several
 different issues.  While the use of an exception flag is ugly, fixing all
 of the issues linked is rather difficult (although if someone would like
 to propose a better solution, we're happy to entertain that suggestion).
 (closes issue ASTERISK-15306)
  Reported by: rickead2000
  Patches:
        20091217__issue16434.diff.txt uploaded by tilghman (license 14)
        20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
  Tested by: rickead2000
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=237406
By: Digium Subversion (svnbot) 2010-01-04 12:30:37.000-0600

Repository: asterisk
Revision: 237407

_U  branches/1.6.0/
U   branches/1.6.0/include/asterisk/channel.h
U   branches/1.6.0/main/pbx.c
U   branches/1.6.0/res/res_agi.c

------------------------------------------------------------------------
r237407 | tilghman | 2010-01-04 12:30:36 -0600 (Mon, 04 Jan 2010) | 30 lines

Merged revisions 237406 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r237406 | tilghman | 2010-01-04 12:28:28 -0600 (Mon, 04 Jan 2010) | 23 lines
 
 Merged revisions 237405 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines
   
   Add a flag to disable the Background behavior, for AGI users.
   This is in a section of code that relates to two other issues, namely
   issue ASTERISK-13159 and issue ASTERISK-13929), one of which was the behavior of
   Background when called with a context argument that matched the current
   context.  This fix broke FreePBX, however, in a post-Dial situation.
   Needless to say, this is an extremely difficult collision of several
   different issues.  While the use of an exception flag is ugly, fixing all
   of the issues linked is rather difficult (although if someone would like
   to propose a better solution, we're happy to entertain that suggestion).
   (closes issue ASTERISK-15306)
    Reported by: rickead2000
    Patches:
          20091217__issue16434.diff.txt uploaded by tilghman (license 14)
          20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
    Tested by: rickead2000
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=237407
By: Digium Subversion (svnbot) 2010-01-04 12:30:45.000-0600

Repository: asterisk
Revision: 237408

_U  branches/1.6.1/
U   branches/1.6.1/include/asterisk/channel.h
U   branches/1.6.1/main/pbx.c
U   branches/1.6.1/res/res_agi.c

------------------------------------------------------------------------
r237408 | tilghman | 2010-01-04 12:30:44 -0600 (Mon, 04 Jan 2010) | 30 lines

Merged revisions 237406 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r237406 | tilghman | 2010-01-04 12:28:28 -0600 (Mon, 04 Jan 2010) | 23 lines
 
 Merged revisions 237405 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines
   
   Add a flag to disable the Background behavior, for AGI users.
   This is in a section of code that relates to two other issues, namely
   issue ASTERISK-13159 and issue ASTERISK-13929), one of which was the behavior of
   Background when called with a context argument that matched the current
   context.  This fix broke FreePBX, however, in a post-Dial situation.
   Needless to say, this is an extremely difficult collision of several
   different issues.  While the use of an exception flag is ugly, fixing all
   of the issues linked is rather difficult (although if someone would like
   to propose a better solution, we're happy to entertain that suggestion).
   (closes issue ASTERISK-15306)
    Reported by: rickead2000
    Patches:
          20091217__issue16434.diff.txt uploaded by tilghman (license 14)
          20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
    Tested by: rickead2000
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=237408
By: Digium Subversion (svnbot) 2010-01-04 12:30:54.000-0600

Repository: asterisk
Revision: 237409

_U  branches/1.6.2/
U   branches/1.6.2/include/asterisk/channel.h
U   branches/1.6.2/main/pbx.c
U   branches/1.6.2/res/res_agi.c

------------------------------------------------------------------------
r237409 | tilghman | 2010-01-04 12:30:53 -0600 (Mon, 04 Jan 2010) | 30 lines

Merged revisions 237406 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r237406 | tilghman | 2010-01-04 12:28:28 -0600 (Mon, 04 Jan 2010) | 23 lines
 
 Merged revisions 237405 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines
   
   Add a flag to disable the Background behavior, for AGI users.
   This is in a section of code that relates to two other issues, namely
   issue ASTERISK-13159 and issue ASTERISK-13929), one of which was the behavior of
   Background when called with a context argument that matched the current
   context.  This fix broke FreePBX, however, in a post-Dial situation.
   Needless to say, this is an extremely difficult collision of several
   different issues.  While the use of an exception flag is ugly, fixing all
   of the issues linked is rather difficult (although if someone would like
   to propose a better solution, we're happy to entertain that suggestion).
   (closes issue ASTERISK-15306)
    Reported by: rickead2000
    Patches:
          20091217__issue16434.diff.txt uploaded by tilghman (license 14)
          20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
    Tested by: rickead2000
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=237409