specs icon indicating copy to clipboard operation
specs copied to clipboard

Add requirements for device supporting ICE candidates

Open jflevesque-genetec opened this issue 1 year ago • 5 comments

In RFC8445, host, server reflexive and relay are marked as SHOULD be supported, but we are changing it for SHALL to ensure the most basic WebRTC connectivity requirements are supported by the devices. Without these, the peer to peer connection is impossible to establish.

As for the ICE TCP candidates, we are adding further requirements so devices can establish a direct connection to cloud services avoiding the need of a TURN server.

jflevesque-genetec avatar Feb 22 '24 20:02 jflevesque-genetec

Before digging into details I'd like to check which are removed, kept and added:

 old           new
5245		Interactive Connectivity Establishment (ICE):
	6544	TCP Candidates with Interactive Connectivity Establishment (ICE)
	6749	The OAuth 2.0 Authorization Framework
7064	7064
	7065	 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers
7519	7519
8489	8489
8656	8656
8829	8829
8839		Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)
8840		A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
	8845	Framework for Telepresence Multi-Streams
8866	8866

8839 replaces 5245. Please note that according to IEC rules normative references must be quoted in the text.

HansBusch avatar Feb 23 '24 14:02 HansBusch

Hi Hans, if memory serves me right, I only removed 5245 to use 8839 which replaces the old RFC. The rest should only be sorting them by RFC number

jflevesque-genetec avatar Feb 26 '24 13:02 jflevesque-genetec

Took the time to double check:

  1. The below new paragraph introduces two new references A device shall support generating and receiving host, server reflexive and relay ICE candidates as defined in [RFC 8445]. A device shall support receiving passive and generating active ICE TCP candidates as defined in [RFC 6544]. RFC 6749 was already there before. Should be removed since not referenced in text. RFC 7605 unchanged and OK RFC 8839 was already there before. Should be removed since not referenced in text. RFC 8840 was already there before and referenced RFC 8845 never mentioned.

Once this one is merged I propose to create another PR sorting the RFCs to avoid diff showing wild changes and remove unreferenced ones.

HansBusch avatar Feb 26 '24 15:02 HansBusch

Agree with paragraph on RFC 8445. However not sure whether we should mandate 6544 as it is a very special case with low success rate.

HansBusch avatar Feb 26 '24 15:02 HansBusch

I'm not sure about low success rate? From my understanding, it is rarely configured (as it needs opening ports on the passive side) but in scenarios where a cloud service needs to act as a peer it is a very efficient way of avoiding the usual ICE flow and getting directly a connection without hassle and unnecessary TURN redirections. While it never happens in browser-device scenarios, that's not the only usecase that benefits from WebRTC connectivity. Most ICE stacks already support the active way (connecting to a peer that has opened a port) so it feels like an easy requirement.

jmelancondev avatar Feb 27 '24 18:02 jmelancondev