[asterisk-bugs] [JIRA] Updated: (ASTERISK-20492) Stuck DTMF when using ChannelRedirect to split a two channel bridge

[Jeremiah Gowdy (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-20492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremiah Gowdy updated ASTERISK-20492:
--------------------------------------

    Attachment: bridge_end_dtmf.patch.txt

This is our patch that seems to fix the issue.  We were forced to go off into the masquerade code as well, since if bridgepeer is the first one to ChannelRedirect(), the channel that started the bridge is left with a zombie bridge partner causing the dtmf end to be ignored.

> Stuck DTMF when using ChannelRedirect to split a two channel bridge
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-20492
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20492
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_bridge, Core/Channels
>    Affects Versions: 10.7.1, 10.8.0, 10.9.0
>         Environment: OpenSuSE 11.4 x64 virtual instance on vSphere 4, CentOS 6.3 x64 on Dell M610 blade
>            Reporter: Jeremiah Gowdy
>            Assignee: Rusty Newton
>            Severity: Critical
>         Attachments: bridge_end_dtmf.patch.txt, full-log.gz
>
>
> When two channels are bridged together and DTMF is used to indicate to our external application to end the bridge, our application executes ChannelRedirect on either one side or both (we tried both ways).  If ChannelRedirect happens after DTMF start but before DTMF end, it seems that the fact that we're in DTMF is copied to both channels as the bridge is dissolved, but the DTMF end is only exposed to one channel causing the other channel to continuously generate DTMF (dsp.c generating the tone in an endless loop).  The channel that gets stuck in the DTMF is always the channel that did not press the digit and thus doesn't get the DTMF end.  We have been able to reproduce this scenario with the DTMF generated by the caller or callee, either direction.  We only have DTMF handling enabled for the side of the call in which the key is pressed (we don't allow the other side to press keys), using the appropriate Bridge flags.  We have even seen a scenario in which the user presses the key that should cause the second channel to be hung up on, and we attempt to clear the second channel, but it seems so busy generating DTMF that the call is never ended.  So it seems to happen if a DTMF starts, a channel is cleared causing it to dissolve the bridge, and again the cleared channel failing to get DTMF end, leaving us stuck in continuous tone.  Issuing playback commands or pressing digits on the affected channel does not clear the continuous DTMF.
> As stated in the above bug fields, we have tried this on 10.7.1, 10.8.0, and 10.9.0-rc, so the recent DTMF rewrite doesn't seem to cause nor remedy the situation.  This bug is basically a fatal show stopper for our Asterisk based application which we were hoping to launch for the end of Q3.  :(
> We are working very hard to debug the issue and develop a patch, but any help would be greatly appreciated.
> I will attach full logs and packet traces shortly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira