[Home]

Summary:ASTERISK-25214: DTMF over SIP INFO and direct media does not work well together
Reporter:Etienne Lessard (hexanol)Labels:
Date Opened:2015-06-30 11:19:45Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Bridges/bridge_native_rtp Channels/chan_sip/General
Versions:13.4.0 Frequency of
Occurrence		Constant
Related
Issues:
is duplicated byASTERISK-28245 DMTF emulation not working if direct_media = yes and dtmf_mode = info is set
Environment:Attachments:( 0) annotated-sip-debug.txt
( 1) AST-25214.ad_hoc.patch
( 2) extensions.conf
( 3) sip.conf
Description:Hello,

There seems to be some problems when using chan_sip with directmedia=yes and dtmfmode=info on asterisk 13.

Given I have two users, Alice and Bob
And Alice calls Bob (via Dial application, with no option)
And Bob answers
When Alice sends a *first* DTMF over SIP INFO
Then Bob does not receive it (i.e. asterisk doesn't sent it)
When Alice sends a *second* DTMF over SIP INFO
Then Bob receives the *first* DTMF, with a duration equals to the time between the first and second DTMF that asterisk received

What this means is that DTMF are not sent "promptly", the last DTMF is always missing, and the duration value of DTMF are unexpected.

I've attached a sip.conf, extensions.conf and an annoted output of the asterisk CLI with "sip set debug on" and DTMF log displayed.

As a note, this used to work correctly on asterisk 11.

Thank you
Comments:By: Asterisk Team (asteriskteam) 2015-06-30 11:19:46.373-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Etienne Lessard (hexanol) 2016-02-17 07:15:36.686-0600

For information, the bug also occurs with res_pjsip (tested with Asterisk 13.7.2).
By: Etienne Lessard (hexanol) 2016-02-17 12:09:40.092-0600

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.