5. Receiving the Initial Offer (Empfangen des initialen Angebots)
Wenn ein Agent ein initiales Angebot empfängt, prüft er, ob der Offerer ICE unterstützt, bestimmt seine eigene Rolle, sammelt Kandidaten, priorisiert sie, wählt Standardkandidaten aus, codiert und sendet eine Antwort und bildet bei vollständigen Implementierungen die Prüflisten und beginnt mit Konnektivitätsprüfungen.
5.1. Verifying ICE Support (Überprüfung der ICE-Unterstützung)
Der Agent fährt mit den in dieser Spezifikation definierten ICE-Verfahren fort, wenn für jeden Medienstrom im empfangenen SDP das Standardziel für jede Komponente dieses Medienstroms in einem candidate-Attribut erscheint. Beispielsweise erscheinen im Fall von RTP die IP-Adresse und der Port in den c- bzw. m-Zeilen in einem candidate-Attribut, und der Wert im rtcp-Attribut erscheint in einem candidate-Attribut.
Wenn diese Bedingung nicht erfüllt ist, MUST (muss) der Agent das SDP basierend auf den normalen RFC 3264-Verfahren verarbeiten, ohne einen der im Rest dieser Spezifikation beschriebenen ICE-Mechanismen zu verwenden, mit den folgenden Ausnahmen:
-
Der Agent MUST (muss) die Regeln von Abschnitt 10 befolgen, die Keepalive-Verfahren für alle Agenten beschreiben.
-
Wenn der Agent nicht mit ICE fortfährt, weil a=candidate-Attribute vorhanden waren, aber keines mit dem Standardziel des Medienstroms übereinstimmte, MUST (muss) der Agent ein a=ice-mismatch-Attribut in seine Antwort aufnehmen.
-
Wenn die Standardkandidaten Relay-Kandidaten waren, die über einen TURN-Server gelernt wurden, MUST (muss) der Agent Berechtigungen im TURN-Server für die IP-Adressen erstellen, die er von seinem Peer im gerade empfangenen SDP gelernt hat. Wenn dies nicht geschieht, können anfängliche Pakete im Medienstrom vom Peer verloren gehen.
5.2. Determining Role (Bestimmung der Rolle)
Für jede Sitzung übernimmt jeder Agent eine Rolle. Es gibt zwei Rollen: kontrollierend (controlling) und kontrolliert (controlled). Der kontrollierende Agent ist für die Auswahl der endgültigen Kandidatenpaare verantwortlich, die für die Kommunikation verwendet werden. Für einen vollständigen Agenten bedeutet dies, die Kandidatenpaare zu nominieren, die von ICE für jeden Medienstrom verwendet werden können, und bei Bedarf das aktualisierte Angebot basierend auf der Auswahl von ICE zu generieren. Für eine Lite-Implementierung bedeutet das Sein des kontrollierenden Agenten, ein Kandidatenpaar basierend auf denen im Angebot und in der Antwort auszuwählen (für IPv4 gibt es immer nur ein Paar) und dann bei Bedarf ein aktualisiertes Angebot zu generieren, das diese Auswahl widerspiegelt (für einen reinen IPv4-Host ist dies nie erforderlich). Dem kontrollierten Agenten wird mitgeteilt, welche Kandidatenpaare für jeden Medienstrom verwendet werden sollen, und er generiert kein aktualisiertes Angebot, um diese Informationen zu signalisieren. Die folgenden Abschnitte beschreiben detailliert die tatsächlichen Verfahren, die von kontrollierenden und kontrollierten Knoten befolgt werden.
Die Regeln zur Bestimmung der Rolle und die Auswirkungen auf das Verhalten sind wie folgt:
-
Beide Agenten sind vollständig: Der Agent, der das Angebot generiert hat, das die ICE-Verarbeitung gestartet hat, MUST (muss) die kontrollierende Rolle übernehmen, und der andere MUST (muss) die kontrollierte Rolle übernehmen. Beide Agenten bilden Prüflisten, führen die ICE-Zustandsmaschinen aus und generieren Konnektivitätsprüfungen. Der kontrollierende Agent führt die Logik in Abschnitt 8.1 aus, um Paare zu nominieren, die von ICE ausgewählt werden, und dann beenden beide Agenten ICE wie in Abschnitt 8.1.2 beschrieben. In ungewöhnlichen Fällen, die in Anhang B.11 beschrieben sind, ist es möglich, dass beide Agenten fälschlicherweise glauben, sie seien kontrolliert oder kontrollierend. Um dies zu lösen, MUST (muss) jeder Agent eine Zufallszahl, den sogenannten Entscheidungswert (Tie-Breaker), auswählen, der gleichmäßig zwischen 0 und (2**64) - 1 verteilt ist (d. h. eine positive 64-Bit-Ganzzahl). Diese Zahl wird bei Konnektivitätsprüfungen verwendet, um diesen Fall zu erkennen und zu beheben, wie in Abschnitt 7.1.2.2 beschrieben.
-
Ein Agent vollständig, einer Lite: Der vollständige Agent MUST (muss) die kontrollierende Rolle übernehmen, und der Lite-Agent MUST (muss) die kontrollierte Rolle übernehmen. Der vollständige Agent bildet Prüflisten, führt die ICE-Zustandsmaschinen aus und generiert Konnektivitätsprüfungen. Dieser Agent führt die Logik in Abschnitt 8.1 aus, um Paare zu nominieren, die von ICE ausgewählt werden, und verwendet die Logik in Abschnitt 8.1.2, um ICE zu beenden. Die Lite-Implementierung hört einfach auf Konnektivitätsprüfungen, empfängt sie und antwortet darauf und schließt dann ICE wie in Abschnitt 8.2 beschrieben ab. Für die Lite-Implementierung gilt der Zustand der ICE-Verarbeitung für jeden Medienstrom als Running (In Ausführung), und der Zustand von ICE insgesamt ist Running.
-
Beide Lite: Der Agent, der das Angebot generiert hat, das die ICE-Verarbeitung gestartet hat, MUST (muss) die kontrollierende Rolle übernehmen, und der andere MUST (muss) die kontrollierte Rolle übernehmen. In diesem Fall werden niemals Konnektivitätsprüfungen gesendet. Stattdessen führt jeder Agent, sobald der Offer/Answer-Austausch abgeschlossen ist, die in Abschnitt 8 beschriebene Verarbeitung ohne Konnektivitätsprüfungen durch. Es ist möglich, dass beide Agenten glauben, sie seien kontrolliert oder kontrollierend. Im letzteren Fall wird der Konflikt durch Glare-Erkennungsfunktionen im Signalisierungsprotokoll gelöst, das den Offer/Answer-Austausch überträgt. Der Zustand der ICE-Verarbeitung für jeden Medienstrom gilt als Running, und der Zustand von ICE insgesamt ist Running.
Sobald Rollen für eine Sitzung bestimmt sind, bleiben sie bestehen, es sei denn, ICE wird neu gestartet. Ein ICE-Neustart (Abschnitt 9.1) führt zu einer neuen Auswahl von Rollen und Entscheidungswerten.
5.3. Gathering Candidates (Sammeln von Kandidaten)
Der Prozess zum Sammeln von Kandidaten beim Antwortenden ist identisch mit dem Prozess für den Offerer, wie in Abschnitt 4.1.1 für vollständige Implementierungen und Abschnitt 4.2 für Lite-Implementierungen beschrieben. Es ist RECOMMENDED (empfohlen), dass dieser Prozess sofort nach Erhalt des Angebots beginnt, bevor der Benutzer benachrichtigt wird. Ein solches Sammeln MAY (kann) beginnen, wenn ein Agent startet.
5.4. Prioritizing Candidates (Priorisierung von Kandidaten)
Der Prozess zur Priorisierung von Kandidaten beim Antwortenden ist identisch mit dem Prozess, dem der Offerer folgt, wie in Abschnitt 4.1.2 für vollständige Implementierungen und Abschnitt 4.2 für Lite-Implementierungen beschrieben.
5.5. Choosing Default Candidates (Auswahl von Standardkandidaten)
Der Prozess zur Auswahl von Standardkandidaten beim Antwortenden ist identisch mit dem Prozess, dem der Offerer folgt, wie in Abschnitt 4.1.4 für vollständige Implementierungen und Abschnitt 4.2 für Lite-Implementierungen beschrieben.
5.6. Encoding the SDP (Codierung des SDP)
Der Prozess zur Codierung des SDP beim Antwortenden ist identisch mit dem Prozess, dem der Offerer sowohl für vollständige als auch für Lite-Implementierungen folgt, wie in Abschnitt 4.3 beschrieben.
5.7. Forming the Check Lists (Bildung der Prüflisten)
Das Bilden von Prüflisten erfolgt nur durch vollständige Implementierungen. Lite-Implementierungen MUST (müssen) die in diesem Abschnitt definierten Schritte überspringen.
Es gibt eine Prüfliste pro verwendetem Medienstrom, der aus dem Offer/Answer-Austausch resultiert. Um die Prüfliste für einen Medienstrom zu bilden, bildet der Agent Kandidatenpaare, berechnet eine Kandidatenpaarpriorität, ordnet die Paare nach Priorität, bereinigt sie und setzt ihre Zustände. Diese Schritte werden in diesem Abschnitt beschrieben.
5.7.1. Forming Candidate Pairs (Bildung von Kandidatenpaaren)
Zuerst nimmt der Agent jeden seiner Kandidaten für einen Medienstrom (genannt LOKALE KANDIDATEN) und paart sie mit den Kandidaten, die er von seinem Peer erhalten hat (genannt REMOTE KANDIDATEN) für diesen Medienstrom. Um die in Abschnitt 18.5.2 beschriebenen Angriffe zu verhindern, MAY (können) Agenten die Anzahl der Kandidaten begrenzen, die sie in einem Angebot oder einer Antwort akzeptieren. Ein lokaler Kandidat wird genau dann mit einem Remote-Kandidaten gepaart, wenn die beiden Kandidaten dieselbe Komponenten-ID und dieselbe IP-Adressversion haben. Es ist möglich, dass einige der lokalen Kandidaten nicht mit Remote-Kandidaten gepaart werden und einige der Remote-Kandidaten nicht mit lokalen Kandidaten gepaart werden. Dies kann passieren, wenn ein Agent keine Kandidaten für alle Komponenten eines Medienstroms enthält. Wenn dies geschieht, wird die Anzahl der Komponenten für diesen Medienstrom effektiv reduziert und als gleich dem Minimum der maximalen Komponenten-ID über beide Agenten hinweg betrachtet, die von jedem Agenten über alle Komponenten für den Medienstrom bereitgestellt wird.
Im Fall von RTP würde dies passieren, wenn ein Agent Kandidaten für RTCP bereitstellt und der andere nicht. Als weiteres Beispiel kann der Offerer RTP und RTCP auf demselben Port multiplexen und signalisiert, dass er dies im SDP über ein SDP-Attribut [RFC5761] tun kann. Da der Offerer jedoch nicht weiß, ob der Antwortende ein solches Multiplexing durchführen kann, schließt der Offerer Kandidaten für RTP und RTCP auf separaten Ports ein, sodass das Angebot zwei Komponenten pro Medienstrom hat. Wenn der Antwortende ein solches Multiplexing durchführen kann, würde er nur eine einzelne Komponente für jeden Kandidaten einschließen - für das kombinierte RTP/RTCP-Mux. ICE würde am Ende so handeln, als gäbe es nur eine einzelne Komponente für diesen Kandidaten.
Die Kandidatenpaare, deren lokale und Remote-Kandidaten beide die Standardkandidaten für eine bestimmte Komponente sind, werden wenig überraschend als Standardkandidatenpaar für diese Komponente bezeichnet. Dies ist das Paar, das verwendet würde, um Medien zu übertragen, wenn beide Agenten ICE nicht kennen würden.
Um das Verständnis zu erleichtern, zeigt Abbildung 6 die Beziehungen zwischen mehreren Schlüsselkonzepten -- Transportadressen, Kandidaten, Kandidatenpaare und Prüflisten, zusätzlich zur Angabe der Haupteigenschaften von Kandidaten und Kandidatenpaaren.
+------------------------------------------+
| |
| +---------------------+ |
| |+----+ +----+ +----+ | +Type |
| || IP | |Port| |Tran| | +Priority |
| ||Addr| | | | | | +Foundation |
| |+----+ +----+ +----+ | +ComponentiD |
| | Transport | +RelatedAddr |
| | Addr | |
| +---------------------+ +Base |
| Candidate |
+------------------------------------------+
* *
* *************************************
* *
+-------------------------------+
.| |
| Local Remote |
| +----+ +----+ +default? |
| |Cand| |Cand| +valid? |
| +----+ +----+ +nominated?|
| +State |
| |
| |
| Candidate Pair |
+-------------------------------+
* *
* ************
* *
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
Check
List
Abbildung 6: Konzeptionelles Diagramm einer Prüfliste
5.7.2. Computing Pair Priority and Ordering Pairs (Berechnung der Paarpriorität und Ordnen der Paare)
Sobald die Paare gebildet sind, wird eine Kandidatenpaarpriorität berechnet. Sei G die Priorität für den Kandidaten, der vom kontrollierenden Agenten bereitgestellt wird. Sei D die Priorität für den Kandidaten, der vom kontrollierten Agenten bereitgestellt wird. Die Priorität für ein Paar wird berechnet als:
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Wobei G>D?1:0 ein Ausdruck ist, dessen Wert 1 ist, wenn G größer als D ist, und andernfalls 0. Sobald die Priorität zugewiesen ist, sortiert der Agent die Kandidatenpaare in absteigender Reihenfolge der Priorität. Wenn zwei Paare eine identische Priorität haben, ist die Reihenfolge zwischen ihnen willkürlich.
5.7.3. Pruning the Pairs (Bereinigen der Paare)
Diese sortierte Liste von Kandidatenpaaren wird verwendet, um eine Sequenz von Konnektivitätsprüfungen zu bestimmen, die durchgeführt werden. Jede Prüfung beinhaltet das Senden einer Anforderung von einem lokalen Kandidaten an einen Remote-Kandidaten. Da ein Agent Anforderungen nicht direkt von einem Reflexiven Kandidaten senden kann, sondern nur von seiner Basis, geht der Agent als nächstes die sortierte Liste der Kandidatenpaare durch. Für jedes Paar, bei dem der lokale Kandidat Server-Reflexiv ist, MUST (muss) der Server-Reflexive Kandidat durch seine Basis ersetzt werden. Sobald dies geschehen ist, MUST (muss) der Agent die Liste bereinigen. Dies geschieht durch Entfernen eines Paares, wenn seine lokalen und Remote-Kandidaten identisch mit den lokalen und Remote-Kandidaten eines Paares weiter oben auf der Prioritätsliste sind. Das Ergebnis ist eine Sequenz von geordneten Kandidatenpaaren, die als Prüfliste für diesen Medienstrom bezeichnet wird.
Darüber hinaus MUST (muss) ein Agent, um die in Abschnitt 18.5.2 beschriebenen Angriffe zu begrenzen, die Gesamtzahl der Konnektivitätsprüfungen, die der Agent über alle Prüflisten hinweg durchführt, auf einen bestimmten Wert begrenzen, und dieser Wert MUST (muss) konfigurierbar sein. Ein Standardwert von 100 wird RECOMMENDED (empfohlen). Diese Begrenzung wird durch Verwerfen der Kandidatenpaare mit niedrigerer Priorität durchgesetzt, bis es weniger als 100 sind. Es ist RECOMMENDED (empfohlen), dass nach Möglichkeit ein niedrigerer Wert verwendet wird, der auf die maximale Anzahl plausibler Prüfungen gesetzt wird, die in einer tatsächlichen Bereitstellungskonfiguration auftreten könnten. Die Anforderung an die Konfiguration soll ein Werkzeug bereitstellen, um diesen Wert im Feld zu korrigieren, wenn er sich nach der Bereitstellung als problematisch erweist.
5.7.4. Computing States (Berechnung von Zuständen)
Jedes Kandidatenpaar in der Prüfliste hat eine Foundation und einen Zustand. Die Foundation ist die Kombination der Foundations der lokalen und Remote-Kandidaten im Paar. Der Zustand wird zugewiesen, sobald die Prüfliste für jeden Medienstrom berechnet wurde. Es gibt fünf potenzielle Werte, die der Zustand haben kann:
-
Waiting (Wartend): Für dieses Paar wurde noch keine Prüfung durchgeführt, und sie kann durchgeführt werden, sobald es das wartende Paar mit der höchsten Priorität auf der Prüfliste ist.
-
In-Progress (In Bearbeitung): Für dieses Paar wurde eine Prüfung gesendet, aber die Transaktion ist in Bearbeitung.
-
Succeeded (Erfolgreich): Eine Prüfung für dieses Paar wurde bereits durchgeführt und lieferte ein erfolgreiches Ergebnis.
-
Failed (Fehlgeschlagen): Eine Prüfung für dieses Paar wurde bereits durchgeführt und schlug fehl, entweder indem nie eine Antwort erzeugt wurde oder eine nicht behebbare Fehlerantwort erzeugt wurde.
-
Frozen (Eingefroren): Eine Prüfung für dieses Paar wurde nicht durchgeführt, und sie kann noch nicht durchgeführt werden, bis eine andere Prüfung erfolgreich ist, was es diesem Paar ermöglicht, aufzutauen und in den Zustand Waiting überzugehen.
Während ICE läuft, bewegen sich die Paare zwischen den Zuständen, wie in Abbildung 7 gezeigt.
+-----------+
| |
| |
| Frozen |
| |
| |
+-----------+
|
|unfreeze
|
V
+-----------+ +-----------+
| | | |
| | perform | |
| Waiting |-------->|In-Progress|
| | | |
| | | |
+-----------+ +-----------+
/ |
// |
// |
// |
/ |
// |
failure // |success
// |
/ |
// |
// |
// |
V V
+-----------+ +-----------+
| | | |
| | | |
| Failed | | Succeeded |
| | | |
| | | |
+-----------+ +-----------+
Abbildung 7: Paarzustands-FSM
Die Anfangszustände für jedes Paar in einer Prüfliste werden durch Ausführen der folgenden Schrittfolge berechnet:
-
Der Agent setzt alle Paare in jeder Prüfliste in den Zustand Frozen.
-
Der Agent untersucht die Prüfliste für den ersten Medienstrom (ein Medienstrom ist der erste Medienstrom, wenn er durch die erste m-Zeile im SDP-Angebot und in der Antwort beschrieben wird). Für diesen Medienstrom:
- Für alle Paare mit derselben Foundation setzt er den Zustand des Paares mit der niedrigsten Komponenten-ID auf Waiting. Wenn es mehr als ein solches Paar gibt, wird das mit der höchsten Priorität verwendet.
Eine der Prüflisten wird eine gewisse Anzahl von Paaren im Zustand Waiting haben, und die anderen Prüflisten werden alle ihre Paare im Zustand Frozen haben. Eine Prüfliste mit mindestens einem Paar, das wartet, wird als aktive Prüfliste (active check list) bezeichnet, und eine Prüfliste mit allen Paaren eingefroren wird als eingefrorene Prüfliste (frozen check list) bezeichnet.
Die Prüfliste selbst ist einem Zustand zugeordnet, der den Zustand der ICE-Prüfungen für diesen Medienstrom erfasst. Es gibt drei Zustände:
-
Running (In Ausführung): In diesem Zustand sind ICE-Prüfungen für diesen Medienstrom noch in Bearbeitung.
-
Completed (Abgeschlossen): In diesem Zustand haben ICE-Prüfungen nominierte Paare für jede Komponente des Medienstroms erzeugt. Folglich war ICE erfolgreich und Medien können gesendet werden.
-
Failed (Fehlgeschlagen): In diesem Zustand wurden die ICE-Prüfungen für diesen Medienstrom nicht erfolgreich abgeschlossen.
Wenn eine Prüfliste erstmals als Folge eines Offer/Answer-Austauschs erstellt wird, wird sie in den Zustand Running versetzt.
Die ICE-Verarbeitung über alle Medienströme hinweg hat ebenfalls einen damit verbundenen Zustand. Dieser Zustand ist gleich Running, während die ICE-Verarbeitung im Gange ist. Der Zustand ist Completed, wenn die ICE-Verarbeitung abgeschlossen ist, und Failed, wenn sie ohne Erfolg fehlgeschlagen ist. Regeln für den Übergang zwischen Zuständen werden unten beschrieben.
5.8. Scheduling Checks (Planung von Prüfungen)
Prüfungen werden nur von vollständigen Implementierungen generiert. Lite-Implementierungen MUST (müssen) die in diesem Abschnitt beschriebenen Schritte überspringen.
Ein Agent führt gewöhnliche Prüfungen (ordinary checks) und ausgelöste Prüfungen (triggered checks) durch. Die Generierung beider Prüfungen wird durch einen Timer gesteuert, der für jeden Medienstrom periodisch ausgelöst wird. Der Agent unterhält eine FIFO-Warteschlange, die als Warteschlange für ausgelöste Prüfungen (triggered check queue) bezeichnet wird und Kandidatenpaare enthält, für die bei der nächsten verfügbaren Gelegenheit Prüfungen gesendet werden sollen. Wenn der Timer ausgelöst wird, entfernt der Agent das oberste Paar aus der Warteschlange für ausgelöste Prüfungen, führt eine Konnektivitätsprüfung für dieses Paar durch und setzt den Zustand des Kandidatenpaars auf In-Progress. Wenn sich keine Paare in der Warteschlange für ausgelöste Prüfungen befinden, wird eine gewöhnliche Prüfung gesendet.
Sobald der Agent die Prüflisten wie in Abschnitt 5.7 beschrieben berechnet hat, setzt er einen Timer für jede aktive Prüfliste. Der Timer wird alle Ta*N Sekunden ausgelöst, wobei N die Anzahl der aktiven Prüflisten ist (anfänglich gibt es nur eine aktive Prüfliste). Implementierungen MAY (können) den Timer so einstellen, dass er seltener als dies ausgelöst wird. Implementierungen SHOULD (sollten) darauf achten, diese Timer zu verteilen, damit sie nicht für jeden Medienstrom gleichzeitig ausgelöst werden. Ta und der Neuübertragungstimer RTO werden wie in Abschnitt 16 beschrieben berechnet. Die Multiplikation mit N ermöglicht es, diesen aggregierten Prüfungsdurchsatz auf alle aktiven Prüflisten aufzuteilen. Der erste Timer wird sofort ausgelöst, sodass der Agent in dem Moment, in dem der Offer/Answer-Austausch stattgefunden hat, eine Konnektivitätsprüfung durchführt, gefolgt von der nächsten Prüfung Ta Sekunden später (da es nur eine aktive Prüfliste gibt).
Wenn der Timer ausgelöst wird und keine ausgelöste Prüfung gesendet werden muss, MUST (muss) der Agent eine gewöhnliche Prüfung wie folgt auswählen:
-
Finde das Paar mit der höchsten Priorität in dieser Prüfliste, das sich im Zustand Waiting befindet.
-
Wenn es ein solches Paar gibt:
- Sende eine STUN-Prüfung vom lokalen Kandidaten dieses Paares an den Remote-Kandidaten dieses Paares. Die Verfahren zum Bilden der STUN-Anforderung zu diesem Zweck sind in Abschnitt 7.1.2 beschrieben.
- Setze den Zustand des Kandidatenpaars auf In-Progress.
-
Wenn es kein solches Paar gibt:
- Finde das Paar mit der höchsten Priorität in dieser Prüfliste, das sich im Zustand Frozen befindet.
- Wenn es ein solches Paar gibt:
- Taue das Paar auf.
- Führe eine Prüfung für dieses Paar durch, wodurch sein Zustand in In-Progress übergeht.
- Wenn es kein solches Paar gibt:
- Beende den Timer für diese Prüfliste.
Um die Nachrichtenintegrität für die Prüfung zu berechnen, verwendet der Agent das Remote-Benutzernamenfragment und das Passwort, die aus dem SDP von seinem Peer gelernt wurden. Das lokale Benutzernamenfragment ist dem Agenten für seinen eigenen Kandidaten direkt bekannt.