11. Media Handling (Medienhandhabung)

11.1. Sending Media (Senden von Medien)

Verfahren zum Senden von Medien unterscheiden sich für vollständige und Lite-Implementierungen.

11.1.1. Procedures for Full Implementations (Verfahren für vollständige Implementierungen)

Agenten senden Medien immer unter Verwendung eines Kandidatenpaares, das als ausgewähltes Kandidatenpaar bezeichnet wird. Ein Agent sendet Medien an den entfernten Kandidaten im ausgewählten Paar (wobei die Zieladresse und der Port des Pakets gleich diesem entfernten Kandidaten gesetzt werden) und sendet sie vom lokalen Kandidaten des ausgewählten Paares. Wenn der lokale Kandidat Server- oder Peer-reflexiv ist, stammen Medien von der Basis. Medien, die von einem weitergeleiteten Kandidaten gesendet werden, werden von der Basis über diesen TURN-Server unter Verwendung der in [RFC5766] definierten Verfahren gesendet.

Wenn der lokale Kandidat ein weitergeleiteter Kandidat ist, wird RECOMMENDED, dass ein Agent einen Kanal auf dem TURN-Server zum entfernten Kandidaten erstellt. Dies geschieht unter Verwendung der Verfahren zur Kanalerstellung, wie in Abschnitt 11 von [RFC5766] definiert.

Das ausgewählte Paar für eine Komponente eines Medienstroms ist:

• leer, wenn der Zustand der Checkliste für diesen Medienstrom Running ist und es aufgrund eines ICE-Neustarts kein vorheriges ausgewähltes Paar für diese Komponente gibt

• gleich dem vorherigen ausgewählten Paar für eine Komponente eines Medienstroms, wenn der Zustand der Checkliste für diesen Medienstrom Running ist und es aufgrund eines ICE-Neustarts ein vorheriges ausgewähltes Paar für diese Komponente gab

• gleich dem nominierten Paar mit der höchsten Priorität für diese Komponente in der gültigen Liste, wenn der Zustand der Checkliste Completed ist

Wenn das ausgewählte Paar für mindestens eine Komponente eines Medienstroms leer ist, MUST ein Agent KEINE Medien für irgendeine Komponente dieses Medienstroms senden. Wenn das ausgewählte Paar für jede Komponente eines Medienstroms einen Wert hat, MAY ein Agent Medien für alle Komponenten dieses Medienstroms senden.

Beachten Sie, dass das ausgewählte Paar für eine Komponente eines Medienstroms möglicherweise nicht dem Standardpaar für dieselbe Komponente aus dem jüngsten Angebots-/Antwortaustausch entspricht. Wenn dies geschieht, wird das ausgewählte Paar für Medien verwendet, nicht das Standardpaar. Wenn ICE zum ersten Mal abgeschlossen ist und die ausgewählten Paare nicht mit den Standardpaaren übereinstimmen, sendet der kontrollierende Agent einen aktualisierten Angebots-/Antwortaustausch, um diese Diskrepanz zu beheben. Bis dieses aktualisierte Angebot eintrifft, wird es jedoch keine Übereinstimmung geben. Darüber hinaus werden in sehr ungewöhnlichen Fällen die Standardkandidaten im aktualisierten Angebot/Antwort keine Übereinstimmung sein.

11.1.2. Procedures for Lite Implementations (Verfahren für Lite-Implementierungen)

Eine Lite-Implementierung MUST KEINE Medien senden, bis sie eine Valid-Liste hat, die ein Kandidatenpaar für jede Komponente dieses Medienstroms enthält. Sobald dies geschieht, MAY der Agent mit dem Senden von Medienpaketen beginnen. Dazu sendet er Medien an den entfernten Kandidaten im Paar (wobei die Zieladresse und der Port des Pakets gleich diesem entfernten Kandidaten gesetzt werden) und sendet sie vom lokalen Kandidaten.

11.1.3. Procedures for All Implementations (Verfahren für alle Implementierungen)

ICE hat Wechselwirkungen mit Jitter-Puffer-Anpassungsmechanismen. Ein RTP-Strom kann mit einem Kandidaten beginnen und zu einem anderen wechseln, obwohl dies bei ICE selten vorkommt. Der neuere Kandidat kann dazu führen, dass RTP-Pakete einen anderen Weg durch das Netzwerk nehmen -- einen mit unterschiedlichen Verzögerungseigenschaften. Wie unten diskutiert, werden Agenten ermutigt, Jitter-Puffer neu anzupassen, wenn sich die Quell- oder Zieladresse von Medienpaketen ändert. Darüber hinaus verwenden viele Audio-Codecs das Marker-Bit, um den Beginn eines Talkspurts zu signalisieren, zum Zweck der Jitter-Puffer-Anpassung. Für solche Codecs wird RECOMMENDED, dass der Sender das Marker-Bit [RFC3550] setzt, wenn ein Agent die Übertragung von Medien von einem Kandidatenpaar zu einem anderen wechselt.

11.2. Receiving Media (Empfangen von Medien)

ICE-Implementierungen MUST bereit sein, Medien auf jeder Komponente auf allen Kandidaten zu empfangen, die für diese Komponente im jüngsten Angebots-/Antwortaustausch bereitgestellt wurden (im Fall von RTP würde dies sowohl RTP als auch RTCP einschließen, wenn Kandidaten für beide bereitgestellt wurden).

Es wird RECOMMENDED, dass ein Agent, wenn er ein RTP-Paket mit einer neuen Quell- oder Ziel-IP-Adresse für einen bestimmten Medienstrom empfängt, seine Jitter-Puffer neu anpasst.

RFC 3550 [RFC3550] beschreibt in Abschnitt 8.2 einen Algorithmus zur Erkennung von Kollisionen und Schleifen der Synchronisationsquelle (SSRC). Diese Algorithmen basieren teilweise darauf, unterschiedliche Quelltransportadressen mit derselben SSRC zu sehen. Wenn ICE verwendet wird, treten solche Änderungen jedoch manchmal auf, wenn die Medienströme zwischen Kandidaten wechseln. Ein Agent kann feststellen, dass ein Medienstrom vom selben Peer stammt, als Folge des STUN-Austauschs, der der Medienübertragung vorausgeht. Wenn also eine Änderung der Quelltransportadresse vorliegt, die Medienpakete jedoch vom selben Peer-Agenten stammen, SOLLTE dies NICHT als SSRC-Kollision behandelt werden.