8.4 Putting a Unicast Media Stream on Hold (Unicast-Medienstream halten)
8.4 Putting a Unicast Media Stream on Hold (Unicast-Medienstream halten)
Wenn eine Partei in einem Gespräch die andere "in die Warteschleife legen (on hold)" möchte, das heißt verlangt, dass sie vorübergehend aufhört, einen oder mehrere Unicast-Medienstreams zu senden, bietet eine Partei der anderen ein aktualisiertes SDP an.
Wenn der in die Warteschleife zu legende Stream zuvor ein sendrecv-Medienstream war, wird er durch Markierung als sendonly in die Warteschleife gelegt. Wenn der Stream zuvor recvonly war, wird er durch Markierung als inactive in die Warteschleife gelegt.
Das bedeutet, dass ein Stream in jeder Richtung getrennt "in der Warteschleife" liegt. Jeder Stream wird unabhängig in die Warteschleife gelegt. Der Empfänger eines Offers für einen wartenden Stream SOLLTE nicht automatisch eine Answer zurückgeben, in der der entsprechende Stream wartet. Ein SDP, in dem alle Streams "in der Warteschleife" sind, wird held SDP (gehaltenes SDP) genannt.
Bestimmte Szenarien der Drittparteien-Anrufsteuerung (third party call control) funktionieren nicht, wenn der Answerer auf held SDP mit held SDP antwortet.
Typischerweise erzeugt die Implementierung, wenn ein Benutzer "Warteschleife" drückt, ein Offer, in dem alle Streams im SDP die Richtung sendonly haben, und schaltet lokal stumm, sodass keine Medien zum entfernten Ende gesendet und keine Medien ausgegeben werden.
RFC 2543 [10] legte fest, dass das Halten eines Benutzers durch Setzen der Verbindungsadresse auf 0.0.0.0 erfolgte. Die Verwendung zum Halten eines Anrufs wird nicht mehr empfohlen, da RTCP bei gehaltenen Streams nicht verwendet werden kann, es mit IPv6 nicht funktioniert und verbindungsorientierte Medien zerstört. Es kann jedoch in einem initialen Offer nützlich sein, wenn der Offerer weiß, dass er einen bestimmten Satz von Medienstreams und Formaten verwenden möchte, aber Adressen und Ports zum Zeitpunkt des Offers nicht kennt. Natürlich MUSS die Portnummer bei Verwendung nicht null sein, was bedeuten würde, dass der Stream deaktiviert wurde. Eine Implementierung MUSS in der Lage sein, SDP mit Verbindungsadresse 0.0.0.0 zu empfangen, in diesem Fall bedeutet es, dass weder RTP noch RTCP an die Gegenstelle gesendet werden sollen.