[asterisk-bugs] [JIRA] (ASTERISK-16352) [patch] Dialplan execution stops after awhile on an attended transfer by the calling party (with use of Dial 'g' option)

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-16352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225669#comment-225669 ] 

Matt Jordan commented on ASTERISK-16352:
----------------------------------------

So, first, sorry no one ever replied back here. That kind of sucks.

Looking at your log, this never was actually a bug:
{noformat}
[Jul 12 13:06:42] VERBOSE[22529] logger.c:     -- Executing [s at test:4] Set("SIP/403-00000000", "COUNT=245") in new stack
[Jul 12 13:06:42] DEBUG[22529] pbx.c: Launching 'EndWhile'
[Jul 12 13:06:42] VERBOSE[22529] logger.c:     -- Executing [s at test:5] EndWhile("SIP/403-00000000", "") in new stack
[Jul 12 13:06:42] DEBUG[22464] chan_sip.c: = No match Their Call ID: 661e34bd326a41513b75a0177b0a7e36 at pbx.example.net Their Tag 5m8wetfyfp Our tag: as6fde7297
[Jul 12 13:06:42] DEBUG[22464] chan_sip.c: = No match Their Call ID: 3c2e49bd00dd-k1oqkgshy5g4 Their Tag 8rtcqs97zi Our tag: as0d3c611e
[Jul 12 13:06:42] DEBUG[22464] chan_sip.c: = No match Their Call ID: 30d126e27bda6e9d6fc66bfc3723b050 at pbx.example.net Their Tag n0xmr3nd78 Our tag: as4b3b9a42
[Jul 12 13:06:42] DEBUG[22464] chan_sip.c: = Found Their Call ID: 3c2e49b707ef-pezt1god6wj3 Their Tag pq023yzfo8 Our tag: as158b66b1
[Jul 12 13:06:42] DEBUG[22464] chan_sip.c: **** Received BYE (8) - Command in SIP BYE
[Jul 12 13:06:42] DEBUG[22464] chan_sip.c: Setting SIP_ALREADYGONE on dialog 3c2e49b707ef-pezt1god6wj3
[Jul 12 13:06:42] DEBUG[22464] chan_sip.c: Received bye, issuing owner hangup
[Jul 12 13:06:42] DEBUG[22529] pbx.c: Extension s, priority 1 returned normally even though call was hung up
[Jul 12 13:06:42] DEBUG[22529] channel.c: Soft-Hanging up channel 'SIP/403-00000000'
[Jul 12 13:06:42] DEBUG[22529] channel.c: Hanging up channel 'SIP/403-00000000'
{noformat}

When Asterisk receives a BYE, that hangs up a channel. When the channel hangs up, it stops executing dialplan. That's expected behaviour. If there are any hangup handlers or an {{h}} extension, we would go execute there - but the current execution is done. We only keep executing dialplan so long as the channel is up.

The reason why your patch "worked" is because it removed the {{break}} in the PBX core that stops dialplan execution on hangup. However, that is inherently unsafe. Many, many dialplan applications would crash if they were invoked on a hungup channel, as they would attempt to manipulate a channel that was already dead. What's more, there would be no good way for us to end dialplan execution until someone finally ran out of dialplan to execute - which means most Asterisk dialplans in the world would break.

As such, I'm closing this out as Not a Bug.

> [patch] Dialplan execution stops after awhile on an attended transfer by the calling party  (with use of Dial 'g' option)
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-16352
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16352
>             Project: Asterisk
>          Issue Type: Bug
>          Components: PBX/General
>            Reporter: Ramon Peek
>            Severity: Minor
>         Attachments: debug_log2.tar.gz, patch.diff
>
>
> Dialplan execution stops after awhile on an attended transfer by the calling party  (with use of Dial() command 'g' option) 
> This applies to systems with large dialplans (which we use), small dialplans do not seem to encounter much problems, due to the delay in SIP messaging.
> If traced, you can see the after Asterisk receives a SIP BYE message, the dialplan execution is immediately stopped even though there are other priorities to evaluate in the dialplan.
> SEE STEPS TO REPRODUCE (in advanced view mode)
> *STEPS TO REPRODUCE*
> I use this dialplan:
> {noformat}
> exten = 801,1,Dial(SIP/401,15,g)
> exten = 801,n,Goto(test,s,1)
> exten = 802,1,Dial(SIP/402,15,g)
> exten = 802,n,Goto(test,s,1)
> exten = 803,1,Dial(SIP/403,15,g)
> exten = 803,n,Goto(test,s,1)
> exten = h,1,Goto(test,s,1)
> [test]
> exten = s,1,Set(COUNT=1)
> exten = s,n,While($[${COUNT} <= 1000])
>  exten = s,n,Noop(Waiting loop started for issue 1321 - counter value = ${COUNT})
>  exten = s,n,Set(COUNT=$[${COUNT} + 1])
> exten = s,n,EndWhile
> exten = s,n,Hangup
> {noformat}
> Then:
> * From peer 403 (extension 803) dial 801 (peer 401) and answer.
> * Put call on Hold at 403
> * From peer 403 dial 802 (peer 402) and answer.
> * transfer the call.. (SIP REFER)
> Notice that the dialplan execution stops before the counter reaches 1000.
> NOTE:
> -----
> Please note that this example may seem ludicrous. However in my dialplan I use many ODBC calls that take up some time to execute, which is why I was confronted with this issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)