onvif / specs

ONVIF Network Interface Specifications
Other
325 stars 87 forks source link

Add requirements for device supporting ICE candidates #392

Closed jflevesque-genetec closed 5 days ago

jflevesque-genetec commented 5 months ago

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.

HansBusch commented 5 months 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.

jflevesque-genetec commented 5 months ago

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

HansBusch commented 5 months ago

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 commented 5 months ago

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.

jmelancongen commented 5 months ago

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.