[Home]

Summary:ASTERISK-14598: [patch] Dialplan starts execution before call is accepted
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-08-04 18:40:32Date Closed:2009-08-05 15:43:58
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sig_pri-bug15655.diff.txt
Description:example dialplan code that is repeatable.

exten => 8696,1,Congestion(0)

<b>Correct</b> console output:
Unknown IE 50 (cs5, Unknown Information Element)
   -- Accepting call from 'XXXX205' to '8696' on channel 0/31, span 1
   -- Executing [8696@incoming:1] Congestion("DAHDI/31-1", "0") in new stack
 == Spawn extension (incoming, 8696, 1) exited non-zero on 'DAHDI/31-1'
   -- Hungup 'DAHDI/31-1'

<b>Incorrect</b> console output:

!! Unknown IE 50 (cs5, Unknown Information Element)
   -- Executing [8696@incoming:1] Congestion("DAHDI/31-1", "0") in new stack
 == Spawn extension (incoming, 8696, 1) exited non-zero on 'DAHDI/31-1'
   -- Hungup 'DAHDI/31-1'
   -- Accepting call from 'XXXXX205' to '' on channel 0/31, span 1

No further calls can be made into asterisk.
Shortly after. Asterisk will segfault.
Comments:By: Alec Davis (alecdavis) 2009-08-04 18:45:11

Console output after patch:
Every time, the call is accepted, then the Dialplan starts.

!! Unknown IE 50 (cs5, Unknown Information Element)
   -- Accepting call from '8512' to '8696' on channel 0/1, span 1
   -- Executing [8696@incoming:1] Congestion("DAHDI/1-1", "0") in new stack
 == Spawn extension (incoming, 8696, 1) exited non-zero on 'DAHDI/1-1'
   -- Hungup 'DAHDI/1-1'
!! Unknown IE 50 (cs5, Unknown Information Element)
   -- Accepting call from '8512' to '8696' on channel 0/2, span 1
   -- Executing [8696@incoming:1] Congestion("DAHDI/2-1", "0") in new stack
 == Spawn extension (incoming, 8696, 1) exited non-zero on 'DAHDI/2-1'
   -- Hungup 'DAHDI/2-1'
!! Unknown IE 50 (cs5, Unknown Information Element)
   -- Accepting call from '8512' to '8696' on channel 0/3, span 1
   -- Executing [8696@incoming:1] Congestion("DAHDI/3-1", "0") in new stack
 == Spawn extension (incoming, 8696, 1) exited non-zero on 'DAHDI/3-1'
   -- Hungup 'DAHDI/3-1'
!! Unknown IE 50 (cs5, Unknown Information Element)
   -- Accepting call from '8512' to '8696' on channel 0/4, span 1
   -- Executing [8696@incoming:1] Congestion("DAHDI/4-1", "0") in new stack
 == Spawn extension (incoming, 8696, 1) exited non-zero on 'DAHDI/4-1'
   -- Hungup 'DAHDI/4-1'
!! Unknown IE 50 (cs5, Unknown Information Element)
   -- Accepting call from '8512' to '8696' on channel 0/5, span 1
   -- Executing [8696@incoming:1] Congestion("DAHDI/5-1", "0") in new stack
 == Spawn extension (incoming, 8696, 1) exited non-zero on 'DAHDI/5-1'
   -- Hungup 'DAHDI/5-1'
!! Unknown IE 50 (cs5, Unknown Information Element)
   -- Accepting call from '8512' to '8696' on channel 0/6, span 1
   -- Executing [8696@incoming:1] Congestion("DAHDI/6-1", "0") in new stack
 == Spawn extension (incoming, 8696, 1) exited non-zero on 'DAHDI/6-1'
   -- Hungup 'DAHDI/6-1'
By: Alec Davis (alecdavis) 2009-08-04 19:42:55

Turns out this is a similar fix as in http://svn.digium.com/svn/asterisk/team/group/issue14068/channels/sig_pri.c
By: Alec Davis (alecdavis) 2009-08-04 20:14:24

SVN-branch-1.6.1-r202764M we also see dialplan execution start before 'Accepting call from.....'
By: Alec Davis (alecdavis) 2009-08-05 03:01:20

Tried libpri-issue14068 and asterisl-issue14068 and although the fix is similar and tidier, the output on console is still out of order, 'Accepting call' is later, I'm guessing will be random.

This output was a call from a Jtec ISDN Switch with CallingSubAddress set to '2580', CalledSubAddress was '0863' - but thats not relevant yet.

unpatched console output:
   -- Executing [8696@incoming:1] NoOp("DAHDI/25-1", "9100 callingsubaddr=2580 calledsubaddr=") in new stack
   -- Executing [8696@incoming:2] Congestion("DAHDI/25-1", "0") in new stack
   -- Accepting call from 'XXXXX9100' to '8696' on channel 0/25, span 1
By: Digium Subversion (svnbot) 2009-08-05 14:19:15

Repository: asterisk
Revision: 210575

U   branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r210575 | rmudgett | 2009-08-05 14:19:14 -0500 (Wed, 05 Aug 2009) | 14 lines

Dialplan starts execution before the channel setup is complete.

*  Issue 15655: For the case where dialing is complete for an incoming
call, dahdi_new() was asked to start the PBX and then the code set more
channel variables.  If the dialplan hungup before these channel variables
got set, asterisk would likely crash.
*  Fixed potential for overlap incoming call to erroneously set channel
variables as global dialplan variables if the ast_channel structure failed
to get allocated.
*  Added missing set of CALLINGSUBADDR in the dialing is complete case.

(closes issue ASTERISK-14598)
Reported by: alecdavis

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

http://svn.digium.com/view/asterisk?view=rev&revision=210575
By: Alec Davis (alecdavis) 2009-08-05 14:39:12

Richard:
This also applies to the 1.6.1 branch, not sure about 1.6.0 or 1.6.2

By: Digium Subversion (svnbot) 2009-08-05 14:40:21

Repository: asterisk
Revision: 210640

_U  trunk/
U   trunk/channels/sig_pri.c

------------------------------------------------------------------------
r210640 | rmudgett | 2009-08-05 14:40:20 -0500 (Wed, 05 Aug 2009) | 21 lines

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

........
 r210575 | rmudgett | 2009-08-05 14:18:56 -0500 (Wed, 05 Aug 2009) | 14 lines
 
 Dialplan starts execution before the channel setup is complete.
 
 *  Issue 15655: For the case where dialing is complete for an incoming
 call, dahdi_new() was asked to start the PBX and then the code set more
 channel variables.  If the dialplan hungup before these channel variables
 got set, asterisk would likely crash.
 *  Fixed potential for overlap incoming call to erroneously set channel
 variables as global dialplan variables if the ast_channel structure failed
 to get allocated.
 *  Added missing set of CALLINGSUBADDR in the dialing is complete case.
 
 (closes issue ASTERISK-14598)
 Reported by: alecdavis
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=210640
By: Digium Subversion (svnbot) 2009-08-05 15:07:27

Repository: asterisk
Revision: 210647

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_dahdi.c

------------------------------------------------------------------------
r210647 | rmudgett | 2009-08-05 15:07:26 -0500 (Wed, 05 Aug 2009) | 28 lines

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

................
 r210640 | rmudgett | 2009-08-05 14:40:03 -0500 (Wed, 05 Aug 2009) | 21 lines
 
 Merged revisions 210575 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r210575 | rmudgett | 2009-08-05 14:18:56 -0500 (Wed, 05 Aug 2009) | 14 lines
   
   Dialplan starts execution before the channel setup is complete.
   
   *  Issue 15655: For the case where dialing is complete for an incoming
   call, dahdi_new() was asked to start the PBX and then the code set more
   channel variables.  If the dialplan hungup before these channel variables
   got set, asterisk would likely crash.
   *  Fixed potential for overlap incoming call to erroneously set channel
   variables as global dialplan variables if the ast_channel structure failed
   to get allocated.
   *  Added missing set of CALLINGSUBADDR in the dialing is complete case.
   
   (closes issue ASTERISK-14598)
   Reported by: alecdavis
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=210647
By: Digium Subversion (svnbot) 2009-08-05 15:28:25

Repository: asterisk
Revision: 210681

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_dahdi.c

------------------------------------------------------------------------
r210681 | rmudgett | 2009-08-05 15:28:25 -0500 (Wed, 05 Aug 2009) | 28 lines

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

................
 r210640 | rmudgett | 2009-08-05 14:40:03 -0500 (Wed, 05 Aug 2009) | 21 lines
 
 Merged revisions 210575 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r210575 | rmudgett | 2009-08-05 14:18:56 -0500 (Wed, 05 Aug 2009) | 14 lines
   
   Dialplan starts execution before the channel setup is complete.
   
   *  Issue 15655: For the case where dialing is complete for an incoming
   call, dahdi_new() was asked to start the PBX and then the code set more
   channel variables.  If the dialplan hungup before these channel variables
   got set, asterisk would likely crash.
   *  Fixed potential for overlap incoming call to erroneously set channel
   variables as global dialplan variables if the ast_channel structure failed
   to get allocated.
   *  Added missing set of CALLINGSUBADDR in the dialing is complete case.
   
   (closes issue ASTERISK-14598)
   Reported by: alecdavis
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=210681
By: Digium Subversion (svnbot) 2009-08-05 15:43:58

Repository: asterisk
Revision: 210686

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r210686 | rmudgett | 2009-08-05 15:43:58 -0500 (Wed, 05 Aug 2009) | 28 lines

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

................
 r210640 | rmudgett | 2009-08-05 14:40:03 -0500 (Wed, 05 Aug 2009) | 21 lines
 
 Merged revisions 210575 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r210575 | rmudgett | 2009-08-05 14:18:56 -0500 (Wed, 05 Aug 2009) | 14 lines
   
   Dialplan starts execution before the channel setup is complete.
   
   *  Issue 15655: For the case where dialing is complete for an incoming
   call, dahdi_new() was asked to start the PBX and then the code set more
   channel variables.  If the dialplan hungup before these channel variables
   got set, asterisk would likely crash.
   *  Fixed potential for overlap incoming call to erroneously set channel
   variables as global dialplan variables if the ast_channel structure failed
   to get allocated.
   *  Added missing set of CALLINGSUBADDR in the dialing is complete case.
   
   (closes issue ASTERISK-14598)
   Reported by: alecdavis
 ........
................

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

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