Dynamic payload type in sdp processing error

[continued-cn]

As mentioned above. When FS dial out a device， dynamic payload type appears in SDP especially when there has video. A serious error occurred when FS encountered inconsistent sent and received payload types. For example, the FS declares that the h264 rtp payload is 103 in the sdp signaling of the calling counterpart, and the counterpart responds that the h264 payload is 110 in the sdp signaling. Then the counterpart send rtp data with 103 payload type, but FS rejected. Later I researched relevant code and found that this is not a simple problem, but that FS has an error in understanding of payload sent and received during media negotiation. As it involves a wide range, I am not able to list them one by one. Could you study the handling of the payload in switch_core_media and rtp_session thanks a lot !

[seven1240]

Please try the latest master and upload any logs and/or pcap so we can look.

[jimdoesvoip]

@seven1240 we see something similar with FS on a call into FS where there is a dynamic type in the inbound SDP, FS responds with that same p-type, but in the logs we see that it is looking for DTMF with the standard p-type.

This is what the SDP looks like: 10:57 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f 2020-04-28 13:19:45.459270 [DEBUG] sofia.c:7312 Remote SDP: df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f v=0 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f o=Sonus_UAC 2028347824 493821194 IN IP4 216.86.41.7 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f s=SIP Media Capabilities df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f t=0 0 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f m=audio 63894 RTP/AVP 0 18 127 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f c=IN IP4 216.86.41.4 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=rtpmap:0 PCMU/8000 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=rtpmap:18 G729/8000 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=fmtp:18 annexb=no df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=rtpmap:127 telephone-event/8000 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=fmtp:127 0-15 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=maxptime:20 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f m=video 0 RTP/AVP 109 34 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f c=IN IP4 0.0.0.0 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f (edited) 10:58 In the log we see these interesting lines: 10:58 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f 2020-04-28 13:19:45.479259 [DEBUG] switch_core_media.c:8908 sofia/external/+15029152555@216.86.41.7(opens in new tab) Set 2833 dtmf send payload to 127 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f 2020-04-28 13:19:45.479259 [DEBUG] switch_core_media.c:8915 sofia/external/+15029152555@216.86.41.7(opens in new tab) Set 2833 dtmf receive payload to 101 10:58 And then we see the FS SDP on its way back to sonus: 10:58 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f 2020-04-28 13:19:45.479259 [DEBUG] mod_sofia.c:905 Local SDP sofia/external/+15029152555@216.86.41.7(opens in new tab): df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f v=0 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f o=FreeSWITCH 1588077163 1588077164 IN IP4 216.86.42.101 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f s=FreeSWITCH df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f c=IN IP4 216.86.42.101 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f t=0 0 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f m=audio 17222 RTP/AVP 0 127 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=rtpmap:0 PCMU/8000 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=rtpmap:127 telephone-event/8000 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=fmtp:127 0-16 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=ptime:20 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=sendrecv df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f a=rtcp:17223 IN IP4 216.86.42.101 df2dcbdf-bb1d-44b8-bd62-a2e7069ead9f 10:58 After this FS doesn’t detect any DTMF from the RTP stream from sonus.

[anandpaithankar1]

I am also seeing this issue - Here is my SDP Offer and Answer

Offer SDP -

v=0
   o=WH 1588925731 1588925732 IN IP4 10.1.5.167
   s=WH
   c=IN IP4 10.1.5.167
   t=0 0
   m=audio 29030 RTP/AVP 102 0 8 3 105 101
   a=rtpmap:102 opus/48000/2
   a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:3 GSM/8000
   a=rtpmap:105 telephone-event/48000
   a=fmtp:105 0-16
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=ptime:20

Answer SDP -

  v=0
   o=FE 104085 104085 IN IP4 204.141.30.65
   s=FE
   c=IN IP4 204.141.30.65
   b=AS:1920
   t=0 0
   m=audio 3192 RTP/AVP 114 9 0 8 101
   b=TIAS:64000
   a=rtpmap:114 opus/48000/2
   a=fmtp:114 maxaveragebitrate=64000;stereo=1
   a=rtpmap:9 G722/8000
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
   a=sendrecv

For Opus, there is only one-way audio from Offerer to Answerer but not the other way around. There is two-way audio, if the negotiated codec is G711 (static PT). This problem can also be seen for video codecs.

I guess the problem could be with following code... For write_codec.agreed_pt should be recv_pt (or what was offered by far-end PT)

switch_core_media.c 

    a_engine->write_codec.agreed_pt = a_engine->cur_payload_map->pt;
    a_engine->read_codec.agreed_pt = a_engine->cur_payload_map->pt;

        ...

       v_engine->write_codec.agreed_pt = v_engine->cur_payload_map->pt;
       v_engine->read_codec.agreed_pt = v_engine->cur_payload_map->pt;

[Bucky101]

I believe I may be seeing something similar. I recieve rtp dtmf type 102

    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): - 422535658 620232604 IN IP4 x.x.x.x
            Session Name (s): -
            Connection Information (c): IN IP4 y.y.y.y
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 59296 RTP/AVP 8 102
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): rtpmap:102 telephone-event/8000
            Media Attribute (a): fmtp:102 0-15
            [Generated Call-ID: a22a98d0077e951e142c450814da5819@SoftX3000]

And respond

Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): FreeSWITCH 1631666206 1631666207 IN IP4 y.y.y.y
    Session Name (s): FreeSWITCH
    Connection Information (c): IN IP4 x.x.x.x
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 31912 RTP/AVP 8 102
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): rtpmap:102 telephone-event/8000
    Media Attribute (a): fmtp:102 0-16
    Media Attribute (a): ptime:20
    [Generated Call-ID: a22a98d0077e951e142c450814da5819@SoftX3000]

FS Version 1.10.1 -1 64bit does not bridge the recieved dynamic RTP and so DTMF does not work

Real-Time Transport Protocol
    [Stream setup by SDP (frame 40847)]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    1... .... = Marker: True
    Payload type: DynamicRTP-Type-101 (101)
    Sequence number: 3417
    [Extended sequence number: 68953]
    Timestamp: 321433580
    Synchronization Source identifier: 0x00310013 (3211283)

[progcxw]

I have the same problem. On my b-leg, Freeswitch set 2833 dtmf send payload to 105, but Set 2833 dtmf receive payload to 101. For nearly one minute it can't detect any dtmf. Is there anybody know how to solve it?

[progcxw]

And here is my freeswitch console log: fsdtmflog.md

[progcxw]

I modified the 'rfc2833-pt' in sip_profiles/internal.xml to '105', and it worked for me.

[dragos-oancea]

can you test current master ? 6c87ed491597fb5e30935d8309aa7e0c3aa9e18f possibly fixes it.