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

[Harald Alvestrand <[e-mail]>]

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 <[e-mail]> *On Behalf Of *Ted Hardie
> *Sent:* den 3 november 2021 14:10
> *To:* Harald Alvestrand <[e-mail]>
> *Cc:* RTCWeb IETF <[e-mail]>
> *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 
> <[e-mail] <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>