7. Connection Management (Gestion de connexion)
Les méthodes, mécanismes et exigences pour établir, négocier et démanteler les connexions sont un vaste sujet, et aussi un domaine où la liberté d'interopérabilité et d'innovation est nécessaire.
Les principes suivants s'appliquent :
-
La négociation média WebRTC sera capable d'exprimer la même sémantique SDP offre/réponse utilisée dans SIP [RFC3264], de sorte qu'il soit possible de construire des passerelles de signalisation entre SIP et la négociation média WebRTC.
-
Les passerelles sont possibles vers des dispositifs SIP traditionnels qui prennent en charge ICE et les mécanismes RTP/SDP appropriés, les codecs et les mécanismes de sécurité, sans utiliser de passerelle média. Une passerelle de signalisation peut être nécessaire pour traduire entre la signalisation côté Web et la signalisation SIP.
-
Lors de la spécification du SDP pour de nouveaux codecs, il ne devrait pas être nécessaire d'avoir une autre standardisation pour utiliser ce codec dans un navigateur Web. L'ajout de nouveaux codecs qui peuvent avoir de nouveaux paramètres SDP ne devrait pas changer l'API entre le navigateur et l'application JavaScript. Une fois qu'un navigateur prend en charge un nouveau codec, les anciennes applications écrites avant la spécification du codec devraient être capables d'utiliser automatiquement le nouveau codec lorsque cela est approprié sans modifications de l'application JavaScript.
Les choix spécifiques faits pour WebRTC et leur impact sur l'API fournie aux navigateurs implémentant WebRTC sont décrits dans [RFC8829].
Les navigateurs WebRTC doivent (MUST) implémenter [RFC8829].
Les endpoints WebRTC doivent (MUST) implémenter les fonctionnalités liées à la couche réseau décrites dans [RFC8829] (par exemple, BUNDLE [RFC8843], "rtcp-mux" [RFC5761] et Trickle ICE [RFC8838]), mais ces endpoints n'ont pas besoin de prendre en charge les fonctionnalités d'API décrites dans [RFC8829].