[asterisk-bugs] [JIRA] (ASTERISK-25214) DTMF over SIP INFO and direct media does not work well together

Wed Mar 23 10:49:56 CDT 2016

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

Etienne Lessard edited comment on ASTERISK-25214 at 3/23/16 10:48 AM:
----------------------------------------------------------------------

Hello,

So I took a bit of time to try understanding why the bug is present in Asterisk 13 and not in Asterisk 11. By enabling the DTMF log, a difference shows up:

In Asterisk 11:

{code}
DTMF[10861][C-00000002]: __ast_read: DTMF end '5' received on SIP/69jqad-00000004, duration 160 ms
DTMF[10861][C-00000002]: __ast_read: DTMF end passthrough '5' on SIP/69jqad-00000004
{code}

In Asterisk 13:

{code}
DTMF[29484][C-00000004]: __ast_read: DTMF end '6' received on SIP/69jqad-00000007, duration 160 ms
DTMF[29484][C-00000004]: __ast_read: DTMF begin emulation of '6' with duration 160 queued on SIP/69jqad-00000007
...
{code}

So in Asterisk 11, when direct media is enabled and SIP INFO is used, when an AST_FRAME_DTMF_END control frame is read from the channel's readq, asterisk does not try to emulate the DTMF and just return the frame (in the simple case). In Asterisk 13, it begins emulating the DTMF, but since we are in direct media, the emulation ends doesn't happen promptly since no VOICE or NULL frames are read to trigger the end of the emulation, etc.

Why did it "worked" in Asterisk 11 with chan_sip ? Mostly because of this:

In chan_sip.c, in the sip_new function (sip_tech_info is an ast_channel_tech with a NULL send_digit_begin):

{code}
ast_channel_tech_set(tmp, (ast_test_flag(&i->flags[0], SIP_DTMF) == SIP_DTMF_INFO || ast_test_flag(&i->flags[0], SIP_DTMF) == SIP_DTMF_SHORTINFO) ? &sip_tech_info : &sip_tech);
{code}

In channel.c, in the ast_channel_bridge function (just before bridging the two channels) -- the equivalent does not exist in Asterisk 13:

{code}
if (!ast_channel_tech(c0)->send_digit_begin)
    ast_set_flag(ast_channel_flags(c1), AST_FLAG_END_DTMF_ONLY);
if (!ast_channel_tech(c1)->send_digit_begin)
    ast_set_flag(ast_channel_flags(c0), AST_FLAG_END_DTMF_ONLY);
{code}

So in Asterisk 11, when 2 channels using SIP INFO are bridged by ast_channel_bridge, the AST_FLAG_END_DTMF_ONLY flag is set, and when this flag is set, DTMF "pass through correctly" (most of the time).

I'm sharing an ad hoc, non exhaustive patch I wrote for Asterisk 13 that:

* works with either app_dial, app_queue and app_followme
* works with chan_sip
* not compatible with chan_pjsip (since chan_pjsip doesn't implement the "alternative ast_channel_tech with a NULL send_digit_begin" hack that chan_sip does).
* not compatible with other way to bridge calls (e.g. from ARI)
* does not work if Local channels are involved

I don't consider this patch to be the "right solution", but I guess it might be helpful for some other people until there's a more complete fix.

Note that I'm interested in this bug mostly for 2 reasons:

* we have clients which are using both direct media and an external application that is using the AMI "Transfer" action, which is currently implemented in Asterisk with "features code", and requires the use of the tT option in Dial to work, but using theses options with RFC2833 prevent direct media, so we need use SIP INFO
* we have clients using an SCCP channel driver (not chan_skinny) that supports SIP / SCCP direct media, and since DTMF with SCCP phones are not in the RTP, this is the same problem as DTMF with SIP INFO

Thank you.

was (Author: hexanol):
Hello,