1. Introduction

1. Introduction

Ce document décrit comment l'interface W3C Web Real-Time Communication (WebRTC) RTCPeerConnection [W3C.webrtc] est utilisée pour contrôler la configuration, la gestion et la fermeture d'une session multimédia.

1.1 General Design of JSEP (Conception générale de JSEP)

La configuration d'appel WebRTC a été conçue pour se concentrer sur le contrôle du plan média, laissant le comportement du plan de signalisation à l'application autant que possible. La raison est que différentes applications peuvent préférer utiliser différents protocoles, tels que le protocole de signalisation d'appel SIP existant, ou quelque chose de personnalisé pour l'application particulière, peut-être pour un cas d'utilisation nouveau. Dans cette approche, les informations clés qui doivent être échangées sont la description de session multimédia, qui spécifie les informations de configuration de transport et de média nécessaires pour établir le plan média.

Avec ces considérations à l'esprit, ce document décrit le JavaScript Session Establishment Protocol (JSEP), qui permet un contrôle total de la machine à états de signalisation depuis JavaScript. Comme décrit ci-dessus, JSEP suppose un modèle dans lequel une application JavaScript s'exécute dans un environnement d'exécution contenant des API WebRTC (l'"implémentation JSEP"). L'implémentation JSEP est presque entièrement dissociée du flux de signalisation principal, qui est plutôt géré par le JavaScript utilisant deux interfaces: (1) passer les descriptions de session locales et distantes et (2) interagir avec la machine à états Interactive Connectivity Establishment (ICE) [RFC8445]. La combinaison de l'implémentation JSEP et de l'application JavaScript est appelée "point terminal JSEP" dans ce document.

Dans ce document, l'utilisation de JSEP est décrite comme si elle se produisait toujours entre deux points terminaux JSEP. Notez cependant que dans de nombreux cas, elle se produira en fait entre un point terminal JSEP et une sorte de serveur, tel qu'une passerelle ou une unité de contrôle multipoint (MCU). Cette distinction est invisible pour le point terminal JSEP; il suit simplement les instructions qui lui sont données via l'API.

La gestion des descriptions de session par JSEP est simple et directe. Chaque fois qu'un échange offre/réponse est nécessaire, le côté initiateur crée une offre en appelant une API createOffer. L'application utilise ensuite cette offre pour configurer sa configuration locale via l'API setLocalDescription. L'offre est finalement envoyée au côté distant via son mécanisme de signalisation préféré (par exemple, WebSockets); lors de la réception de cette offre, la partie distante l'installe en utilisant l'API setRemoteDescription.

Pour compléter l'échange offre/réponse, la partie distante utilise l'API createAnswer pour générer une réponse appropriée, l'applique en utilisant l'API setLocalDescription, et renvoie la réponse à l'initiateur via le canal de signalisation. Lorsque l'initiateur reçoit cette réponse, il l'installe en utilisant l'API setRemoteDescription, et la configuration initiale est terminée. Ce processus peut être répété pour des échanges offre/réponse supplémentaires.

Concernant ICE [RFC8445], JSEP découple la machine à états ICE de la machine à états de signalisation globale. La machine à états ICE doit rester dans l'implémentation JSEP car seule l'implémentation possède les connaissances nécessaires sur les candidats et autres informations de transport. Cette séparation offre une flexibilité supplémentaire dans les protocoles qui découplent les descriptions de session du transport. Par exemple, dans le SIP traditionnel, chaque offre ou réponse est autonome, incluant à la fois les descriptions de session et les informations de transport. Cependant, [RFC8840] permet l'utilisation de SIP avec Trickle ICE [RFC8838], dans lequel la description de session peut être envoyée immédiatement et les informations de transport peuvent être envoyées lorsqu'elles sont disponibles. L'envoi séparé d'informations de transport peut permettre un démarrage ICE et DTLS plus rapide, car les vérifications ICE peuvent commencer dès que des informations de transport sont disponibles plutôt que d'attendre toutes les informations. Le découplage de JSEP entre les machines à états ICE et de signalisation lui permet de s'adapter à l'un ou l'autre modèle.

Bien qu'elle abstraie la signalisation, l'approche JSEP exige que l'application soit consciente du processus de signalisation. Bien que l'application n'ait pas besoin de comprendre le contenu des descriptions de session pour établir un appel, l'application doit appeler les bonnes API au bon moment, convertir les descriptions de session et les informations ICE dans les messages définis de son protocole de signalisation choisi, et effectuer la conversion inverse sur les messages qu'elle reçoit de l'autre côté.

Une façon de faciliter la vie de l'application est de fournir une bibliothèque JavaScript qui cache cette complexité au développeur; cette bibliothèque implémenterait un protocole de signalisation donné avec sa machine à états et son code de sérialisation, présentant une interface de niveau supérieur orientée appel au développeur d'application. Par exemple, des bibliothèques existent pour fournir des implémentations des protocoles de signalisation SIP [RFC3261] et Extensible Messaging and Presence Protocol (XMPP) [RFC6120] au-dessus de l'API JSEP. Ainsi, JSEP offre un meilleur contrôle pour le développeur expérimenté sans imposer de complexité supplémentaire au développeur novice.

1.2 Other Approaches Considered (Autres approches considérées)

Une approche qui a été envisagée au lieu de JSEP était d'inclure un protocole de signalisation léger. Au lieu de fournir des descriptions de session à l'API, l'API produirait et consommerait des messages de ce protocole. Tout en fournissant une API de plus haut niveau, cela plaçait plus de contrôle de la signalisation dans l'implémentation JSEP, l'obligeant à comprendre et à gérer des concepts tels que le conflit de signalisation (voir [RFC3264], Section 4).

Une deuxième approche envisagée mais non retenue consistait à découpler la gestion des objets de contrôle média des descriptions de session, en offrant plutôt des API qui contrôleraient directement chaque composant. Cela a été rejeté sur la base de l'argument qu'exiger l'exposition de ce niveau de complexité au programmeur d'application ne serait pas bénéfique; cela (1) résulterait en une API où même un exemple simple nécessiterait une quantité importante de code pour orchestrer toutes les interactions nécessaires et (2) créerait une grande surface d'API qui devrait être convenue et documentée. De plus, ces points d'API pourraient être appelés dans n'importe quel ordre, entraînant un ensemble plus complexe d'interactions avec le sous-système média que l'approche JSEP, qui spécifie comment les descriptions de session doivent être évaluées et appliquées.

Une variation de JSEP qui a été envisagée consistait à conserver l'API de base orientée description de session mais à déplacer le mécanisme de génération d'offres et de réponses hors de l'implémentation JSEP. Au lieu de fournir des méthodes createOffer/createAnswer dans l'implémentation, cette approche exposerait plutôt une API getCapabilities, qui fournirait à l'application les informations dont elle a besoin pour générer ses propres descriptions de session. Cela augmente la quantité de travail que l'application doit faire; elle doit savoir comment générer des descriptions de session à partir de capacités, et en particulier comment générer la bonne réponse à partir d'une offre arbitraire et des capacités prises en charge. Bien que cela puisse certainement être résolu en utilisant une bibliothèque comme celle mentionnée ci-dessus, cela force essentiellement l'utilisation de cette bibliothèque même pour un exemple simple. Fournir createOffer/createAnswer évite ce problème.

1.3 Contradiction regarding bundle-only "m=" sections (Contradiction concernant les sections "m=" bundle-only)

Depuis l'approbation des documents de spécification WebRTC, l'IETF a pris conscience d'une incohérence entre le document spécifiant JSEP et le document spécifiant BUNDLE (cette RFC et [RFC8843], respectivement). Plutôt que de retarder davantage la publication pour parvenir à une résolution, les documents sont publiés tels qu'ils ont été initialement approuvés. L'IETF a l'intention de reprendre le travail sur ces technologies, et des versions révisées de ces documents seront publiées dès qu'une résolution sera disponible.

Le problème spécifique concerne le traitement des sections "m=" désignées comme bundle-only, comme discuté dans la Section 4.1.1 de cette RFC. Actuellement, il existe une divergence entre JSEP et BUNDLE, ainsi qu'entre ces spécifications et les implémentations de navigateur existantes:

• JSEP prescrit que lesdites sections "m=" devraient utiliser le port zéro et ajouter un attribut "a=bundle-only" dans les offres initiales, mais pas dans les réponses ou les offres ultérieures.

• BUNDLE prescrit que ces sections "m=" devraient être marquées comme décrit dans le point précédent, mais dans toutes les offres et réponses.

• La plupart des navigateurs actuels ne marquent aucune section "m=" avec le port zéro et utilisent plutôt le même port pour toutes les sections "m=" groupées; d'autres suivent le comportement JSEP.