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

[Cullen Jennings <[e-mail]>]

I  agree we need the consent checks that ICE provided but I think ICE Lite still provided the checks that provide the consent to receive packets property. 

> On Nov 9, 2021, at 1:49 PM, Roman Shpount <[e-mail]> wrote:
> 
> I would advise against ICE-lite. One of the things that ICE provides is consent to send media. ICE-lite does not have this. Getting consent is important to avoid using endpoints for DDOS attacks, so it is a matter of security.
> 
> If they want to simplify things, they can use host candidates only, which will make the ICE state machine trivial.
> _____________
> Roman Shpount
> 
> 
> On Tue, Nov 9, 2021 at 3:38 PM Cullen Jennings <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> 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 <[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>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>