From roman@telurix.com Sat Mar 2 08:30:18 2024 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E09C151077 for ; Sat, 2 Mar 2024 08:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.105 X-Spam-Level: X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telurix.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUcA76BUtN6f for ; Sat, 2 Mar 2024 08:30:14 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432C0C151073 for ; Sat, 2 Mar 2024 08:30:14 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-513173e8191so3589285e87.1 for ; Sat, 02 Mar 2024 08:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; t=1709397011; x=1710001811; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WCKPrx4USyADZ80ODVHQT+wHYRAHdMkdNXnPRpNYHCA=; b=I6eLgX4c+IE99CW81pyxWJRdIp8jiIxKh4jst2bT/Y4/bsiSF3h5SPnjiXakfuYkTE 5taaGWa2r8KN3hz1yQOcrcukXsMR6h+khegLj6ayQ6o5eOr30Hn5gokA4Ji4d+YwfRSA H8bQlJVoHehFM+Iusf3jd4TJrXVHaK5Dkc5bY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709397011; x=1710001811; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WCKPrx4USyADZ80ODVHQT+wHYRAHdMkdNXnPRpNYHCA=; b=Hj7PLJKF7SlBzuuc8gLyu2Auj56Gdle+hG1NG1l0dTnCnEJ8B3E8n2pEOGWrVmFSGz f4CyIjHClS5EpMF5WBDFpZMX+qcFkeKYqoNDjkSi9CnsXsGz8N1tLlL6lvpymV3UbBfI 2fe4WMGzjqIoARgt52FXL/CLyU76rnRnlJ+ZbK2ttlo2A5MRMUz8/Z/yutz7uq1K6F9g MmGe11C2zBu9/xGV15w7ua9jcsHeKTZUBNUEfE5FmxQttoAFoOv/H68ilC3C+KoGb9/h UJRiD35h3AwVKdSsY/vZ6eAXiJFpeBefF98EyrRzDbpPdPe3SfIOv1k4tcHSsOgStNJD Eq6g== X-Forwarded-Encrypted: i=1; AJvYcCXz4CkJw54zC1wR5Hih5360IVRqlBqELFraDXmZ2QVv3U9zYAAADiei8QmFxNMTqjPfWKYbz3sIpO/FdzLba0o= X-Gm-Message-State: AOJu0YzjbXaHAYhXGM52S84iswU1fA8l2MwyZD+zoqeHjjaBgCejbezu Us0ORkSe6unVfrnMnsBEe1CM8VrjXdbmli6kYEMMCydLwt1gXKlYrKpUOBSyl3G+AfvIdPXVtR7 1 X-Google-Smtp-Source: AGHT+IFIFGb4oXhj+52pAmZ8rADAm+B5x9JnruA1AQ0TdnumzQtKOisn3zx8APDk8YFX04qNa4YogA== X-Received: by 2002:a05:6512:34c8:b0:512:ed33:c16 with SMTP id w8-20020a05651234c800b00512ed330c16mr3340952lfr.8.1709397011145; Sat, 02 Mar 2024 08:30:11 -0800 (PST) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id c8-20020a056512074800b005130d251b57sm1031937lfs.166.2024.03.02.08.30.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Mar 2024 08:30:11 -0800 (PST) Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2d180d6bd32so35842481fa.1 for ; Sat, 02 Mar 2024 08:30:10 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUu42FBz1nc66u89ASHD2EjaxWFsjh3J2075ecUls3WM1d0JigNIgSa/w9mQJGJwC5pIw4u44OnR/yLb0l3iNQ= X-Received: by 2002:a2e:b54e:0:b0:2d2:779d:3054 with SMTP id a14-20020a2eb54e000000b002d2779d3054mr3143960ljn.0.1709397010420; Sat, 02 Mar 2024 08:30:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Sat, 2 Mar 2024 11:29:58 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Bernard Aboba Cc: Harald Alvestrand , RTCWeb IETF , Philipp Hancke , =?UTF-8?Q?Henrik_Bostr=C3=B6m?= Content-Type: multipart/alternative; boundary="000000000000961dfc0612b00103" Archived-At: Subject: Re: [rtcweb] JSEPbis: Questions about send-only/recv-only codecs and Section 4.2.6 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2024 16:30:18 -0000 --000000000000961dfc0612b00103 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the main confusion here is that all preferences are defined for all "m=3D" line directions. For sendonly, setCodecPreferences should define what codecs are preferred to send and should only include codecs from RTCRtpSender.getCapabilities(kind). For recvonly, setCodecPreferences should define what codecs are preferred to receive and should only include codecs from RTCRtpReceiver.getCapabilities(kind). For sendrecv, setCodecPreferences should define what codecs are preferred to both send and receive and should only include codecs which a present in both RTCRtpSender.getCapabilities(kind) and RTCRtpReceiver.getCapabilities(kind). The last one is the most problematic since it conflicts with the current use cases. _____________ Roman Shpount On Sat, Mar 2, 2024 at 11:14=E2=80=AFAM Bernard Aboba wrote: > 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 > will > reject attempts to set codecs not matching > codecs found > in RTCRtpReceiver > .getCapabilities > (kin= d), > where kind is the kind of the RTCRtpTransceiver > ** on which the > method is called*. > > For a send-only m-line, does sCP really require a match to codecs found i= n > RTCRtpReceiver.getCapabilities(kind), or should it use > RTCRtpSender.getCapabilities(kind)? > > On Sat, Mar 2, 2024 at 4:29=E2=80=AFAM Harald Alvestrand = 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=E2=80=AFPM Bernard Aboba >> wrote: >> >>> The purpose of this email is to alert the RTCWEB WG to a potential issu= e >>> 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 multipl= e >>> browsers, including Chrome, Firefox and Safari. Safari Tech Preview 18= 9 >>> has enabled by default support for both sending and receiving H.265, wh= ile >>> Chrome and Firefox are working on enabling reception of H.265. This ha= s >>> lead to discussion of potential interoperability issues between browser= s >>> 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 t= he >>> associated "m=3D" section on future calls to createOffer and createAnsw= er. *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 m= ay >>> be correct with respect to operation of sCP() on a send/recv or recv-on= ly >>> m-line, for a send-only m-line it seems odd to insist that sCP() will o= nly >>> 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 >>> - >>> >>> w3c/webrtc-pc#2933 >>> - >>> >>> w3c/webrtc-pc#2935 >>> - >>> >>> w3c/webrtc-pc/#2888 >>> >>> _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000961dfc0612b00103 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the main confusion here is that all preferences ar= e defined for all "m=3D" line directions.

For = sendonly, setCodecPreferences should define what codecs are preferred to se= nd and should only include codecs from=C2=A0RTCRtpSender.getCapabilities(ki= nd).

For recvonly, setCodecPreferences should defi= ne what codecs are preferred to receive and should only include codecs from= =C2=A0RTCRtpReceiver.getCapabilities(kind).

For se= ndrecv,=C2=A0 setCodecPreferences should define what codecs are preferred to both send an= d receive and should only include codecs which a present in both=C2=A0 RTCRtpSender.getCapabilities(kind) and=C2=A0RTCRtpReceiver.getCapabilities(= kind).

The last one is the most problematic since = it conflicts with the current use cases.
_____________
Roman Shpo= unt


On Sat, Mar 2, 2024 at 11:14=E2=80=AFAM Bernard Ab= oba <bernard.aboba@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">The text in WebRTC-PC also includes statements about sCP() = that do not seem to apply to the send-only case. For=C2=A0example, in Secti= on 5.4:=C2=A0

setCodecPreferences=C2=A0will re= ject attempts to set=C2=A0codecs=C2=A0not matching=C2=A0codecs found in=C2=A0RTCRtpReceiver.getCapabilities(kind), where= =C2=A0kind=C2=A0is the kind of the=C2=A0RTCRtpTransceiver=C2=A0on which the method is= called.

For a send-only m-line, does sCP really r= equire a match to codecs found in RTCRtpReceiver.getCapabilities(kind), or = should it use RTCRtpSender.getCapabilities(kind)?=C2=A0=C2=A0
<= /div>
O= n Sat, Mar 2, 2024 at 4:29=E2=80=AFAM Harald Alvestrand <hta@google.com> wrote:
At= tempting to reflect my current understanding:

The only = way I can interpret the current text in a sensible manner is to focus on th= e word "directly" - given that the text on processing the prefere= nce list also says that if the responder has no preference, the codecs in t= he sendonly media section's preference list should be interpreted as &q= uot;the codecs that the offerer wishes that the responder should respond wi= th 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=E2=80=AFPM Bernard Aboba <= bernard.aboba@= gmail.com> wrote:
The purpose of this email is to alert the = RTCWEB WG to a potential issue that has been pointed out in JSEPbis=C2=A0Se= ction 4.2.6, with respect to the operation of setCodecPreferences().=C2=A0<= /div>

Currently, support for the H.265 codec in WebRTC is und= erway in multiple browsers, including Chrome, Firefox and Safari.=C2=A0 Saf= ari Tech Preview 189 has enabled by default support for both sending and re= ceiving H.265, while Chrome and Firefox are working on enabling reception o= f H.265.=C2=A0 This has lead to discussion of potential interoperability is= sues between browsers that can Offer H.265 on a send/recv m-line, and brows= ers that can only Offer H.265 on a recv-only m-line.=C2=A0

At the AVTCORE WG Virtual Interim on February 13, 2024, we discussed=C2= =A0Issue 22 relating to the handling of send-only and recv-only codecs:=C2= =A0
draft-uberti-rtcweb-rfc8829bis Section 4.2.6 says:=C2=A0

"The setCodecPref= erences method sets the codec preferences of a transceiver, which in turn a= ffect the presence and order of codecs of the associated "m=3D" s= ection on future calls to createOffer and createAnswer.=C2=A0 Note that setCodecPreferences d= oes not directly affect which codec the implementation decides to send. It = only affects which codecs the implementation indicates that it prefers to r= eceive, via the offer or answer.= =C2=A0 Even when a codec is excluded by setCodecPreferences, it still m= ay 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 partic= ular, 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 insi= st 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():
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000961dfc0612b00103--