3.2 Session Descriptions and State Machine (Descriptions de session et machine à états)

Afin d'établir le plan média, l'implémentation JSEP a besoin de paramètres spécifiques pour indiquer ce qu'il faut transmettre au côté distant, ainsi que comment gérer le média reçu. Ces paramètres sont déterminés par l'échange de descriptions de session dans les offres et réponses, et il y a certains détails de ce processus qui doivent être gérés dans les API JSEP.

Le fait qu'une description de session s'applique au côté local ou au côté distant affecte la signification de cette description. Par exemple, la liste des codecs envoyée à une partie distante indique ce que le côté local est prêt à recevoir, ce qui, lorsqu'il est croisé avec l'ensemble des codecs pris en charge par le côté distant, spécifie ce que le côté distant doit envoyer. Cependant, tous les paramètres ne suivent pas cette règle; certains paramètres sont déclaratifs, et le côté distant doit soit les accepter soit les rejeter entièrement. Un exemple d'un tel paramètre est les empreintes digitales TLS [RFC8122] telles qu'utilisées dans le contexte de DTLS [RFC6347]; ces empreintes digitales sont calculées en fonction du ou des certificats locaux offerts et ne sont pas soumises à négociation.

De plus, diverses RFC imposent des conditions différentes sur le format des offres par rapport aux réponses. Par exemple, une offre peut proposer un nombre arbitraire de sections "m=" (c'est-à-dire des descriptions de média telles que décrites dans [RFC4566], Section 5.14), mais une réponse doit contenir exactement le même nombre que l'offre.

Enfin, bien que les paramètres média exacts ne soient connus qu'après l'échange d'une offre et d'une réponse, l'offrant peut recevoir des vérifications ICE, et éventuellement du média (par exemple, dans le cas d'une nouvelle offre après qu'une connexion ait été établie) avant de recevoir une réponse. Pour traiter correctement le média entrant dans ce cas, le gestionnaire de média de l'offrant doit être conscient des détails de l'offre avant l'arrivée de la réponse.

Par conséquent, pour gérer correctement les descriptions de session, l'implémentation JSEP a besoin de:

Savoir si une description de session concerne le côté local ou distant.
Savoir si une description de session est une offre ou une réponse.
Permettre que l'offre soit spécifiée indépendamment de la réponse.

JSEP résout cela en ajoutant à la fois les méthodes setLocalDescription et setRemoteDescription et en faisant en sorte que les objets de description de session contiennent un champ de type indiquant le type de description de session fournie. Cela satisfait les exigences énumérées ci-dessus pour l'offrant, qui appelle d'abord setLocalDescription(sdp [offer]) puis plus tard setRemoteDescription(sdp [answer]), et pour le répondant, qui appelle d'abord setRemoteDescription(sdp [offer]) puis plus tard setLocalDescription(sdp [answer]).

Pendant l'échange offre/réponse, l'offre en attente est considérée comme "en attente" chez l'offrant et le répondant, car elle peut être acceptée ou rejetée. S'il s'agit d'une nouvelle offre, chaque côté aura également des descriptions locales et distantes "actuelles", qui reflètent le résultat du dernier échange offre/réponse. Les sections 4.1.14, 4.1.16, 4.1.13 et 4.1.15 fournissent plus de détails sur les descriptions en attente et actuelles.

JSEP permet également qu'une réponse soit traitée comme provisoire par l'application. Les réponses provisoires fournissent un moyen pour un répondant de communiquer des paramètres de session initiaux à l'offrant, afin de permettre à la session de commencer, tout en permettant qu'une réponse finale soit spécifiée ultérieurement. Ce concept de réponse finale est important pour le modèle offre/réponse; lorsqu'une telle réponse est reçue, toutes les ressources supplémentaires allouées par l'appelant peuvent être libérées, maintenant que la configuration de session exacte est connue. Ces "ressources" peuvent inclure des choses comme des composants ICE supplémentaires, des candidats Traversal Using Relays around NAT (TURN), ou des décodeurs vidéo. Les réponses provisoires, en revanche, ne font pas une telle désallocation; en conséquence, plusieurs réponses provisoires dissemblables, avec leurs propres choix de codec, paramètres de transport, etc., peuvent être reçues et appliquées pendant la configuration de l'appel. Notez que la réponse finale elle-même peut être différente de toute réponse provisoire reçue.

Dans [RFC3264], la contrainte au niveau de la signalisation est qu'une seule offre peut être en attente pour une session donnée, mais au niveau JSEP, une nouvelle offre peut être générée à tout moment. Par exemple, lors de l'utilisation de SIP pour la signalisation, si une offre est envoyée puis annulée à l'aide d'un CANCEL SIP, une autre offre peut être générée même si aucune réponse n'a été reçue pour la première offre. Pour prendre en charge cela, la couche média JSEP peut fournir une offre via la méthode createOffer chaque fois que l'application JavaScript en a besoin pour la signalisation. Le répondant peut renvoyer zéro ou plusieurs réponses provisoires, puis finalement terminer l'échange offre/réponse en envoyant une réponse finale. La machine à états pour cela est la suivante:

                    setRemote(OFFER)               setLocal(PRANSWER)
                        /-----\                               /-----\
                        |     |                               |     |
                        v     |                               v     |
         +---------------+    |                +---------------+    |
         |               |----/                |               |----/
         |  have-        | setLocal(PRANSWER)  | have-         |
         |  remote-offer |------------------- >| local-pranswer|
         |               |                     |               |
         |               |                     |               |
         +---------------+                     +---------------+
              ^   |                                   |
              |   | setLocal(ANSWER)                  |
setRemote(OFFER)  |                                   |
              |   V                  setLocal(ANSWER) |
         +---------------+                            |
         |               |                            |
         |               |<---------------------------+
         |    stable     |
         |               |<---------------------------+
         |               |                            |
         +---------------+          setRemote(ANSWER) |
              ^   |                                   |
              |   | setLocal(OFFER)                   |
setRemote(ANSWER) |                                   |
              |   V                                   |
         +---------------+                     +---------------+
         |               |                     |               |
         |  have-        | setRemote(PRANSWER) |have-          |
         |  local-offer  |------------------- >|remote-pranswer|
         |               |                     |               |
         |               |----\                |               |----\
         +---------------+    |                +---------------+    |
                        ^     |                               ^     |
                        |     |                               |     |
                        \-----/                               \-----/
                    setLocal(OFFER)               setRemote(PRANSWER)

                     Figure 2: JSEP State Machine

Hormis ces transitions d'état, il n'y a pas d'autre différence entre le traitement des réponses provisoires ("pranswer") et finales ("answer").

3.2 Session Descriptions and State Machine (Descriptions de session et machine à états)​

3.2 Session Descriptions and State Machine (Descriptions de session et machine à états)