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

[Bernard Aboba <[e-mail]>]

The text in WebRTC-PC also includes statements about sCP() that do not seem
to apply to the send-only case. For example, in Section 5.4:

*setCodecPreferences
<https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-setcodecpreferences>
will
reject attempts to set codecs not matching
<https://w3c.github.io/webrtc-pc/#dfn-codec-match> codecs found
in RTCRtpReceiver
<https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver>.getCapabilities
<https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getcapabilities>(kind),
where kind is the kind of the RTCRtpTransceiver
<https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver>** on which the
method is called*.

For a send-only m-line, does sCP really require a match to codecs found in
RTCRtpReceiver.getCapabilities(kind), or should it use
RTCRtpSender.getCapabilities(kind)?

On Sat, Mar 2, 2024 at 4:29 AM Harald Alvestrand <[e-mail]> wrote:

> 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>
>>
>>