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/[email protected]: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 <[email protected]>
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 <[email protected]>

[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/[email protected]: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