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

This is (perhaps) a subclass on an interesting situation, where the 5g network spins up a new bearer channel with an interface which is effectively a VPN to the far end.
This obviates ICE, also they probably don’t want Chrome to be able to talk to the far end :-)

Tim (who spent too long in Telcoland) 

> On 10 Nov 2021, at 11:09, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> 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 <mailto: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> <mailto:rtcweb-bounces@ietf.org> On Behalf Of Ted Hardie
>> Sent: den 3 november 2021 14:10
>> To: Harald Alvestrand <harald@alvestrand.no> <mailto:harald@alvestrand.no>
>> Cc: RTCWeb IETF <rtcweb@ietf.org> <mailto: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 <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