3.2 Session Descriptions and State Machine (Sitzungsbeschreibungen und Zustandsautomat)

Um die Medienebene zu etablieren, benötigt die JSEP-Implementierung spezifische Parameter, um anzugeben, was an die entfernte Seite übertragen werden soll, sowie wie die empfangenen Medien zu handhaben sind. Diese Parameter werden durch den Austausch von Sitzungsbeschreibungen in Offers und Answers bestimmt, und es gibt bestimmte Details dieses Prozesses, die in den JSEP-APIs behandelt werden müssen.

Ob eine Sitzungsbeschreibung auf die lokale oder die entfernte Seite zutrifft, beeinflusst die Bedeutung dieser Beschreibung. Beispielsweise gibt die Liste der an eine entfernte Partei gesendeten Codecs an, was die lokale Seite zu empfangen bereit ist, was, wenn es mit dem Satz von Codecs geschnitten wird, den die entfernte Seite unterstützt, angibt, was die entfernte Seite senden sollte. Jedoch folgen nicht alle Parameter dieser Regel; einige Parameter sind deklarativ, und die entfernte Seite muss sie entweder vollständig akzeptieren oder ablehnen. Ein Beispiel für einen solchen Parameter sind die TLS-Fingerabdrücke [RFC8122], wie sie im Kontext von DTLS [RFC6347] verwendet werden; diese Fingerabdrücke werden basierend auf den angebotenen lokalen Zertifikaten berechnet und unterliegen nicht der Verhandlung.

Darüber hinaus stellen verschiedene RFCs unterschiedliche Bedingungen für das Format von Offers versus Answers. Beispielsweise kann ein Offer eine beliebige Anzahl von "m="-Abschnitten vorschlagen (d. h. Medienbeschreibungen, wie in [RFC4566], Abschnitt 5.14 beschrieben), aber ein Answer muss genau die gleiche Anzahl wie das Offer enthalten.

Schließlich, während die genauen Medienparameter erst nach dem Austausch eines Offers und eines Answers bekannt sind, kann der Offerer ICE-Prüfungen und möglicherweise Medien empfangen (z. B. im Fall eines Re-Offers nach dem Aufbau einer Verbindung), bevor er ein Answer erhält. Um eingehende Medien in diesem Fall ordnungsgemäß zu verarbeiten, muss der Medien-Handler des Offerers über die Details des Offers informiert sein, bevor das Answer eintrifft.

Daher benötigt die JSEP-Implementierung, um Sitzungsbeschreibungen ordnungsgemäß zu handhaben:

Zu wissen, ob eine Sitzungsbeschreibung die lokale oder entfernte Seite betrifft.
Zu wissen, ob eine Sitzungsbeschreibung ein Offer oder ein Answer ist.
Zu ermöglichen, dass das Offer unabhängig vom Answer spezifiziert wird.

JSEP adressiert dies durch Hinzufügen sowohl der setLocalDescription- als auch der setRemoteDescription-Methoden und durch Einbeziehen eines Typfelds in Sitzungsbeschreibungsobjekte, das den Typ der bereitgestellten Sitzungsbeschreibung angibt. Dies erfüllt die oben aufgeführten Anforderungen sowohl für den Offerer, der zuerst setLocalDescription(sdp [offer]) aufruft und später setRemoteDescription(sdp [answer]), als auch für den Answerer, der zuerst setRemoteDescription(sdp [offer]) aufruft und später setLocalDescription(sdp [answer]).

Während des Offer/Answer-Austauschs wird das ausstehende Offer beim Offerer und beim Answerer als "ausstehend" betrachtet, da es entweder akzeptiert oder abgelehnt werden kann. Wenn dies ein Re-Offer ist, hat jede Seite auch "aktuelle" lokale und entfernte Beschreibungen, die das Ergebnis des letzten Offer/Answer-Austauschs widerspiegeln. Die Abschnitte 4.1.14, 4.1.16, 4.1.13 und 4.1.15 bieten weitere Details zu ausstehenden und aktuellen Beschreibungen.

JSEP ermöglicht es auch, dass ein Answer von der Anwendung als vorläufig behandelt wird. Vorläufige Answers bieten dem Answerer eine Möglichkeit, anfängliche Sitzungsparameter an den Offerer zurückzukommunizieren, um den Beginn der Sitzung zu ermöglichen, während ein finales Answer später spezifiziert werden kann. Dieses Konzept eines finalen Answers ist wichtig für das Offer/Answer-Modell; wenn ein solches Answer empfangen wird, können alle vom Anrufer zugewiesenen zusätzlichen Ressourcen freigegeben werden, da die genaue Sitzungskonfiguration nun bekannt ist. Diese "Ressourcen" können Dinge wie zusätzliche ICE-Komponenten, Traversal Using Relays around NAT (TURN)-Kandidaten oder Videodecoder umfassen. Vorläufige Answers führen hingegen keine solche Freigabe durch; infolgedessen können während des Anrufaufbaus mehrere unterschiedliche vorläufige Answers mit ihren eigenen Codec-Auswahlen, Transportparametern usw. empfangen und angewendet werden. Beachten Sie, dass das finale Answer selbst sich von allen empfangenen vorläufigen Answers unterscheiden kann.

In [RFC3264] ist die Einschränkung auf Signalisierungsebene, dass für eine gegebene Sitzung nur ein Offer ausstehend sein kann, aber auf JSEP-Ebene kann jederzeit ein neues Offer generiert werden. Wenn beispielsweise SIP für die Signalisierung verwendet wird und ein Offer gesendet und dann mit einem SIP CANCEL abgebrochen wird, kann ein weiteres Offer generiert werden, obwohl für das erste Offer kein Answer empfangen wurde. Um dies zu unterstützen, kann die JSEP-Medienschicht über die createOffer-Methode ein Offer bereitstellen, wann immer die JavaScript-Anwendung eines für die Signalisierung benötigt. Der Answerer kann null oder mehr vorläufige Answers zurücksenden und dann den Offer/Answer-Austausch durch Senden eines finalen Answers beenden. Der Zustandsautomat dafür ist wie folgt:

                    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

Abgesehen von diesen Zustandsübergängen gibt es keinen anderen Unterschied zwischen der Behandlung von vorläufigen ("pranswer") und finalen ("answer") Answers.

3.2 Session Descriptions and State Machine (Sitzungsbeschreibungen und Zustandsautomat)​

3.2 Session Descriptions and State Machine (Sitzungsbeschreibungen und Zustandsautomat)