- From: Roman Shpount via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Apr 2024 18:43:06 +0000
- To: public-webrtc-logs@w3.org
@stefhak I am saying that the procedure for asymmetric codecs in sendrecv line is not defined in RFC 9429. Implementing asymmetric codecs on a sendrecv line using RFC 3264 is possible. To do this, the offerer will send codecs "A B" in the offer, and the answerer will send codecs "B A" in the answer. This will imply that the offerer prefers to receive A, but B is also supported, and that the answerer prefers to receive B, but A is also supported. This might need an additional nudge outside of the offer/answer to force using different codecs in both directions and to signal that the offerer cannot receive B or that the answerer cannot receive A. Based on the above, what is missing is an API that specifies that two codecs should be left in the answer. sCP can be used to control their order and signal which codec the answerer prefers to receive, but the mechanism that specifies that the codecs should be present in the answer is missing. Furthermore, per RFC 3264, it is possible to have codecs in the answer, which were not present in the offer. I am not sure of the API to add codecs in the answer which were not present in the offer (apart from SDP manipulation). -- GitHub Notification of comment by rshpount Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2937#issuecomment-2073174203 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 23 April 2024 18:43:06 UTC