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

[Justin Uberti <[e-mail]>]

The idea behind the text in red is an explicit callout to the fact that the
implementation may decide to use other mechanisms (e.g.,
RtcRtpSender.setParameters, CPU or bandwidth limitations, etc) to decide
exactly what should be sent over the wire.

Also, this API is intended to directly influence signaling, i.e., the set
of codecs that are offered. It is not intended to directly control
RtpSender settings.

I agree with the point that the operation here may seem a bit weird for a
sendonly m= line. That said, I think it is entirely consistent with RFC
3264 S 5.1, where a) what is offered is primarily intended as a guide for
what the answerer will actually send and b) the answerer may choose to send
whatever it wants as long as it uses a format from the offer.

I think keeping sCP focused on what goes into the actual offer will make it
easier to reason about this API.

On Sat, Mar 2, 2024 at 8:31 AM Philipp Hancke <philipp.hancke=
[e-mail]> wrote:

> 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>
>>>>
>>>> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>