9. Subsequent Offer/Answer Exchanges (Nachträgliche Angebots-/Antwortaustausche)

Jeder Agent MAY jederzeit ein nachträgliches Angebot generieren, wie es durch RFC 3264 [RFC3264] erlaubt ist. Die Regeln in Abschnitt 8 veranlassen den kontrollierenden Agenten, ein aktualisiertes Angebot zum Abschluss der ICE-Verarbeitung zu senden, wenn ICE andere Kandidatenpaare als die Standardpaare ausgewählt hat. Dieser Abschnitt definiert Regeln für die Konstruktion von nachträglichen Angeboten und Antworten.

Sollte ein nachträgliches Angebot abgelehnt werden, wird die ICE-Verarbeitung so fortgesetzt, als ob das nachträgliche Angebot niemals gemacht worden wäre.

9.1. Generating the Offer (Generierung des Angebots)

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

9.1.1.1. ICE Restarts (ICE-Neustarts)

Ein Agent MAY die ICE-Verarbeitung für einen bestehenden Medienstrom neu starten. Ein ICE-Neustart führt, wie der Name schon sagt, dazu, dass alle vorherigen Zustände der ICE-Verarbeitung gelöscht werden und Prüfungen von neuem beginnen. Der einzige Unterschied zwischen einem ICE-Neustart und einer brandneuen Mediensitzung besteht darin, dass während des Neustarts Medien weiterhin an das zuvor validierte Paar gesendet werden können.

Ein Agent MUST ICE für einen Medienstrom neu starten, wenn:

• Das Angebot zu dem Zweck generiert wird, das Ziel des Medienstroms zu ändern. Mit anderen Worten, wenn ein Agent ein aktualisiertes Angebot generieren möchte, das, wenn ICE nicht verwendet worden wäre, zu einem neuen Wert für das Ziel einer Medienkomponente führen würde.

• Ein Agent ändert sein Implementierungsniveau. Dies geschieht typischerweise nur in Anwendungsfällen der Anrufsteuerung durch Dritte, bei denen die Entität, die die Signalisierung durchführt, nicht die Entität ist, die die Medien empfängt, und sie das Ziel der Medien während der Sitzung auf eine andere Entität geändert hat, die eine andere ICE-Implementierung hat.

Diese Regeln implizieren, dass das Setzen der IP-Adresse in der c-Zeile auf 0.0.0.0 einen ICE-Neustart verursacht. Folglich MUST ICE-Implementierungen diesen Mechanismus NICHT für das Halten von Anrufen verwenden und stattdessen a=inactive und a=sendonly verwenden, wie in [RFC3264] beschrieben.

Um ICE neu zu starten, MUST ein Agent sowohl ice-pwd als auch ice-ufrag für den Medienstrom in einem Angebot ändern. Beachten Sie, dass es zulässig ist, ein Attribut auf Sitzungsebene in einem Angebot zu verwenden, aber denselben ice-pwd oder ice-ufrag als Attribut auf Medienebene in einem nachträglichen Angebot bereitzustellen. Dies ist keine Änderung des Passworts, sondern nur eine Änderung seiner Darstellung und verursacht keinen ICE-Neustart.

Ein Agent setzt den Rest der Felder im SDP für diesen Medienstrom so, wie er es in einem anfänglichen Angebot dieses Medienstroms tun würde (siehe Abschnitt 4.3). Folglich MAY der Satz von Kandidaten einige, keine oder alle der vorherigen Kandidaten für diesen Strom enthalten und MAY einen völlig neuen Satz von Kandidaten enthalten, die wie in Abschnitt 4.1.1 beschrieben gesammelt wurden.

9.1.1.2. Removing a Media Stream (Entfernen eines Medienstroms)

Wenn ein Agent einen Medienstrom entfernt, indem er seinen Port auf Null setzt, MUST er KEINE Kandidatenattribute für diesen Medienstrom enthalten und SOLLTE KEINE anderen ICE-bezogenen Attribute, die in Abschnitt 15 definiert sind, für diesen Medienstrom enthalten.

9.1.1.3. Adding a Media Stream (Hinzufügen eines Medienstroms)

Wenn ein Agent einen neuen Medienstrom hinzufügen möchte, setzt er die Felder im SDP für diesen Medienstrom so, als wäre dies ein anfängliches Angebot für diesen Medienstrom (siehe Abschnitt 4.3). Dies führt dazu, dass die ICE-Verarbeitung für diesen Medienstrom beginnt.

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

Dieser Abschnitt beschreibt zusätzliche Verfahren für vollständige Implementierungen, die bestehende Medienströme abdecken.

Die Benutzernamenfragmente, das Passwort und das Implementierungsniveau MUST dieselben bleiben wie zuvor verwendet. Wenn ein Agent eines dieser Elemente ändern muss, MUST er ICE für diesen Medienstrom neu starten.

Zusätzliches Verhalten hängt vom Zustand der ICE-Verarbeitung für diesen Medienstrom ab.

9.1.2.1. Existing Media Streams with ICE Running (Bestehende Medienströme mit laufendem ICE)

Wenn ein Agent ein aktualisiertes Angebot generiert, das einen Medienstrom enthält, der zuvor etabliert wurde und für den sich ICE-Prüfungen im Zustand Running befinden, folgt der Agent den hier definierten Verfahren.

Ein Agent MUST Kandidatenattribute für alle lokalen Kandidaten enthalten, die er zuvor für diesen Medienstrom signalisiert hatte. Die Eigenschaften dieses Kandidaten, wie im SDP signalisiert -- die Priorität, Foundation, Typ und zugehörige Transportadresse -- SOLLTEN gleich bleiben. Die IP-Adresse, der Port und das Transportprotokoll, die diesen Kandidaten grundlegend identifizieren, MUST gleich bleiben (wenn sie sich ändern, wäre es ein neuer Kandidat). Die Komponenten-ID MUST gleich bleiben. Der Agent MAY zusätzliche Kandidaten enthalten, die er zuvor nicht angeboten hat, die er aber seit dem letzten Angebots-/Antwortaustausch gesammelt hat, einschließlich Peer-reflexiver Kandidaten.

Der Agent MAY das Standardziel für Medien ändern. Wie bei anfänglichen Angeboten MUST es einen Satz von Kandidatenattributen im Angebot geben, die diesem Standardziel entsprechen.

9.1.2.2. Existing Media Streams with ICE Completed (Bestehende Medienströme mit abgeschlossenem ICE)

Wenn ein Agent ein aktualisiertes Angebot generiert, das einen Medienstrom enthält, der zuvor etabliert wurde und für den sich ICE-Prüfungen im Zustand Completed befinden, folgt der Agent den hier definierten Verfahren.

Das Standardziel für Medien (d. h. die Werte der IP-Adressen und Ports in den m- und c-Zeilen, die für diesen Medienstrom verwendet werden) MUST der lokale Kandidat aus dem nominierten Paar mit der höchsten Priorität in der gültigen Liste für jede Komponente sein. Dies "fixiert" das Standardziel für Medien, sodass es dem Ziel entspricht, das ICE für Medien ausgewählt hat.

Der Agent MUST Kandidatenattribute für Kandidaten enthalten, die dem Standardziel für jede Komponente des Medienstroms entsprechen, und MUST KEINE anderen Kandidaten enthalten.

Zusätzlich, wenn der Agent kontrollierend ist, MUST er das a=remote-candidates-Attribut für jeden Medienstrom enthalten, dessen Checkliste im Zustand Completed ist. Das Attribut enthält die entfernten Kandidaten aus dem nominierten Paar mit der höchsten Priorität in der gültigen Liste für jede Komponente dieses Medienstroms. Es wird benötigt, um eine Race Condition zu vermeiden, bei der der kontrollierende Agent seine Paare auswählt, aber das aktualisierte Angebot die Konnektivitätsprüfungen zum kontrollierten Agenten überholt, der nicht einmal weiß, dass diese Paare gültig sind, geschweige denn ausgewählt wurden. Siehe Anhang B.6 für eine Erläuterung dieser Race Condition.

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

9.1.3.1. Existing Media Streams with ICE Running (Bestehende Medienströme mit laufendem ICE)

Dieser Abschnitt beschreibt Verfahren für Lite-Implementierungen für bestehende Ströme, für die ICE läuft.

Eine Lite-Implementierung MUST alle ihre Kandidaten für jede Komponente jedes Medienstroms in einem a=candidate-Attribut in jedem nachträglichen Angebot enthalten. Diese Kandidaten werden identisch zu den Verfahren für anfängliche Angebote gebildet, wie in Abschnitt 4.2 beschrieben.

Eine Lite-Implementierung MUST KEINE zusätzlichen Host-Kandidaten in einem nachträglichen Angebot hinzufügen. Wenn ein Agent zusätzliche Kandidaten anbieten muss, MUST er ICE neu starten.

Die Benutzernamenfragmente, das Passwort und das Implementierungsniveau MUST dieselben bleiben wie zuvor verwendet. Wenn ein Agent eines dieser Elemente ändern muss, MUST er ICE für diesen Medienstrom neu starten.

9.1.3.2. Existing Media Streams with ICE Completed (Bestehende Medienströme mit abgeschlossenem ICE)

Wenn ICE für einen Medienstrom abgeschlossen ist, MUST das Standardziel für diesen Medienstrom auf den entfernten Kandidaten des Kandidatenpaares für diese Komponente in der gültigen Liste gesetzt werden. Für eine Lite-Implementierung gibt es immer nur ein einzelnes Kandidatenpaar in der gültigen Liste für jede Komponente eines Medienstroms. Zusätzlich MUST der Agent ein Kandidatenattribut für jedes Standardziel enthalten.

Zusätzlich, wenn der Agent kontrollierend ist (was nur passiert, wenn beide Agenten Lite sind), MUST der Agent das a=remote-candidates-Attribut für jeden Medienstrom enthalten. Das Attribut enthält die entfernten Kandidaten aus den Kandidatenpaaren in der gültigen Liste (ein Paar für jede Komponente jedes Medienstroms).

9.2. Receiving the Offer and Generating an Answer (Empfangen des Angebots und Generieren einer Antwort)

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

Beim Empfang eines nachträglichen Angebots innerhalb einer bestehenden Sitzung MUST ein Agent die Verifizierungsverfahren in Abschnitt 5.1 erneut anwenden, ohne Rücksicht auf die Ergebnisse der Verifizierung aus früheren Angebots-/Antwortaustauschen. Tatsächlich ist es möglich, dass ein früherer Angebots-/Antwortaustausch dazu führte, dass ICE nicht verwendet wurde, aber als Folge eines nachträglichen Austauschs verwendet wird.

9.2.1.1. Detecting ICE Restart (Erkennen eines ICE-Neustarts)

Wenn das Angebot eine Änderung in den a=ice-ufrag- oder a=ice-pwd-Attributen im Vergleich zum vorherigen SDP vom Peer enthielt, zeigt dies an, dass ICE für diesen Medienstrom neu gestartet wird. Wenn alle Medienströme neu gestartet werden, dann wird ICE insgesamt neu gestartet.

Wenn ICE für einen Medienstrom neu gestartet wird:

• Der Agent MUST die a=ice-ufrag- und a=ice-pwd-Attribute in der Antwort ändern.

• Der Agent MAY sein Implementierungsniveau in der Antwort ändern.

Ein Agent setzt den Rest der Felder im SDP für diesen Medienstrom so, wie er es in einer anfänglichen Antwort auf diesen Medienstrom tun würde (siehe Abschnitt 4.3). Folglich MAY der Satz von Kandidaten einige, keine oder alle der vorherigen Kandidaten für diesen Strom enthalten und MAY einen völlig neuen Satz von Kandidaten enthalten, die wie in Abschnitt 4.1.1 beschrieben gesammelt wurden.

9.2.1.2. New Media Stream (Neuer Medienstrom)

Wenn das Angebot einen neuen Medienstrom enthält, setzt der Agent die Felder in der Antwort so, als hätte er ein anfängliches Angebot erhalten, das diesen Medienstrom enthält (siehe Abschnitt 4.3). Dies führt dazu, dass die ICE-Verarbeitung für diesen Medienstrom beginnt.

9.2.1.3. Removed Media Stream (Entfernter Medienstrom)

Wenn ein Angebot einen Medienstrom enthält, dessen Port Null ist, MUST der Agent KEINE Kandidatenattribute für diesen Medienstrom in seine Antwort aufnehmen und SOLLTE KEINE anderen ICE-bezogenen Attribute, die in Abschnitt 15 definiert sind, für diesen Medienstrom aufnehmen.

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

Sofern der Agent keinen ICE-Neustart aus dem Angebot erkannt hat, MUST die Benutzernamenfragmente, das Passwort und das Implementierungsniveau dieselben bleiben wie zuvor verwendet. Wenn ein Agent eines dieser Elemente ändern muss, MUST er ICE für diesen Medienstrom neu starten, indem er ein Angebot generiert; ICE kann in einer Antwort nicht neu gestartet werden.

Zusätzliche Verhaltensweisen hängen vom Zustand der ICE-Verarbeitung für diesen Medienstrom ab.

9.2.2.1. Existing Media Streams with ICE Running and no remote-candidates (Bestehende Medienströme mit laufendem ICE und keinen remote-candidates)

Wenn ICE für einen Medienstrom läuft und das Angebot für diesen Medienstrom das remote-candidates-Attribut fehlte, sind die Regeln für die Konstruktion der Antwort identisch mit denen für den Anbieter, wie in Abschnitt 9.1.2.1 beschrieben.

9.2.2.2. Existing Media Streams with ICE Completed and no remote-candidates (Bestehende Medienströme mit abgeschlossenem ICE und keinen remote-candidates)

Wenn ICE für einen Medienstrom Completed ist und das Angebot für diesen Medienstrom das remote-candidates-Attribut fehlte, sind die Regeln für die Konstruktion der Antwort identisch mit denen für den Anbieter, wie in Abschnitt 9.1.2.2 beschrieben, außer dass der Antwortende das a=remote-candidates-Attribut NICHT in die Antwort aufnehmen DARF.

9.2.2.3. Existing Media Streams and remote-candidates (Bestehende Medienströme und remote-candidates)

Ein kontrollierter Agent erhält ein Angebot mit dem a=remote-candidates-Attribut für einen Medienstrom, wenn sein Peer die ICE-Verarbeitung für diesen Medienstrom abgeschlossen hat. Dieses Attribut ist im Angebot vorhanden, um mit einer Race Condition zwischen dem Empfang des Angebots und dem Empfang der Binding-Antwort umzugehen, die dem Antwortenden mitteilt, welcher Kandidat von ICE ausgewählt wird. Siehe Anhang B.6 für eine Erklärung dieser Race Condition. Folglich hängt die Verarbeitung eines Angebots mit diesem Attribut vom Gewinner des Rennens ab.

Der Agent bildet ein Kandidatenpaar für jede Komponente des Medienstroms durch:

• Setzen des entfernten Kandidaten gleich dem Standardziel des Anbieters für diese Komponente (z. B. den Inhalt der m- und c-Zeilen für RTP und das a=rtcp-Attribut für RTCP)

• Setzen des lokalen Kandidaten gleich der Transportadresse für dieselbe Komponente im a=remote-candidates-Attribut im Angebot.

Der Agent prüft dann, ob jedes dieser Kandidatenpaare in der gültigen Liste vorhanden ist. Wenn ein bestimmtes Paar nicht in der gültigen Liste ist, hat die Prüfung das Rennen "verloren". Nennen Sie ein solches Paar ein "Verliererpaar".

Der Agent findet alle Paare in der Checkliste, deren entfernte Kandidaten gleich dem entfernten Kandidaten im Verliererpaar sind:

• Wenn keines der Paare In-Progress ist und mindestens eines Failed ist, ist es höchstwahrscheinlich, dass ein Netzwerkfehler, wie eine Netzwerkpartition oder schwerwiegender Paketverlust, aufgetreten ist. Der Agent SOLLTE eine Antwort für diesen Medienstrom generieren, als ob das remote-candidates-Attribut nicht vorhanden gewesen wäre, und dann ICE für diesen Strom neu starten.

• Wenn mindestens eines der Paare In-Progress ist, SOLLTE der Agent warten, bis diese Prüfungen abgeschlossen sind, und während jede abgeschlossen wird, die Verarbeitung in diesem Abschnitt wiederholen, bis es keine Verliererpaare mehr gibt.

Sobald es keine Verliererpaare mehr gibt, kann der Agent die Antwort generieren. Er MUST das Standardziel für Medien auf die Kandidaten im remote-candidates-Attribut aus dem Angebot setzen (jeder von ihnen wird nun der lokale Kandidat eines Kandidatenpaares in der gültigen Liste sein). Er MUST ein Kandidatenattribut in die Antwort für jeden Kandidaten im remote-candidates-Attribut im Angebot aufnehmen.

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

Wenn das empfangene Angebot das remote-candidates-Attribut für einen Medienstrom enthält, bildet der Agent ein Kandidatenpaar für jede Komponente des Medienstroms durch:

• Setzen des entfernten Kandidaten gleich dem Standardziel des Anbieters für diese Komponente (z. B. den Inhalt der m- und c-Zeilen für RTP und das a=rtcp-Attribut für RTCP).

• Setzen des lokalen Kandidaten gleich der Transportadresse für dieselbe Komponente im a=remote-candidates-Attribut im Angebot.

Er platziert diese Kandidaten dann in die Valid-Liste für den Medienstrom. Der Zustand der ICE-Verarbeitung für diesen Medienstrom wird auf Completed gesetzt.

Darüber hinaus, wenn der Agent glaubte, er sei kontrollierend, aber das Angebot das remote-candidates-Attribut enthielt, glauben beide Agenten, sie seien kontrollierend. In diesem Fall hätten beide ungefähr zur gleichen Zeit aktualisierte Angebote gesendet. Das Signalisierungsprotokoll, das die Angebots-/Antwortaustausche trägt, wird jedoch diesen Glare-Zustand aufgelöst haben, sodass ein Agent immer der 'Gewinner' ist, indem sein Angebot empfangen wurde, bevor sein Peer ein Angebot gesendet hat. Der Gewinner übernimmt die Rolle des Kontrollierten, sodass der Verlierer (der in diesem Abschnitt betrachtete Antwortende) seine Rolle auf kontrolliert ändern MUST. Folglich, wenn der Agent ein aktualisiertes Angebot senden wollte, da er basierend auf den Regeln in Abschnitt 8.2.2 kontrollierend war, muss er dies nicht mehr tun.

Neben dem möglichen Rollenwechsel, der Änderung in der Valid-Liste und den Zustandsänderungen wird die Konstruktion der Antwort identisch zur Konstruktion eines Angebots durchgeführt, wie in Abschnitt 9.1.3 beschrieben.

9.3. Updating the Check and Valid Lists (Aktualisierung der Check- und Valid-Listen)

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

9.3.1.1. ICE Restarts (ICE-Neustarts)

Der Agent MUST die nominierten Paare mit der höchsten Priorität in der Valid-Liste für jede Komponente des Medienstroms, genannt die vorherigen ausgewählten Paare, vor dem Neustart speichern. Der Agent wird weiterhin Medien unter Verwendung dieser Paare senden, wie in Abschnitt 11.1 beschrieben. Sobald diese Ziele notiert sind, MUST der Agent die Valid- und Checklisten löschen und dann die Checkliste und ihre Zustände neu berechnen, wie in Abschnitt 5.7 beschrieben.

9.3.1.2. New Media Stream (Neuer Medienstrom)

Wenn der Angebots-/Antwortaustausch einen neuen Medienstrom hinzugefügt hat, MUST der Agent eine neue Checkliste dafür erstellen (und natürlich eine leere Valid-Liste zu Beginn), wie in Abschnitt 5.7 beschrieben.

9.3.1.3. Removed Media Stream (Entfernter Medienstrom)

Wenn der Angebots-/Antwortaustausch einen Medienstrom entfernt hat oder eine Antwort einen angebotenen Medienstrom abgelehnt hat, MUST ein Agent die Valid-Liste für diesen Medienstrom löschen. Er MUST alle laufenden STUN-Transaktionen für diesen Medienstrom beenden. Ein Agent MUST die Checkliste für diesen Medienstrom entfernen und alle ausstehenden gewöhnlichen Prüfungen dafür stornieren.

9.3.1.4. ICE Continuing for Existing Media Stream (ICE wird für bestehenden Medienstrom fortgesetzt)

Die Valid-Liste wird durch einen aktualisierten Angebots-/Antwortaustausch nicht beeinflusst, es sei denn, ICE wird neu gestartet.

Wenn sich ein Agent im Zustand Running für diesen Medienstrom befindet, wird die Checkliste aktualisiert (die Checkliste ist irrelevant, wenn der Zustand abgeschlossen ist). Dazu berechnet der Agent die Checkliste unter Verwendung der in Abschnitt 5.7 beschriebenen Verfahren neu. Wenn ein Paar auf der neuen Checkliste auch auf der vorherigen Checkliste war und sein Zustand Waiting, In-Progress, Succeeded oder Failed war, wird sein Zustand übernommen. Andernfalls wird sein Zustand auf Frozen gesetzt.

Wenn keine der Checklisten aktiv ist (was bedeutet, dass die Paare in jeder Checkliste Frozen sind), setzt der Full-Mode-Agent das erste Paar in der Checkliste für den ersten Medienstrom auf Waiting und setzt dann den Zustand aller anderen Paare in dieser Checkliste für dieselbe Komponenten-ID und mit derselben Foundation ebenfalls auf Waiting.

Als nächstes geht der Agent jede Checkliste durch, beginnend mit dem Paar mit der höchsten Priorität. Wenn ein Paar einen Zustand von Succeeded hat und es eine Komponenten-ID von 1 hat, dann wird der Zustand aller Frozen Paare in derselben Checkliste mit derselben Foundation, deren Komponenten-IDs nicht 1 sind, auf Waiting gesetzt. Wenn für eine bestimmte Checkliste Paare für jede Komponente dieses Medienstroms im Zustand Succeeded vorhanden sind, verschiebt der Agent den Zustand aller Frozen Paare für die erste Komponente aller anderen Medienströme (und somit in verschiedenen Checklisten) mit derselben Foundation auf Waiting.

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

Wenn ICE für einen Medienstrom neu gestartet wird, MUST der Agent eine neue Valid-Liste für diesen Medienstrom starten. Er MUST die Paare in der vorherigen Valid-Liste für jede Komponente des Medienstroms, genannt die vorherigen ausgewählten Paare, speichern und weiterhin Medien dorthin senden, wie in Abschnitt 11.1 beschrieben. Der Zustand der ICE-Verarbeitung für jeden Medienstrom MUST auf Running geändert werden, und der Zustand der ICE-Verarbeitung MUST auf Running geändert werden.