Incorrect RFC2833 DTMF Payload Type Set on B-leg with Opus

[emaktech]

I have encountered what I believe to be a bug on FreeSWITCH 1.10.7.

Essentially, a call is bridged to the B-leg and established using the opus codec, RFC2833 DTMF payload type is negotiated incorrectly. e.g. FreeSWITCH will show somehting like Set 2833 dtmf send payload to 103 recv payload to 101

Further, if rfc2833-pt is set to 101 in the below example, it will be mismatched as above. If it is set to 103 in the below example, the telephone-event will not be negotiated at all (no DTMF possible). In the example below, this parameter is set to 101 in the SIP profile.

To Reproduce

1. Enable Opus codec on endpoints to be tested
2. Enable mod_opus with your preferred settings
3. Set inbound-late-negotiation to true in the SIP profile
4. Initiate a call and bridge it to the b-leg setting the codecs as follows:
   nolocal:absolute_codec_string=opus@8000h,PCMU

Local SDP will look something like this during negotiation:

Local SDP:
v=0
o=FreeSWITCH 1660642719 1660642720 IN IP4 25.225.10.100
s=FreeSWITCH
c=IN IP4 25.225.10.100
t=0 0
m=audio 22046 RTP/AVP 102 0 103 104 101 13
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=14000; maxplaybackrate=8000; sprop-maxcapturerate=8000; ptime=20; minptime=10; maxptime=120
a=rtpmap:0 PCMU/8000
**a=rtpmap:103 telephone-event/48000**
a=fmtp:103 0-15
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:104 CN/48000
a=rtpmap:13 CN/8000
a=ptime:20
a=sendrecv

Remote SDP will look something like this during negotiation:

2022-08-16 11:46:06.560088 98.97% [DEBUG] sofia.c:7509 Remote SDP:
v=0
o=- 20040 20041 IN IP4 192.168.0.196
s=SDP data
c=IN IP4 192.168.0.196
t=0 0
m=audio 11840 RTP/AVP 102 103
a=rtpmap:102 opus/48000/2
a=fmtp:102 sprop-maxcapturerate=48000; maxaveragebitrate=40000; maxplaybackrate=48000; useylrtx=1; useinbandfec=1
**a=rtpmap:103 telephone-event/48000**
a=fmtp:103 0-15
a=ptime:20

FreeSWITCH evaluates codecs and correctly chooses[ opus:102:48000:20:0:1]. It correctly identifies telephone-event payload numbers, but ultimately sets a different send payload and recv payload incorrectly:

2022-08-16 11:46:06.560088 98.97% [DEBUG] switch_core_media.c:5650 Audio Codec Compare [opus:102:48000:20:0:1]/[opus:116:48000:20:0:1]
2022-08-16 11:46:06.560088 98.97% [DEBUG] switch_core_media.c:5705 Audio Codec Compare [opus:116:48000:20:0:1] ++++ is saved as a match
2022-08-16 11:46:06.560088 98.97% [DEBUG] switch_core_media.c:5650 Audio Codec Compare [opus:102:48000:20:0:1]/[PCMU:0:8000:20:64000:1]
2022-08-16 11:46:06.560088 98.97% [DEBUG] switch_core_media.c:5566 Set telephone-event payload to 103@48000
2022-08-16 11:46:06.560088 98.97% [DEBUG] switch_core_media.c:5915 Set telephone-event payload to 103@48000
2022-08-16 11:46:06.560088 98.97% [DEBUG] switch_core_media.c:5973 sofia/internal_5090/200@192.168.0.196:12007 Set 2833 dtmf send payload to 103 recv payload to 101
2022-08-16 11:46:06.560088 98.97% [DEBUG] sofia.c:8524 Processing updated SDP

As a result, you cannot receive DTMF from the endpoint on the B-leg because FreeSWITCH is trying to receive with payload 101 but the remote endpoint clearly asked for payload 103 during negotiation.

Expected behavior

In the above example, the expected behavior would have been for FreeSWITCH to be correctly set to both receive and send payload 103 following negotiation, thus allowing DTMF to function correctly.

Package version or git hash

• Version 1.10.7

** Logs **
Full FreeSWITCH Debug Log:
opus-payload-type.txt

PCAP of call:
8a42d645-9834-123b-129b-d85ed3605f06.zip

[dragos-oancea]

did u try master branch ? this is probably fixed by:

commit 6c87ed491597fb5e30935d8309aa7e0c3aa9e18f
Author: Michael Jerris <mike@jerris.com>
Date:   Fri Dec 17 13:55:11 2021 -0700

    [Core] RFC 3264 says once we assign a payload number to a dynamic codec, we are stuck with it.
    
    8.3.1 Modifying Address, Port or Transport
    
       The port number for a stream MAY be changed.  To do this, the offerer
       creates a new media description, with the port number in the m line
       different from the corresponding stream in the previous SDP.  If only
       the port number is to be changed, the rest of the media stream
       description SHOULD remain unchanged.  The offerer MUST be prepared to
       receive media on both the old and new ports as soon as the offer is
       sent.  The offerer SHOULD NOT cease listening for media on the old
       port until the answer is received and media arrives on the new port.
       Doing so could result in loss of media during the transition.
    
    Co-authored-by: Anthony Minessale <anthm@signalwire.com>

[emaktech]

Hey @dragos-oancea thanks so much for your reply! I didn't mention it in my post, but I had actually also tested with that specific patch and behavior was the same.

For posterity's sake, I just compiled the current master branch and tested again and behavior is identical. e.g.

[DEBUG] switch_core_media.c:5986 sofia/internal/200@xxx.xxx.x.xxx:12345 Set 2833 dtmf send payload to 103 recv payload to 101

I won't re-post the entire log because it's completely identical on master in this regard to 1.10.7, unfortunately :(

[olofssonanton]

@emaktech Did you find any solution for this? We're suffering from what looks to be the same issue. Version 1.10.8

[vla2ka]

Hi! I have the same problem. Did you manage to solve it?

[olofssonanton]

@vla2ka try this PR #1979. It's been a while, but I believe that was our fix.

[shaunjstokes]

@olofssonanton @emaktech have you tested DTMF in your environments after transfer or 3-way conference?

We have the same issue but in our case inbound-late-negotiation is false and it only occurs when using Opus on blind transfer, attended transfer or 3-way conference. It affects multiple devices such as Zoiper, Yealink and Polycom. There's no change after applying PR #1979. There is another issue #1191 which is the same problem, when we set 'rfc2833-pt' on the internal SIP profile to 103 this resolves the problem on blind transfer and 3-way conference but it still occurs on attended transfer. We can workaround the problem by using hold\unhold from the device, this restores DTMF functionality but it's not a solution.

[shaunjstokes]

We still have issues with DTMF after transfer or 3-way conference on Opus calls, DTMF is now interrupted as audio payload. PR #1979 doesn't fix this issue. As a workaround we can enable liberal DTMF on the SIP profile then switch to SIP INFO on affected devices.

[thanhloi2603]

@shaunjstokes not sure if #2983 help you but it solved mine in #1191

[shaunjstokes]

We ended up switching to SIP INFO (out-of-band) DTMF as our default. In-band RFC2833 has proven too unreliable for VoIP — this payload type mismatch with Opus being one example, but we've also hit issues with codec transcoding paths mangling RFC2833 events and general endpoint interoperability problems around dynamic payload type negotiation.
For anyone else affected while this remains open:
SIP profile level:
<param name="dtmf-type" value="info"/>
Or per-leg in the dialplan:
<action application="set" data="dtmf_type=info"/>
SIP INFO has its own trade-offs (sent on the signalling path, so subject to SIP proxy handling quirks), but in practice it's been significantly more consistent for us, particularly with Opus and other wideband codecs.