From bernard.aboba@gmail.com Wed Mar 20 10:08:54 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 2D5E1C14F6A0 for ; Wed, 20 Mar 2024 10:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nWN4Yr-bk-C7 for ; Wed, 20 Mar 2024 10:08:53 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 97FB4C14F617 for ; Wed, 20 Mar 2024 10:08:53 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1def142ae7bso51243145ad.3 for ; Wed, 20 Mar 2024 10:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710954533; x=1711559333; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=AKjlqMpx+fllkmHJGavDFUBlFT3MtrXtiAAVESp5F+c=; b=WWe4szojKco99DWo94ro+hp5qT1iscjk5DW7a7SPo10M1IDeS+daSjLPzJOiJrZ1IZ ECfV2JmEStxyk8aaUYf8pYSIsE0PCCYXGuiNfDuQv+lxnFnVmKI2ZhDPeAqgLAZqxosl zfJlWNXZlPbrnUe83ito8thvqCpUNR0h3lKKs2x7O+gJuXbdhEbuqcRKs6c2+ick4u7t /MzkuzkbsbESpeDYP0YKRs0nrSGPV+8s9LLzSfoYVN95hh/Rf7265RH0JiarC+S/MYQJ 3pMOqYeLZuAikXvR4WI/3nz6e5wF7pA7NFVikia5z53VMnsLXTCvpiHDq1G+sNCRBSsJ nKAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710954533; x=1711559333; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AKjlqMpx+fllkmHJGavDFUBlFT3MtrXtiAAVESp5F+c=; b=TTPXZ0YhWlcA+AIgPRUL5Kbf/pKRkKnIDAphCt526Fys9EqSnOIZ3LHAYAZZBUvRVv HPskecRZFkAbK3YU/52xLOXm98O5rde6YspQ13RvhzcXJ7IcyvBivJZGg6QAZWfPWrCX 3DbhCEAUnYUPy6qiqXrh7i6pmbWvJmjBp8xrzmzsY4m73NtliudP/SrpllK6RdXfRXjD jC8gIKJOdneShocKKlEgJWdEGtLQ2A7rtnhATH0a2uNXKA/odNnXcCE5ihQASKcM6fUh f0NuLFetBJqQdDnBmY4j95rEDsdNmCXCKG62Hep8+9hYWH1TtmO9CO6cub3ITM7km88w 1u9g== X-Forwarded-Encrypted: i=1; AJvYcCXdvwgXFRlvAMUCEy9jQf3K/UdF7OUU/I5420a/LX1iVUrqFRG3Zvsfs58kHLClb/1Whh0hQM8BgEH32/J8Og0= X-Gm-Message-State: AOJu0Yzpg3qGUV9CLVA/7qtMTar4aR1qcCL81oKdWUknVPwsjldpvlAN uIjhoLcZNQL3mJPJUI+h/ePUQxNUu854FdBJ0FwxJ+oXn0sF7IhR X-Google-Smtp-Source: AGHT+IElCDpPj9Fu1RianLg6si2+5yLrMFHPYx8JL1WbfiFGtqJzTYoLIieG9y0nCyXejOxGS8BEjw== X-Received: by 2002:a17:902:7842:b0:1e0:6351:ad94 with SMTP id e2-20020a170902784200b001e06351ad94mr1278155pln.36.1710954532347; Wed, 20 Mar 2024 10:08:52 -0700 (PDT) Received: from smtpclient.apple (c-73-254-166-200.hsd1.wa.comcast.net. [73.254.166.200]) by smtp.gmail.com with ESMTPSA id x9-20020a170902a38900b001e004924412sm8805148pla.108.2024.03.20.10.08.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Mar 2024 10:08:51 -0700 (PDT) From: Bernard Aboba X-Google-Original-From: Bernard Aboba Content-Type: multipart/alternative; boundary=Apple-Mail-4959098B-1B23-4363-BD91-A65CF8364570 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 20 Mar 2024 10:08:40 -0700 Message-Id: <7372DBF4-492F-47FC-9C7C-C1C55FAD282E@gmail.com> References: Cc: Justin Uberti , "Murray S. Kucherawy" , Harald Alvestrand , RTCWeb IETF , =?utf-8?Q?Henrik_Bostr=C3=B6m?= In-Reply-To: To: Christer Holmberg X-Mailer: iPad Mail (21E219) 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: Wed, 20 Mar 2024 17:08:54 -0000 --Apple-Mail-4959098B-1B23-4363-BD91-A65CF8364570 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The= problem is that for a send-only m-line, sCP does affect what codecs can be s= ent.

On Mar 20, 2024, at= 02:46, Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.= org> wrote:

=EF=BB=BF

Hi,<= /o:p>

 

In general, I don=E2=80= =99t think the spec should say whether something affects an implementation o= r not. How do we know what affects what in an implementation?

 

If we want to clarify something= , we could say something like =E2=80=9CsCP is not used to indicate which cod= ec an implementation shall send=E2=80=9D.

&nb= sp;

Also, maybe the statement that sCP only affects wha= t an implementation wants to receive should be in the first sentence of the s= ection? Now the sentence only talks about =E2=80=9Ccodec preference=E2=80=9D= , which I assume can cause confusion.

 <= /o:p>

Finally, if there is text somewhere that DOES define ho= w the implementation shall decide what codec to send, there could be a refer= ence.

 

Regards,

 

<= span lang=3D"EN-US" style=3D"mso-fareast-language:EN-US">Christer=

 

From: rtcw= eb <rtcweb-bounces@ietf.org> On Behalf Of Justin Uberti
S= ent: Wednesday, 20 March 2024 0.32
To: Murray S. Kucherawy <= ;superuser@gmail.com>
Cc: Harald Alvestrand <hta@google.com&= gt;; RTCWeb IETF <rtcweb@ietf.org>; Henrik Bostr=C3=B6m <hbos@googl= e.com>
Subject: Re: [rtcweb] JSEPbis: Questions about send-only= /recv-only codecs and Section 4.2.6

 

Some people who received this messa= ge don't often get email from justin=3D40fixie.ai@dmarc.ietf.org. Learn why this is important

<= div>

I don't think any changes are needed in RFC8= 829bis, I believe the text in S 4.2.6 is sufficient. 

 

If necessary though we could expound on the sentence in 4.2.6 that says= "Note that setCodecPreferences does not directly affect
   whi= ch codec the implementation decides to send" to make the intent clearer.

 

On Mon, Mar 18, 2024 at 4:54=E2=80=AFPM Murray S. Ku= cherawy <superuser@gmail.com&g= t; wrote:

On Mon, Mar 4, 2024 at 3:57=E2=80=AFPM= Justin Uberti <justin=3D40fixie.ai@dmarc.ietf.org> wrote:

=

The idea behind the text in red is an explicit callout to the f= act that the implementation may decide to use other mechanisms (e.g., RtcRtp= Sender.setParameters, CPU or bandwidth limitations, etc) to decide exactly w= hat should be sent over the wire.

 

Also, this API is in= tended to directly influence signaling, i.e., the set of codecs that are off= ered. It is not intended to directly control RtpSender settings.<= /p>

 

I agree with the point that the operation here may seem a bi= t weird for a sendonly m=3D line. That said, I think it is entirely consiste= nt with RFC 3264 S 5.1, where a) what is offered is primarily intended as a g= uide 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.<= /o:p>

 

<= p class=3D"MsoNormal">I think keeping sCP focused on what goes into the actu= al offer will make it easier to reason about this API.

<= /div>

 

Are there any required changes to RFC8829bis, which= is in AUTH48?

 

-MSK

_____________________________= __________________
rtcweb mailing list
rtcwe= b@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
= --Apple-Mail-4959098B-1B23-4363-BD91-A65CF8364570--