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

[Philipp Hancke <[e-mail]>]

I believe there are two reasons the current text says "not directly":
1/ the answerer will attempt to match the senders order of media formats:
"Otherwise, the media formats on the "m=" line MUST be generated in the
same order as those offered in the current remote description," (section
5.3.1, assuming sCP it not used at the receiver).
2/ the initial answerer may generate a subsequent offer which leads us to
"the media formats on the "m=" line MUST be generated in the same order as
in the most recent answer" (section 5.2.2; note: the most recent answer is
the current local description)

The order or choice of codecs in (1) does not seem to matter until the
initial answerer changes the direction and creates a subsequent offer the
order of media formats on the formerly sendonly m-line would matter.

Am Sa., 2. März 2024 um 17:14 Uhr schrieb 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>
>>>
>>>