[asterisk-bugs] [JIRA] (ASTERISK-29018) pbx: Channel redirect might be missed if redirected channel is executing dialplan
Patrick Wakano (JIRA)
noreply at issues.asterisk.org
Tue Aug 4 20:25:43 CDT 2020
[ https://issues.asterisk.org/jira/browse/ASTERISK-29018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Wakano updated ASTERISK-29018:
--------------------------------------
Status: Waiting for Feedback (was: Waiting for Feedback)
The example was created just to force the problem and simulate it in my local asterisk but it was based on my production scenario. So my real world case is just a very complex version of the example. The loop is there to simulate a long dialplan. The CLI command is simulating a separate application that triggers the channel redirect from the ChannelRedirect application running in another context.
To summarize, you can think of it as this pseudo-code:
[callwait-context]
exten => s,1,NoOp(Income calls land here and some dialplan logic happens)
same => n,AGI(A RabbitMQ msg is sent)
same => n,NoOp(Long dialplan logic happens here which includes playbacks, setting variables, GoSub and AGI calls with DB queries)
same => n,BridgeWait
[redirect-context]
exten => s,1,NoOp(Only few lines in here)
same => n,ChannelRedirect(${WAIT_CHAN},somewhereelse,s,1)
So the idea is that the channel should execute the callwait-context and reach the BridgeWait from where it will be bridged or redirected somewhere else. In my case the RabbitMQ msg is treated by another application. As a result that application will at some point decide to send an Originate command via AMI which will run the redirect-context in a Local channel that executes the ChannelRedirect for the waiting channel. However, occasionally, the Originate command is sent before the channel being able to reach the BridgeWait. In this case, the ChannelRedirect happens to happen during that long dialplan logic, and we've seen some few cases where the ChannelRedirect just doesn't work, and because the redirection is missed the channel reaches and stays in the BridgeWait until it times out (an error situation not expected to happen).
>From observation, I could not find a pattern for the problem. From the cases I've seen there is no common step in the dialplan causing the issue. It seems that, regardless of the command, for every priority, there is a small window where the dialplan and the redirect can both modify the next step for the channel, and if unlucky the dialplan overrides what the redirect has just done. Sometimes it even happens to have the context and priority mixed from both commands, eg. the context is the one set by the redirect, but the priority is the one from the dialplan...
> pbx: Channel redirect might be missed if redirected channel is executing dialplan
> ---------------------------------------------------------------------------------
>
> Key: ASTERISK-29018
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29018
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/Channels, Core/PBX
> Affects Versions: 16.8.0
> Reporter: Patrick Wakano
> Assignee: Patrick Wakano
> Severity: Minor
>
> When using the Channel Redirect feature (either the dialplan app ChannelRedirect or the CLI channel redirect) it has been observed that the redirection might just not work in case the channel being redirected is executing something else in the dialplan.
> Take for example the dialplan below just to simulate the issue. If while the channel is looping, the channel redirect command is issued for that channel from the CLI, the redirect might simply not work and the channel keeps executing the loop.
> Given the channel redirect is an explicit action to alter the channel execution, I think it should always override whatever dialplan execution the channel is doing, so it should just terminate the current priority and then immediately go to where the channel redirect determined. However there are cases where the next dialplan priority gets executed and so the redirection silently fails to happen even tough it says the redirection was successful.
> The problem does not happen every time, it seems to be a 30% chance of having the issue for the example below.
> {noformat}
> [pstn-outgoing]
> exten => 8888,1,Answer()
> same => n,Set(i=0)
> same => n,While($[${i} < 10000])
> same => n,Set(Dummy=${PRIORITY})
> same => n,Set(i=$[${i}+1])
> same => n,EndWhile
> same => n,NoOp(Loop end)
> same => n,Hangup()
> same => n(end),NoOp(Terminated)
> same => n,Hangup()
> {noformat}
> Logs:
> {noformat}
> -- Executing [8888 at pstn-outgoing:4] Set("SIP/9000-0000000f", "Dummy=4") in new stack
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=69") in new stack
> -- Executing [8888 at pstn-outgoing:6] EndWhile("SIP/9000-0000000f", "") in new stack
> -- Executing [8888 at pstn-outgoing:3] While("SIP/9000-0000000f", "1") in new stack
> -- Executing [8888 at pstn-outgoing:4] Set("SIP/9000-0000000f", "Dummy=4") in new stack
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=70") in new stack
> -- Executing [8888 at pstn-outgoing:6] EndWhile("SIP/9000-0000000f", "") in new stack
> -- Executing [8888 at pstn-outgoing:3] While("SIP/9000-0000000f", "1") in new stack
> -- Executing [8888 at pstn-outgoing:4] Set("SIP/9000-0000000f", "Dummy=4") in new stack
> pstn8*CLI> channel redirect SIP/9000-0000000f pstn-outgoing,8888,end
> Channel 'SIP/9000-0000000f' successfully redirected to pstn-outgoing,8888,end
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=287") in new stack
> -- Executing [8888 at pstn-outgoing:6] EndWhile("SIP/9000-0000000f", "") in new stack
> -- Executing [8888 at pstn-outgoing:3] While("SIP/9000-0000000f", "1") in new stack
> -- Executing [8888 at pstn-outgoing:4] Set("SIP/9000-0000000f", "Dummy=4") in new stack
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=288") in new stack
> -- Executing [8888 at pstn-outgoing:6] EndWhile("SIP/9000-0000000f", "") in new stack
> -- Executing [8888 at pstn-outgoing:3] While("SIP/9000-0000000f", "1") in new stack
> -- Executing [8888 at pstn-outgoing:4] Set("SIP/9000-0000000f", "Dummy=4") in new stack
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=289") in new stack
> .....
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=9997") in new stack
> -- Executing [8888 at pstn-outgoing:6] EndWhile("SIP/9000-0000000f", "") in new stack
> -- Executing [8888 at pstn-outgoing:3] While("SIP/9000-0000000f", "1") in new stack
> -- Executing [8888 at pstn-outgoing:4] Set("SIP/9000-0000000f", "Dummy=4") in new stack
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=9998") in new stack
> -- Executing [8888 at pstn-outgoing:6] EndWhile("SIP/9000-0000000f", "") in new stack
> -- Executing [8888 at pstn-outgoing:3] While("SIP/9000-0000000f", "1") in new stack
> -- Executing [8888 at pstn-outgoing:4] Set("SIP/9000-0000000f", "Dummy=4") in new stack
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=9999") in new stack
> -- Executing [8888 at pstn-outgoing:6] EndWhile("SIP/9000-0000000f", "") in new stack
> -- Executing [8888 at pstn-outgoing:3] While("SIP/9000-0000000f", "1") in new stack
> -- Executing [8888 at pstn-outgoing:4] Set("SIP/9000-0000000f", "Dummy=4") in new stack
> -- Executing [8888 at pstn-outgoing:5] Set("SIP/9000-0000000f", "i=10000") in new stack
> -- Executing [8888 at pstn-outgoing:6] EndWhile("SIP/9000-0000000f", "") in new stack
> -- Executing [8888 at pstn-outgoing:3] While("SIP/9000-0000000f", "0") in new stack
> -- Executing [8888 at pstn-outgoing:7] NoOp("SIP/9000-0000000f", "Loop end") in new stack
> -- Executing [8888 at pstn-outgoing:8] Hangup("SIP/9000-0000000f", "") in new stack
> == Spawn extension (pstn-outgoing, 8888, 8) exited non-zero on 'SIP/9000-0000000f'
> pstn8*CLI>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list