[Home]

Summary:ASTERISK-29051: res_pjsip_sdp_rtp: Does not set correct values on RTP instance when "auto" DTMF is used
Reporter:Sebastian Damm (sdamm)Labels:
Date Opened:2020-08-28 04:31:09Date Closed:2020-09-30 07:06:38
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip_sdp_rtp
Versions:17.6.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Debian BusterAttachments:( 0) alltraffic.pcap
( 1) asterisk.log
( 2) asterisk-nocolor.log
Description:When bridging two call legs where one leg supports rfc4733 events and the other leg does not, DTMF tones don't get converted. This is because Asterisk enters native bridge if codecs are equal and then has no chance to detect anything inside the rtp stream. When transcoding from one codec to another, Asterisk stays in simple bridge, and it should behave the same way if dtmf modes differ.

To reproduce: Set dtmf_mode to "auto" in the endpoint settings in pjsip.conf. Send a call from a client only supporting inband DTMF to the Asterisk, send this call to another client supporting telephone-events. Then send DTMF digits from the calling device. They will end up inband on the receiving client. However, if the receiving client is for example another Asterisk, it will not look into the audio if the SDP offered telephone-event. DTMF digits will not be recognized.
Comments:By: Asterisk Team (asteriskteam) 2020-08-28 04:31:10.867-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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

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].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

By: Joshua C. Colp (jcolp) 2020-08-28 04:37:20.625-0500

Please attach the SIP trace so the full negotiation can be seen and confirmed. An actual console log would also help to confirm which type of bridge you are referring to, as there are two.

By: Sebastian Damm (sdamm) 2020-08-28 05:42:20.598-0500

Attached is the traffic as seen from the client side, and an Asterisk log with extended debugging enabled. You can see that "native_bridge" gets chosen for this call.

By: Joshua C. Colp (jcolp) 2020-08-28 06:09:28.951-0500

The problem is not with the bridging layer, but res_pjsip_sdp_rtp. It does not appear to be setting the correct information on the RTP instance when "auto" DTMF is used resulting in the logic that determines DTMF compatibility believing they are compatible.

By: Alexander Traud (traud) 2020-09-15 10:56:22.751-0500

Anyone working on this already? I face a similar symptom with native bridge and consider to look into it. My issue has a complete different cause as it is not about different DTMF methods but a compatible but [different audio codec …|https://github.com/traud/asterisk-amr/issues/10] Therefore, an idea for a short-term fix: Is it possible to instruct Asterisk to transcode always, go for simple bridge instead? Not aware of. Anyone interested in that approach, as a short-term fix?

By: Sean Bright (seanbright) 2020-09-16 14:06:15.582-0500

Same asterisk.log but with ANSI color stuff stripped out

By: Holger Hans Peter Freyther (zecke) 2020-09-22 23:25:07.309-0500

Thanks Joshua for pointing me into the right direction. I don't fully understand how the AST_RTP_PROPERTY_DTMF and dtmf_mode_set interact but clearing the property for the channel that doesn't have telephone-event in the SDP file makes them incompatible (from the asterisk rtp engine and native bridge support).

I also updated two more places in get_codecs in case there is a re-invite and the telephone-event will show up int he SDP file. Please take a look if I got it right.

By: Friendly Automation (friendly-automation) 2020-09-30 07:06:39.816-0500

Change 15004 merged by Friendly Automation:
res_pjsip_sdp_rtp: Fix accidentally native bridging calls

[https://gerrit.asterisk.org/c/asterisk/+/15004|https://gerrit.asterisk.org/c/asterisk/+/15004]

By: Friendly Automation (friendly-automation) 2020-09-30 07:10:05.833-0500

Change 15001 merged by Friendly Automation:
res_pjsip_sdp_rtp: Fix accidentally native bridging calls

[https://gerrit.asterisk.org/c/asterisk/+/15001|https://gerrit.asterisk.org/c/asterisk/+/15001]

By: Friendly Automation (friendly-automation) 2020-09-30 07:11:02.206-0500

Change 14934 merged by Friendly Automation:
res_pjsip_sdp_rtp: Fix accidentally native bridging calls

[https://gerrit.asterisk.org/c/asterisk/+/14934|https://gerrit.asterisk.org/c/asterisk/+/14934]

By: Friendly Automation (friendly-automation) 2020-09-30 08:22:39.672-0500

Change 15002 merged by George Joseph:
res_pjsip_sdp_rtp: Fix accidentally native bridging calls

[https://gerrit.asterisk.org/c/asterisk/+/15002|https://gerrit.asterisk.org/c/asterisk/+/15002]

By: Friendly Automation (friendly-automation) 2020-10-01 07:07:30.945-0500

Change 15003 merged by George Joseph:
res_pjsip_sdp_rtp: Fix accidentally native bridging calls

[https://gerrit.asterisk.org/c/asterisk/+/15003|https://gerrit.asterisk.org/c/asterisk/+/15003]