[webrtc-pc] Clarify a=rtpmap codec mappings should be offered even if the codec is not a preferred one (#2932)

henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== Clarify a=rtpmap codec mappings should be offered even if the codec is not a preferred one ==
My reading of [RFC3264, section 6.1](https://www.rfc-editor.org/rfc/rfc3264#section-6.1) leads me to believe that in sendrecv and recvonly use cases, the answerer has no choice but to have at least one receive codec that was in the offer. So even though it can add its own codecs, there has to be some codec in common between offerer and answerer.

In order to support unidirectional use cases (pc1 prefers X, pc2 prefers Y), pc1 has to list codec Y in the offer even though it is not in its preference list and has no intention of ever receiving it. In other words the `a=rtpmap` list of codecs is a separate list of codecs than the `a=audio/video` preference list.

Proposal: Add a NOTE under `setCodecPreferences` explaining that the preference list only affects the `a=audio/video` line, not which codecs get a PT. And we need test coverage that removing a codec from the preference list does not prevent it getting a PT.

IIUC...

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2932 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 2 February 2024 10:19:08 UTC