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:45 | Date Closed: | |||
Priority: | Major | Regression? | |||
Status: | Open/New | Components: | Bridges/bridge_native_rtp Channels/chan_sip/General | ||
Versions: | 13.4.0 | Frequency of Occurrence | Constant | ||
Related Issues: |
| ||||
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. |