rfuchs
commented
5 months ago This has been asked several times before and should have been sent to the mailing list, not the GH issue tracker.
Answer codecs and their numbering are expected to match the codecs that were offered. But you can try adding allow-asymmetric-codecs and see if that helps.
Hi,
We have an issue with codecs using dynamic payload types. The scenario is one client sending an offer with a dynamic pt codec and the answer containing the same codec but using a different dynamic pt.
According to IETF RFC 3264 section 6.1 "In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer." Since this is not a MUST you are allowed to signal the same codec with a different payload type in the answer (obviously only relevant for dynamic pt). However, our problem is that when anchoring the RTP stream through RTPengine those codecs are stripped away with the log entry
[codec] Not adding stray answer codec opus/48000/2 (97)An example of this offer/answer below:
[1706878602.608671] DEBUG: [391234@54.74.170.234]: [control] Dump for 'offer' from 10.85.166.86:48536: { "DTLS": "active", "DTLS-fingerprint": "SHA-256", "ICE": "default", "SDES": [ "no" ], "call-id": "391234@54.74.170.234", "command": "offer", "from-tag": "391234", "metadata": "{"domain":""}", "replace": [ "origin", "session-connection" ], "rtcp-mux": [ "accept", "offer" ], "sdp": "v=0
o =user-0.ip-10-85-166-86.eu-west-1.compute.internal-1706878602592 1706878602592 1706878600714 IN IP4 54.74.170.234 s=Talk
c=IN IP4 54.74.170.234
t=0 0
a=group:BUNDLE as
a=rtcp-xr:rcvr-rtt=all:31000 stat-summary=loss,dup,jitt,TTL voip-metrics
a=record:off
m=audio 31000 RTP/AVP 96 0 8
c=IN IP4 54.74.170.234
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtcp:31000
a=rtcp-fb: trr-int 1000
a=rtcp-fb: ccm tmmbr
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=mid:as
a=rtcp-mux
, "transport-protocol": "UDP/TLS/RTP/SAVPF" }
[1706878602.624005] DEBUG: [391234@54.74.170.234]: [control] Dump for 'answer' from 10.85.166.86:46729: { "call-id": "391234@54.74.170.234", "command": "answer", "from-tag": "391234", "replace": [ "origin", "session-connection" ], "sdp": "v=0 o=- 1804489028204583686 2 IN IP4 54.74.170.234 s=- t=0 0 a=msid-semantic: WMS 702093cf-7409-47bd-bac3-5253af45b414 m=audio 30000 UDP/TLS/RTP/SAVPF 97 0 8 c=IN IP4 54.74.170.234 a=rtpmap:97 opus/48000/2 a=fmtp:97 minptime=10;useinbandfec=1 a=rtcp:9 IN IP4 0.0.0.0 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=setup:active a=mid:as a=msid:702093cf-7409-47bd-bac3-5253af45b414 e7af9e6d-2214-4d89-b2be-0669f5f2a2b9 a=sendrecv a=fingerprint:sha-256 6F:BD:FA:91:2E:95:2A:EE:C3:B1:75:C8:1A:C2:4C:87:FB:34:CE:03:10:B1:51:72:F8:FB:6F:8D:9D:FD:DF:F1 a=rtcp-mux ", "to-tag": "94072", "transport-protocol": "RTP/AVP" }
Generating the logs [1706878602.624058] DEBUG: [391234@54.74.170.234]: [core] Using default bitrate of 32000 bps for 2-channel Opus [1706878602.624088] DEBUG: [391234@54.74.170.234]: [core] Unconfirming peer address for local 10.85.166.143:33330 [1706878602.624094] DEBUG: [391234@54.74.170.234]: [core] Unconfirming peer address for local 10.85.166.143:33338 1706878602.624101] DEBUG: [391234@54.74.170.234]: [core] Unconfirming peer address for local 10.85.166.143:33331 [1706878602.624113] DEBUG: [391234@54.74.170.234]: [core] Unconfirming peer address for local 10.85.166.143:0 [1706878602.624147] DEBUG: [391234@54.74.170.234]: [core] Unsubscribing '391234' from '94072' [1706878602.624153] DEBUG: [391234@54.74.170.234]: [core] Unsubscribing '94072' from '391234' [1706878602.624158] DEBUG: [391234@54.74.170.234]: [core] Subscribing '94072' to '391234' [1706878602.624163] DEBUG: [391234@54.74.170.234]: [core] Subscribing '391234' to '94072' [1706878602.624204] DEBUG: [391234@54.74.170.234]: [codec] Updating codecs for answerer 94072 #1 [1706878602.624210] DEBUG: [391234@54.74.170.234]: [codec] Not adding stray answer codec opus/48000/2 (97)
Is there a way to keep the removed OPUS codec although using a different dynamic pt? Obviously RTPengine recognises the codec. We have seen this behaviour also for other codecs using dynamic pt.
Please excuse if this is mentioned somewhere but I have looked through examples and documentation without finding any relevant configuration for this.
Thanks in advance /Carl