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

[Bo Burman <[e-mail]>]

It seems to me that Tim is making a fair description of reality in this case.

 

While I have no insight into the customer request to Google, I’d like to emphasize that since it refers to the GSMA text, the context of that request must reasonably be IMS-native telephony with added data channel(s). In IMS-native telephony context there’s today no support for ICE or ICE Lite, which is then likely the reason for the request. Use of Chrome as a browser application would hardly make sense to me in the context of IMS-native telephony (without any gateway), so I agree with Tim on that aspect.

 

Thanks,

Bo

 

From: rtcweb <[e-mail]> On Behalf Of westhawk
Sent: den 10 november 2021 11:17
To: Harald Alvestrand <[e-mail]>
Cc: RTCWeb IETF <[e-mail]>
Subject: 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 <[e-mail] <mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > 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  <mailto:[e-mail]> <[e-mail]> On Behalf Of Ted Hardie
Sent: den 3 november 2021 14:10
To: Harald Alvestrand  <mailto:[e-mail]> <[e-mail]>
Cc: RTCWeb IETF  <mailto:[e-mail]> <[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

_______________________________________________
rtcweb mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/rtcweb