Re: [rtcweb] JSEPbis: Questions about send-only/recv-only codecs and Section 4.2.6

[Harald Alvestrand <[e-mail]>]

Attempting to reflect my current understanding:

The only way I can interpret the current text in a sensible manner is to
focus on the word "directly" - given that the text on processing the
preference list also says that if the responder has no preference, the
codecs in the sendonly media section's preference list should be
interpreted as "the codecs that the offerer wishes that the responder
should respond with as their preference, if they can receive them".

This *indirectly* influences the choice of codecs, since the receiver's
response will limit the sender's selection of what to send.




On Fri, Mar 1, 2024 at 9:00 PM Bernard Aboba <[e-mail]>
wrote:

> The purpose of this email is to alert the RTCWEB WG to a potential issue
> that has been pointed out in JSEPbis Section 4.2.6, with respect to the
> operation of setCodecPreferences().
>
> Currently, support for the H.265 codec in WebRTC is underway in multiple
> browsers, including Chrome, Firefox and Safari.  Safari Tech Preview 189
> has enabled by default support for both sending and receiving H.265, while
> Chrome and Firefox are working on enabling reception of H.265.  This has
> lead to discussion of potential interoperability issues between browsers
> that can Offer H.265 on a send/recv m-line, and browsers that can only
> Offer H.265 on a recv-only m-line.
>
> At the AVTCORE WG Virtual Interim on February 13, 2024, we discussed Issue
> 22 relating to the handling of send-only and recv-only codecs:
> https://github.com/aboba/hevc-webrtc/issues/22
>
> draft-uberti-rtcweb-rfc8829bis Section 4.2.6 says:
>
> "The setCodecPreferences method sets the codec preferences of a
> transceiver, which in turn affect the presence and order of codecs of the
> associated "m=" section on future calls to createOffer and createAnswer.  *Note
> that setCodecPreferences does not directly affect which codec the
> implementation decides to send. It only affects which codecs the
> implementation indicates that it prefers to receive, via the offer or
> answer.*  Even when a codec is excluded by setCodecPreferences, it still
> may be used to send until the next offer/answer exchange discards it."
>
> Questions arose relating to the (red) text in italics, because it does not
> appear to be consistent with the definition of setCodecPreferences() within
> the WebRTC-PC API specification. In particular, while the text may be
> correct with respect to operation of sCP() on a send/recv or recv-only
> m-line, for a send-only m-line it seems odd to insist that sCP() will only
> affect receive preferences, not send preferences.
>
> Currently within the W3C WEBRTC WG, several issues have been opened
> relating to the behavior of setCodecPreferences():
>
>    -
>
>    w3c/webrtc-pc#2936 <https://github.com/w3c/webrtc-pc/issues/2936>
>    -
>
>    w3c/webrtc-pc#2933 <https://github.com/w3c/webrtc-pc/issues/2933>
>    -
>
>    w3c/webrtc-pc#2935 <https://github.com/w3c/webrtc-pc/pull/2935>
>    -
>
>    w3c/webrtc-pc/#2888 <https://github.com/w3c/webrtc-pc/issues/2888>
>
>