Re: [rtcweb] 5G standards advocating WebRTC protocol violations?
Ted Hardie <ted.ietf@gmail.com> Wed, 10 November 2021 10:10 UTC
Return-Path: <ted.ietf@gmail.com>
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 C61983A0CD2 for <rtcweb@ietfa.amsl.com>; Wed, 10 Nov 2021 02:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjTrZpBh7lxf for <rtcweb@ietfa.amsl.com>; Wed, 10 Nov 2021 02:10:12 -0800 (PST)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 7F29D3A0CCE for <rtcweb@ietf.org>; Wed, 10 Nov 2021 02:10:12 -0800 (PST)
Received: by mail-il1-x130.google.com with SMTP id x9so1891170ilu.6 for <rtcweb@ietf.org>; Wed, 10 Nov 2021 02:10:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gdzIzhJMg5jazIjJNs2AMkgp6dikmpQeIsbozrCmdJc=; b=nbgillspbemMoNv/xCuwU97ZzuG7u+Dn1/06UwbzrXlfCFsmF2wiFrjJs0A3fU1SCe MCFPxx1fXtDMiYUpm7ibXYcsIwDJw/uBSjUJ1uuK3qB/UlSMK4N7Ma8c3J8to6f8dbyE XydE+baTMms4fwX2p4hacrJetjdlme0SJ0y/OKf7M1Wb4JB+VlK2mYnOnnsC+sVxTBpp dXOAPNhl/2FHukAq8W6d5rcaU9PLWgUbNYCWmbXu+lcPrX7c+0bWhgeUMu6tnFJ5j01P cqx6vBxtY9vFdNC2RdStPwirCN709HcWc3TcOnWLmehq1TqCyiEPG9vIxXHY1z0InfDD LQgg==
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=gdzIzhJMg5jazIjJNs2AMkgp6dikmpQeIsbozrCmdJc=; b=BktzEofaM1qlm4HtnPu90AvrT5wJl/esTbA5wIuuy0xt5coenXBynmtNOUb+m0oWHy rV0FaO2OV/CiUYNBqGLxajRYc2WldCcJrIQPCxNknz4vZY/A9NaGknXq9OyFztGlZRB7 0aF/3BJm12HI10TWrXBw9QO1OM8PMeqYNYnHudB5+6SKUP1gpVi6f7/RJ95QObKxF1hG RSPtUf9gvxi6eUMlSoQmLBIXGg+uH8urrysWcVplLWpkIsTLEGgt5ts6Tpoy7CTmkRBw 8DyZjjtd3pZZDVy/2W0MYlC+quwpwPa6lIvgJ6qYdIBVqehLdjPOwgz2PXhJZ7U1RYVe p/pA==
X-Gm-Message-State: AOAM531aueiKWMgKq9WelimwooYsTK9ZmwI1pZf17jYmC+SVyoY+AuH5 KPfPSOOam+iKOFE6kQCtzsgWwtdLuahe0EJU0SI=
X-Google-Smtp-Source: ABdhPJxpr0GeNr6VOr17MQ8WtQ1ghGfL+LmPtNOYxyRbGnNBTc2Af9JLLjbq4mFRU/C8ywnyRUILrE1lGTmtxqJefXU=
X-Received: by 2002:a05:6e02:144b:: with SMTP id p11mr10119769ilo.70.1636539010851; Wed, 10 Nov 2021 02:10:10 -0800 (PST)
MIME-Version: 1.0
References: <ca569473-975c-b11d-eaa6-4aa215c8c7c9@alvestrand.no> <CA+9kkMA1GfFY_Uemhvu7PZNj-rJGUMyxYcMbS4_vVu5MTq75Bg@mail.gmail.com> <HE1PR07MB34038C7F4DF8907E96F33C948D929@HE1PR07MB3403.eurprd07.prod.outlook.com> <8c8b1988-1c2a-eb6b-5f0a-c9412c6d8981@alvestrand.no>
In-Reply-To: <8c8b1988-1c2a-eb6b-5f0a-c9412c6d8981@alvestrand.no>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 10 Nov 2021 10:09:43 +0000
Message-ID: <CA+9kkMBYbHmHQUQVtTSuZYgq9WHK1wiQmcmX_Yv9s_9vzfsjyQ@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Bo Burman <bo.burman@ericsson.com>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006726b305d06c6e27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/pty9oGuyr_tPejVXCCqtsNmLgcY>
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: Wed, 10 Nov 2021 10:10:18 -0000
Hi Harald, Bo, Thanks to you both for the clarifications. It seems to me, in light of this, that the working group probably does not need to draft a liaison statement and that this can be worked out simply using the explanatory email that Bo provided. If that is not the case, I'd appreciate a clearer statement of what would be required. thanks, Ted Hardie On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand <harald@alvestrand.no> wrote: > Thanks Bo! > > The specific problem I have is that a customer has requested that Chrome > be modified to be able to operate without ICE, where the owner of the > equipment in question is pointing to this particular sentence as > justification for its request. > > If the sentence had said "Use of STUN and TURN servers are not required, > and ICE-Lite can be used", that would have been no problem. > > Harald > On 11/9/21 11:45 PM, Bo Burman wrote: > > Hi Ted, Harald, > > > > I have some insight into that GSMA work that might help the discussion. > > The intent was never to create or even suggest incompatible changes to > WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC > protocols, which I believe is clear from other parts of that White Paper. > The suggested reuse of WebRTC data channel protocol stack is for 3GPP > IMS-native multimedia telephony, not intended to change the core of WebRTC. > It should be OK to use a data channel outside of WebRTC context – for > example, like CLUE telepresence makes use of it. Also, 3GPP previously > defined WebRTC access to IMS through the use of a gateway where ICE is used > on the WebRTC side, but that is separate from the GSMA case. > > > > The GSMA White Paper is mainly educational for that community, in this > case exploring possibilities with using WebRTC data channel media as part > of 5G phone calls. If GSMA members find this interesting enough, normative > work and specifications will follow but nothing is started yet. > > > > I believe the sentence Harald highlights below should be interpreted from > the perspective that ICE/STUN/TURN functionality is strictly not needed in > a telco operator’s network, since connectivity is solved by other means in > that context. That particular sentence is likely not considering what > requirements, e.g. use of ICE, that may come from reuse of existing WebRTC > protocol stacks. This aspect must however be kept in mind as the work > continues. > > > > I hope that helps. > > > > Cheers, > > Bo > > > > *From:* rtcweb <rtcweb-bounces@ietf.org> <rtcweb-bounces@ietf.org> *On > Behalf Of *Ted Hardie > *Sent:* den 3 november 2021 14:10 > *To:* Harald Alvestrand <harald@alvestrand.no> <harald@alvestrand.no> > *Cc:* RTCWeb IETF <rtcweb@ietf.org> <rtcweb@ietf.org> > *Subject:* Re: [rtcweb] 5G standards advocating WebRTC protocol > violations? > > > > 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> > 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 > https://www.ietf.org/mailman/listinfo/rtcweb > >
- [rtcweb] 5G standards advocating WebRTC protocol … Harald Alvestrand
- Re: [rtcweb] 5G standards advocating WebRTC proto… Ted Hardie
- Re: [rtcweb] 5G standards advocating WebRTC proto… Cullen Jennings
- Re: [rtcweb] 5G standards advocating WebRTC proto… Roman Shpount
- Re: [rtcweb] 5G standards advocating WebRTC proto… Bo Burman
- Re: [rtcweb] 5G standards advocating WebRTC proto… Harald Alvestrand
- Re: [rtcweb] 5G standards advocating WebRTC proto… Ted Hardie
- Re: [rtcweb] 5G standards advocating WebRTC proto… westhawk
- Re: [rtcweb] 5G standards advocating WebRTC proto… Cullen Jennings
- Re: [rtcweb] 5G standards advocating WebRTC proto… Bo Burman
- Re: [rtcweb] 5G standards advocating WebRTC proto… Roman Shpount