IETF Logo Mail Archive

Re: [Wish] WG Last Call for draft-ietf-wish-whip

Bernard Aboba <bernard.aboba@gmail.com> Fri, 10 March 2023 12:55 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659EAC17B334 for <wish@ietfa.amsl.com>; Fri, 10 Mar 2023 04:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Ub3pebLaDQrj for <wish@ietfa.amsl.com>; Fri, 10 Mar 2023 04:55:13 -0800 (PST)
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 B99D7C151539 for <wish@ietf.org>; Fri, 10 Mar 2023 04:55:13 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id n6so5432461plf.5 for <wish@ietf.org>; Fri, 10 Mar 2023 04:55:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678452913; 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=X+7xd4kACKosH0cZzcuG59UrdNCEDuQvVNEa8pN+W2w=; b=cAKI42GiYBV0S84k9EZfdQRFtU0wbX4OLiLMAT4E3RZsDaTL2S1pH/h8bTqZXGlj89 ur8tZA0NTNz9GEj877D+qQpIpK+t3Bq7knXijCYpqDx5irHa+GDRLC7mJNpcyPMez7hK 83tWGraA2i2efQSGS833L7DtYnmqiFdxf9yguFjtgxutwRBcGkvmVmcTJTsm8Bx7XgPr t2YfFTRF62dfNwiP75V4sI8gfZLHa5vGbUs5Obu3A0Nd+cSs46KDHUu+qrDtAWVbzf1r oM8Fc0sFhGmmmYt5yWGB7Xi03SnuaMSSxMRz7QV2JE/XrvbK01BLf759AzI2KzN0h79Y vQtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678452913; 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=X+7xd4kACKosH0cZzcuG59UrdNCEDuQvVNEa8pN+W2w=; b=dzdRoYp02E4CMZjjXa69g5csTosUyc6GQhAVeYP2zHKcLS7bpFgddRwcbmwbaiuuig X15uaCo/QJrDxBfJhZZQzcz110a5bjDkqWI2dv6y8iWukRCmW3XZBeeDRYS5QCc4ORce 6YeJyn1zfPbFi1HAAcm64zuEDUbS9AJ58uMaS4mOhkGTBXKJbE6aVeNcRpdA7DZi9HiQ yhL9kACx9sI8w/m5N5xCuk37bHCaMnJt/GLR2gYNVltYHfxi+1qPMra25uLvLwcNtxIM diSuAlRy59xMJvjRIbSpDLpOChnJOPFUE2yJtUxkuWjV7WgbI+y7oLlT+uR4ZG2Rvi10 jSjA==
X-Gm-Message-State: AO0yUKUyTsgwqimsRaPCgKsNly/kZ6E3XJ1epG6EtUiWDNODyteaQb7v vgaASI77JMc8LQLQDYwvK3dO+UpdipxMhLJ6
X-Google-Smtp-Source: AK7set8rHrMCy+Mmj+V4fMvoM9Ia+y38uUkKXT4e6DXW+lTpnlImiWc7+v5sCxXM4xFbuDC+7RQwnw==
X-Received: by 2002:a17:902:ea11:b0:194:cc66:66f7 with SMTP id s17-20020a170902ea1100b00194cc6666f7mr31102092plg.19.1678452912461; Fri, 10 Mar 2023 04:55:12 -0800 (PST)
Received: from smtpclient.apple (c-24-16-156-188.hsd1.wa.comcast.net. [24.16.156.188]) by smtp.gmail.com with ESMTPSA id p16-20020a170902ebd000b001994e74c094sm1368861plg.275.2023.03.10.04.55.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Mar 2023 04:55:11 -0800 (PST)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Google-Original-From: Bernard Aboba <Bernard.Aboba@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Mar 2023 04:55:00 -0800
Message-Id: <FED76C80-A6A2-42E9-B6FA-D96BF2D90A7A@gmail.com>
References: <CA+ag07aaZKjXzeZ0aOpLx8WtPqUOrgsTWLjia8wMLAsudBrOzg@mail.gmail.com>
Cc: Sean Turner <sean@sn3rd.com>, WISH List <wish@ietf.org>
In-Reply-To: <CA+ag07aaZKjXzeZ0aOpLx8WtPqUOrgsTWLjia8wMLAsudBrOzg@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
X-Mailer: iPad Mail (20D67)
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/EjIDC9zJkZ_efPA5oNh93wzhOmk>
Subject: Re: [Wish] WG Last Call for draft-ietf-wish-whip
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wish>, <mailto:wish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish/>
List-Post: <mailto:wish@ietf.org>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wish>, <mailto:wish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2023 12:55:14 -0000

On Mar 10, 2023, at 01:47, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
> 
> Yes, but that is already specified in rfc8853, right? We do not really need to add anything else to the whip spec. 

[BA] The combination of RFC 8853 and the restrictions in WHIP do seem to cover it, yes.  There are things allowed by RFC 8853 (increasing the number of simulcast streams after initial negotiation) that are allowed by the API or are not implemented in libwebrtc, but I believe that the WHIP prohibition on re-negotiation covers them.

> Scalable Video Coding (SVC) MAY also be supported both by the Media Servers and WHIP clients. However, there is no universal negotiation mechanism in (SDP) for SVC, as a result, SVC support must be addressed on a codec-by-codec basis and taking into account the intended usage and SVC decoder support.
> 
> What do you think?

[BA] I’m not sure what you mean by “addressed on a codec-by-codec basis”.   SDP O/A handles codec negotiation, and that plus SVC support in the decoder of the chosen codec(s) will constrain the ability to utilize SVC. 

 Perhaps “as a result, configuration of SVC on the encoder needs to take into account the negotiated codec(s), taking into account the intended usage and SVC support in the decoder.”

v2.23.0 | Report a Bug | By Email