Closed jflevesque-genetec closed 5 days ago
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.
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
Took the time to double check:
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.
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.
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.
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.