4.1.10.1. Use of Provisional Answers (Verwendung vorläufiger Antworten)
4.1.10.1. Use of Provisional Answers (Verwendung vorläufiger Antworten)
Die meisten Anwendungen müssen keine Antworten mit dem Typ "pranswer" erstellen. Obwohl es eine gute Praxis ist, sofort auf ein Angebot zu antworten, um den Sitzungstransport vorzuwärmen und Medien-Clipping zu verhindern, besteht die bevorzugte Handhabung für eine JSEP-Anwendung darin, unmittelbar nach Erhalt des Angebots eine endgültige "sendonly"-Antwort mit einem null-MediaStreamTrack zu erstellen und zu senden, was verhindert, dass Medien vom Anrufer gesendet werden, und es ermöglicht, dass Medien sofort bei Antwort durch den Angerufenen gesendet werden. Später, wenn der Angerufene den Anruf tatsächlich annimmt, kann die Anwendung den echten MediaStreamTrack einstecken und ein neues "sendrecv"-Angebot erstellen, um das vorherige Angebot/Antwort-Paar zu aktualisieren und bidirektionalen Medienfluss zu starten. Während dies auch mit einer "sendonly"-Pranswer gefolgt von einer "sendrecv"-Antwort erfolgen könnte, lässt die anfängliche Pranswer den Angebot/Antwort-Austausch offen, was bedeutet, dass der Anrufer während dieser Zeit kein aktualisiertes Angebot senden kann.
Als Beispiel betrachten Sie eine typische JSEP-Anwendung, die Audio und Video so schnell wie möglich einrichten möchte. Wenn der Angerufene ein Angebot mit Audio- und Video-MediaStreamTracks erhält, sendet er sofort eine Antwort, die diese Tracks als sendonly akzeptiert (was bedeutet, dass der Anrufer dem Angerufenen noch keine Medien senden wird, und weil der Angerufene noch keine eigenen MediaStreamTracks hinzugefügt hat, wird auch der Angerufene keine Medien senden). Dann wird er den Benutzer bitten, den Anruf anzunehmen und die benötigten lokalen Tracks zu erwerben. Bei Annahme durch den Benutzer wird die Anwendung die erworbenen Tracks einstecken, die, weil ICE-Handshaking und DTLS-Handshaking zu diesem Zeitpunkt wahrscheinlich abgeschlossen sind, sofort mit der Übertragung beginnen können. Die Anwendung sendet auch ein neues Angebot an die entfernte Seite, das die Annahme des Anrufs anzeigt und Audio und Video zu bidirektionalen Medien verschiebt. Ein detaillierter Beispielablauf entlang dieser Linien wird in Abschnitt 7.3 gezeigt.
Natürlich können einige Anwendungen diesen doppelten Angebot/Antwort-Austausch möglicherweise nicht durchführen, insbesondere solche, die versuchen, zu Legacy-Signalisierungsprotokollen zu überbrücken. In diesen Fällen kann Pranswer der Anwendung immer noch einen Mechanismus zum Vorwärmen des Transports bieten.