Add requirements for device supporting ICE candidates

[jflevesque-genetec]

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]

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]

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]

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]

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]

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.