Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

Cullen Jennings <fluffy@iii.ca> Tue, 09 November 2021 20:38 UTC

Return-Path: <fluffy@iii.ca>
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 C7BB23A10D4 for <rtcweb@ietfa.amsl.com>; Tue, 9 Nov 2021 12:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 JY59dzoUwWNi for <rtcweb@ietfa.amsl.com>; Tue, 9 Nov 2021 12:38:29 -0800 (PST)
Received: from smtp111.iad3b.emailsrvr.com (smtp111.iad3b.emailsrvr.com [146.20.161.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1066A3A10CE for <rtcweb@ietf.org>; Tue, 9 Nov 2021 12:38:29 -0800 (PST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp22.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B14B860120; Tue, 9 Nov 2021 15:38:27 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_66ABFAAF-2CAD-49FB-BCEB-600A01483C70"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CA+9kkMA1GfFY_Uemhvu7PZNj-rJGUMyxYcMbS4_vVu5MTq75Bg@mail.gmail.com>
Date: Tue, 09 Nov 2021 13:38:26 -0700
Message-Id: <C1C2D95D-5A5E-4D02-A40D-F525F6A9C957@iii.ca>
References: <ca569473-975c-b11d-eaa6-4aa215c8c7c9@alvestrand.no> <CA+9kkMA1GfFY_Uemhvu7PZNj-rJGUMyxYcMbS4_vVu5MTq75Bg@mail.gmail.com>
To: RTCWeb IETF <rtcweb@ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Classification-ID: 8dcb6740-844a-4de6-9e35-954d41bcd51d-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/9He7sYC5BStXeBbygDX0vYlvxW8>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 20:38:34 -0000

We might want to say if you don’t want to do any of the ICE nightmare, ICE Lite is the best way to not do it and still have interoperability.  Do we know someone working on this at 5G that can help provide more guidance ?



> On Nov 3, 2021, at 7:10 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> Hi Harald,
> 
> It is definitely possible for us to send liaison statements via the appropriate channel, but I am missing some context.  Can you provide a citation to the document from which the excerpt comes?  (It appears to be labeled a white paper, so the first step may be to confirm that its description and the underlying specs say the same thing.)
> 
> regards,
> 
> Ted Hardie
> 
> On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
> It's come to my attention that there's apparently some 5G spec that says 
> "Use WebRTC datachannel, but don't bother with this ICE stuff".
> 
> The exact quote is below.
> 
> Now I don't mind saying "don't use TURN/STUN servers" - that's a 
> configuration option on the WEBRTC API, and anyone can choose to not do 
> that - but I do mind leaving out ICE. An ICE-supporting implementation 
> won't interwork properly with an implementation that doesn't support ICE.
> 
> Is it possible for the IETF to say "please don't make incompatible 
> changes to our protocols without asking us"? (that's the version where I 
> try not to use expletives).
> 
> Or is it possible that this is all a misunderstanding, and the 5G folks 
> actually meant to require peer-to-peer ICE, but just wrote it wrongly?
> 
> Or did I misunderstand what the WG's intent was, and should just suck it 
> up and interoperate with non-ICE-supporting endpoints?
> 
> Harald
> 
> --------- Spec reference quote ----------
> 
> 1. Spec
> NG.129 - 5G Data Channel White Paper  (CR1001)
> 
> 8.2.1Data channel APIs
> The data channel application consists of the device side logic and the 
> server side logic.
> Both should use standardized APIs that need to be agreed by the industry.
> W3C WebRTC1.0 data channel API specification is suggested as the 
> preferred IMS data channel API. RTCPeerConnection ,
> RTCDataChannel object, the  callbacks need to be supported .
> Only data channel API related definitions  are used and IMS data channel 
> API is not allowed to use WebRTC media.
> ICE/STUN/TURN are also not required.
> 
> # Reference
> 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
> GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
> GSMA NG.129_5G DATA CHANNEL
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb