search

sipwise / rtpengine

The Sipwise media proxy for Kamailio
GNU General Public License v3.0
765 stars 362 forks source link

Picking wrong payload type when dealing with asymetric codecs #1750

Closed ehasting closed 8 months ago

ehasting commented 8 months ago

Hello,

I am implementing rtpengine with opensips and have seen some weird issues when i am dialing up to a UA that is not replying in the sdp with symmetric codec payload number (calling from a Cisco EX90 video device to WebEx).

Running master branch (also tried any of the releases, but the current result is from: 12.1.0.0+mr12.1.0.0)

in words what happen is that, endpoint dials to webex thru opensips, using rtpengine. first invite is good, then webex reply back with supported payload -however the numbers arnt matching (they seems to be hardcoded on webex side)

So ex90 sends 107 108 109 110, webex responds 97 Then the WebEx sends a RE-INVITE within 5 seconds of the call setup (content of the reinvite is the same as the 200 before).

However the rtpengine seems to be stuggle to map the payload number correctly together, and end up picking wrong codec at the end. (the a=rtpmap:101 telephone-event/8000)

The configuration i am sending in viav rtp_relay / rtpengine is: reuse-codecs generate-mid replace-SDP-version replace-origin replace-session-connection media-handover allow-asymmetric-codec ice=remove pad-crypto SDES-nonew SDES-pad SDES-lifetime DTLS=off

i have tried various variants - my current workaround is to disable the MP4A and Opus codecs, forcing it to land on G722 which are not dymamic payload number.

is this a bug, or can it be worked around?

EX90 -> WebEx (INVITE)

m=audio 2434 RTP/AVP 107 108 109 110 104 105 9 15 18 8 0 101 b=TIAS:128000 a=rtpmap:107 MP4A-LATM/90000 a=fmtp:107 profile-level-id=25;object=23;bitrate=128000 a=rtpmap:108 MP4A-LATM/90000 a=fmtp:108 profile-level-id=24;object=23;bitrate=64000 a=rtpmap:109 MP4A-LATM/90000 a=fmtp:109 profile-level-id=24;object=23;bitrate=56000 a=rtpmap:110 MP4A-LATM/90000 a=fmtp:110 profile-level-id=24;object=23;bitrate=48000 a=rtpmap:104 G7221/16000 a=fmtp:104 bitrate=32000 a=rtpmap:105 G7221/16000 a=fmtp:105 bitrate=24000 a=rtpmap:9 G722/8000 a=rtpmap:15 G728/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:uOcxzpZYnJ9b17WYpQAKU0OBwayWwNh5mLXZPdvW|2^48 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:uOcxzpZYnJ9b17WYpQAKU0OBwayWwNh5mLXZPdvW|2^48 UNENCRYPTED_SRTCP a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:gDURSkf8sYhrIDlq4+pkIpLnEkY5BfD9Ic2fDpDi|2^48 a=sendrecv

Post Proxy (rtpengine rewrite)

m=audio 48268 RTP/AVP 107 108 109 110 104 105 9 15 18 8 0 101 b=TIAS:128000 a=mid:1 a=rtpmap:107 MP4A-LATM/90000 a=fmtp:107 profile-level-id=25;object=23;bitrate=128000 a=rtpmap:108 MP4A-LATM/90000 a=fmtp:108 profile-level-id=24;object=23;bitrate=64000 a=rtpmap:109 MP4A-LATM/90000 a=fmtp:109 profile-level-id=24;object=23;bitrate=56000 a=rtpmap:110 MP4A-LATM/90000 a=fmtp:110 profile-level-id=24;object=23;bitrate=48000 a=rtpmap:104 G7221/16000 a=fmtp:104 bitrate=32000 a=rtpmap:105 G7221/16000 a=fmtp:105 bitrate=24000 a=rtpmap:9 G722/8000 a=rtpmap:15 G728/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:48269 a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:uOcxzpZYnJ9b17WYpQAKU0OBwayWwNh5mLXZPdvW|2^31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:uOcxzpZYnJ9b17WYpQAKU0OBwayWwNh5mLXZPdvW|2^31 UNENCRYPTED_SRTCP a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:gDURSkf8sYhrIDlq4+pkIpLnEkY5BfD9Ic2fDpDi|2^31

WebEx -> EX90 (200)

m=audio 50136 RTP/AVP 97 101 b=TIAS:64000 a=content:main a=sendrecv a=rtpmap:97 MP4A-LATM/90000 a=fmtp:97 bitrate=64000;profile-level-id=24;object=23 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp-fb:* ccm cisco-asn a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:74QlhCQxToA7rsNb3k1+9EORkrXwudOBHvYIDh7t a=label:100 a=mid:1

Post Proxy (rtpengine rewrite)

m=audio 59774 RTP/AVP 101 b=TIAS:64000 a=content:main a=rtcp-fb:* ccm cisco-asn a=label:100 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:59775 a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:74QlhCQxToA7rsNb3k1+9EORkrXwudOBHvYIDh7t|2^31

WebEx -> EX90 (RE-INVITE)

m=audio 50136 RTP/AVP 97 101 c=IN IP4 170.72.23.187 b=TIAS:64000 a=content:main a=sendrecv a=rtpmap:97 MP4A-LATM/90000 a=fmtp:97 bitrate=64000;profile-level-id=24;object=23 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp-fb:* ccm cisco-asn a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:74QlhCQxToA7rsNb3k1+9EORkrXwudOBHvYIDh7t a=label:100 a=mid:1

Post Proxy (rtpengine rewrite)

m=audio 59774 RTP/AVP 101 97 c=IN IP4 178.32.178.210 b=TIAS:64000 a=content:main a=rtcp-fb:* ccm cisco-asn a=label:100 a=mid:1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:97 MP4A-LATM/90000 a=fmtp:97 bitrate=64000;profile-level-id=24;object=23 a=sendrecv a=rtcp:59775 a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:74QlhCQxToA7rsNb3k1+9EORkrXwudOBHvYIDh7t|2^31

EX90 -> WebEx (200)

m=audio 2434 RTP/AVP 101 108 b=TIAS:64000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:108 MP4A-LATM/90000 a=fmtp:108 profile-level-id=24;object=23;bitrate=64000 a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:uOcxzpZYnJ9b17WYpQAKU0OBwayWwNh5mLXZPdvW|2^48 a=sendrecv

Post Proxy (rtpengine rewrite)

m=audio 48268 RTP/AVP 101 b=TIAS:64000 a=mid:1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:48269 a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:uOcxzpZYnJ9b17WYpQAKU0OBwayWwNh5mLXZPdvW|2^31

rfuchs commented 8 months ago

This isn't really supported. Codecs and payload types are expected to be negotiated and for this, the payload type numbers are expected to match. The option allow-asymmetric-codec only handles a specific case of mismatched payload type numbers when transcoding.