From nobody Tue Oct 26 10:15:31 2021 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 2DD443A15E7 for ; Tue, 26 Oct 2021 10:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvZxS6vTxns7 for ; Tue, 26 Oct 2021 10:15:21 -0700 (PDT) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5243A15DB for ; Tue, 26 Oct 2021 10:15:19 -0700 (PDT) Received: by mail-il1-f180.google.com with SMTP id j10so21868ilu.2 for ; Tue, 26 Oct 2021 10:15:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yOUpJWydJhXBvoMqTpkUipcA6aFkLVLbvpPENiwdpDY=; b=CB9LH8AhOhrj3RVZk1tCWgG/hTgZM8paMUt5jY7eWzgDHN2uEZdJj9r6khBpVpgf9+ e0GHabmww9HOxXx2zrjACIFLRuxOWAH6loLudVa2bzWkfOLp+ROuv4bqPLH9KilY+TxM c99D6TNxcY6VHhx8CHo68c1BIynJTCd93kP0j3S61gqaLhUn+u8DNXXRwu99zpoHcRYy UmHQcImoIT3pHeeaK2zBFUzSQ2VPR4rsTq0K+2beAhXrGIy4Nw8cfTsTgcMtLWe8r/E1 7Ldqa8Oiq26iTm7t4xJituST0kXx/n2nfUPImgab49gPeqEHTsB5Ttj2MfiDL/WZDPfF Eylg== X-Gm-Message-State: AOAM5301yvXNktPnxaNXgMvdThC+jmI9UhJ7/XF4/jWNbBSmRS/184a6 qy2FXGiApycZNyITcongLg1hQARKkVg/AxrBSOA= X-Google-Smtp-Source: ABdhPJwGq1KKvfmTtn51WbrsqLm0cy2baMQ7yYkj3v5tShNoSUjRZE19HMXE25dJETasJBcwg+98wyrjq7oIVWDo8kw= X-Received: by 2002:a92:8e53:: with SMTP id k19mr14822862ilh.236.1635268518483; Tue, 26 Oct 2021 10:15:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 26 Oct 2021 10:15:02 -0700 Message-ID: To: Roman Shpount Cc: Ted Hardie , RTCWeb IETF , Cullen Jennings , Eric Rescorla , Sean Turner Content-Type: multipart/alternative; boundary="000000000000281ad605cf449f16" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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: Tue, 26 Oct 2021 17:15:28 -0000 --000000000000281ad605cf449f16 Content-Type: text/plain; charset="UTF-8" Agree we should add a reference to 8843-bis. I assume we can do that in the endgame as (I believe) no text in 8829bis needs to change. Regarding 3PCC: - bundle clients should be able to accept initial offers without bundle-only. If not, we should fix that in 8843bis, as this seems like an unnecessary limitation - current implementations seem to be managing this OK. - the stats on BUNDLE show that it has been widely adopted (99.999% usage when there is more than 1 a/v stream), and these numbers are only increasing. If "rare" seems overly opinionated, we could use "uncommon" instead. Regarding the suggested workaround: - adding a=bundle-only is insufficient, the application would also need to insert zero ports for the bundled m= lines. It's also not clear that this would lead to a good outcome, as the non-bundle endpoint would only be able to accept the first bundled m= line. So I would suggest that if 3PCC with non-bundle-aware endpoints is likely, the application should just eat the a=group attribute for bundle to prevent bundling in the first place. On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount wrote: > Hi Ted, > > I have mentioned on git that: > 1. The reference to RFC 8843bis is missing > > 2. The following language is factually incorrect: > > This is by design, but could cause issues in the rare case of sending a > subsequent offer as an initial offer to a non-bundle-aware endpoint via > Third Party Call Control (3PCC). > > Primarily, this will cause issues if a subsequent offer is used as an > initial even with bundle-aware end points. An offer with no bundle-only > attributes for bundled m= lines might not get processed correctly. Second, > I would not comment on how frequent this call scenario is going to be > unless we have to. > > My suggested language was: > > This is by design, but could cause issues in case of sending a subsequent > offer as an initial offer due to Third Party Call Control (3PCC). In such > cases, the signaling application is responsible for adding bundle-only > attributes to the offer so that it can be used as an initial offer. > > Best Regards, > _____________ > Roman Shpount > > > On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie wrote: > >> This email serves as the start of a working group last call for >> draft-uberti-rtcweb-rfc8829bis-01.txt. Because of the upcoming IETF >> meeting, it will be slightly longer than normal, ending on November 16, >> 2021. >> >> Please send comments to the list. >> >> thanks, >> >> Ted and Sean >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --000000000000281ad605cf449f16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree we should add a reference to 8843-bis. I assume we c= an do that in the endgame as (I believe) no text in 8829bis needs to change= .

Regarding 3PCC:
- bundle clients should be a= ble to accept initial offers without bundle-only. If not, we should fix tha= t in 8843bis, as this seems like an unnecessary limitation - current implem= entations seem to be managing this OK.
- the stats on BUNDLE show= that it has been widely adopted (99.999% usage when there is more than 1 a= /v stream), and these numbers are only increasing. If "rare" seem= s overly opinionated, we could use "uncommon" instead.
=
Regarding the suggested workaround:
- adding a=3Db= undle-only is insufficient, the application would also need to insert zero = ports for the bundled m=3D lines. It's also not clear that this would l= ead to a good outcome, as the non-bundle endpoint would only be able to acc= ept the first bundled m=3D line. So I would suggest that if 3PCC with non-b= undle-aware endpoints is likely, the application should just eat the a=3Dgr= oup attribute for bundle to prevent bundling in the first place.
=

On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount <roman@telurix.com> wrote:
Hi Ted,

I have mentioned on git that:
1. The reference to RFC 88= 43bis=C2=A0is missing

2. The following language is= factually incorrect:

This is by design, but could= cause issues in the rare case of sending a subsequent offer as an initial = offer to a non-bundle-aware endpoint via Third Party Call Control (3PCC).

Primarily, this will cause issues if a subsequent o= ffer is used as an initial even with bundle-aware end points. An offer with= no bundle-only attributes for bundled=C2=A0m=3D lines might=C2=A0not get p= rocessed correctly. Second, I would not comment on how frequent=C2=A0this c= all scenario is going to be unless we have to.

My = suggested language=C2=A0was:

This is by design, but could cause issues in case of sending a= subsequent offer as an initial offer due to Third Party Call Control (3PCC= ). In such cases, the signaling application is responsible for adding bundl= e-only attributes to the offer so that it can be used as an initial offer.<= /div>

Best Regards,
__= ___________
Roman Shpount


On Tue, Oct 26, 2021 at 6= :55 AM Ted Hardie <ted.ietf@gmail.com> wrote:
This email serves as the start of a working group last ca= ll for draft-uberti-rtcweb-rfc8829bis-01.txt.=C2=A0 Because of the upcoming= IETF meeting, it will be slightly longer than normal, ending on November 1= 6, 2021.

Please send comm= ents to the list.

thanks,=

Ted and Sean
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000281ad605cf449f16--