7. Performing Connectivity Checks (Durchführung von Konnektivitätsprüfungen)

Dieser Abschnitt beschreibt, wie Konnektivitätsprüfungen durchgeführt werden. Alle ICE-Implementierungen müssen [RFC5389] entsprechen, im Gegensatz zum älteren [RFC3489]. Während jedoch eine vollständige Implementierung sowohl Prüfungen generiert (als STUN-Client agiert) als auch empfängt (als STUN-Server agiert), empfängt eine Lite-Implementierung nur Prüfungen und agiert somit nur als STUN-Server.

7.1. STUN Client Procedures (STUN-Client-Verfahren)

Diese Verfahren definieren, wie ein Agent eine Konnektivitätsprüfung sendet, sei es eine gewöhnliche oder eine getriggerte Prüfung. Diese Verfahren gelten nur für vollständige Implementierungen.

7.1.1. Creating Permissions for Relayed Candidates (Erstellen von Berechtigungen für weitergeleitete Kandidaten)

Wenn die Konnektivitätsprüfung unter Verwendung eines weitergeleiteten lokalen Kandidaten gesendet wird, MUST der Client zuerst eine Berechtigung erstellen, falls er dies nicht bereits zuvor getan hat. Er hätte zuvor eine erstellt, wenn er dem TURN-Server mitgeteilt hätte, eine Berechtigung für den gegebenen weitergeleiteten Kandidaten gegenüber der IP-Adresse des entfernten Kandidaten zu erstellen. Um die Berechtigung zu erstellen, folgt der Agent den in [RFC5766] definierten Verfahren. Die Berechtigung MUST gegenüber der IP-Adresse des entfernten Kandidaten erstellt werden. Es wird RECOMMENDED, dass der Agent die Erstellung eines TURN-Kanals verschiebt, bis ICE abgeschlossen ist; in diesem Fall werden Berechtigungen für Konnektivitätsprüfungen normalerweise unter Verwendung einer CreatePermission-Anfrage erstellt. Sobald etabliert, MUST der Agent die Berechtigung aktiv halten, bis ICE endet.

7.1.2. Sending the Request (Senden der Anfrage)

Die Prüfung wird generiert, indem eine Binding-Anfrage von einem lokalen Kandidaten an einen entfernten Kandidaten gesendet wird. [RFC5389] beschreibt, wie Binding-Anfragen konstruiert und generiert werden. Eine Konnektivitätsprüfung MUST den STUN-Kurzzeit-Anmeldeinformationen-Mechanismus verwenden. Unterstützung für Rückwärtskompatibilität mit RFC 3489 MUST NOT verwendet oder bei Konnektivitätsprüfungen angenommen werden. Der FINGERPRINT-Mechanismus MUST für Konnektivitätsprüfungen verwendet werden.

ICE erweitert STUN durch die Definition mehrerer neuer Attribute, einschließlich PRIORITY, USE-CANDIDATE, ICE-CONTROLLED und ICE-CONTROLLING. Diese neuen Attribute sind formal in Abschnitt 19.1 definiert, und ihre Verwendung wird in den Unterabschnitten unten beschrieben. Diese STUN-Erweiterungen gelten nur für Konnektivitätsprüfungen, die für ICE verwendet werden.

7.1.2.1. PRIORITY and USE-CANDIDATE (PRIORITY und USE-CANDIDATE)

Ein Agent MUST das PRIORITY-Attribut in seine Binding-Anfrage aufnehmen. Das Attribut MUST gleich der Priorität gesetzt werden, die basierend auf dem Algorithmus in Abschnitt 4.1.2 einem Peer-reflexiven Kandidaten zugewiesen würde, sollte als Folge dieser Prüfung einer gelernt werden (siehe Abschnitt 7.1.3.2.1, wie Peer-reflexive Kandidaten gelernt werden). Dieser Prioritätswert wird identisch berechnet, wie die Priorität für den lokalen Kandidaten des Paares berechnet wurde, außer dass die Typpräferenz auf den Wert für Peer-reflexive Kandidatentypen gesetzt wird.

Der kontrollierende Agent MAY das USE-CANDIDATE-Attribut in die Binding-Anfrage aufnehmen. Der kontrollierte Agent MUST NOT es in seine Binding-Anfrage aufnehmen. Dieses Attribut signalisiert, dass der kontrollierende Agent die Prüfungen für diese Komponente beenden und das aus der Prüfung resultierende Kandidatenpaar für diese Komponente verwenden möchte. Abschnitt 8.1.1 gibt Hinweise zur Bestimmung, wann es aufgenommen werden soll.

7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING (ICE-CONTROLLED und ICE-CONTROLLING)

Der Agent MUST das ICE-CONTROLLED-Attribut in die Anfrage aufnehmen, wenn er sich in der kontrollierten Rolle befindet, und MUST das ICE-CONTROLLING-Attribut in die Anfrage aufnehmen, wenn er sich in der kontrollierenden Rolle befindet. Der Inhalt beider Attribute MUST der Tie-Breaker sein, der in Abschnitt 5.2 bestimmt wurde. Diese Attribute sind vollständig in Abschnitt 19.1 definiert.

7.1.2.3. Forming Credentials (Bilden von Anmeldeinformationen)

Eine Binding-Anfrage, die als Konnektivitätsprüfung dient, MUST den STUN-Kurzzeit-Anmeldeinformationen-Mechanismus verwenden. Der Benutzername für die Anmeldeinformationen wird gebildet, indem das vom Peer bereitgestellte Benutzernamenfragment mit dem Benutzernamenfragment des Agenten, der die Anfrage sendet, verkettet wird, getrennt durch einen Doppelpunkt (":"). Das Passwort ist gleich dem vom Peer bereitgestellten Passwort. Betrachten wir zum Beispiel den Fall, in dem Agent L der Anbieter und Agent R der Antwortende ist. Agent L hat ein Benutzernamenfragment von LFRAG für seine Kandidaten und ein Passwort von LPASS aufgenommen. Agent R hat ein Benutzernamenfragment von RFRAG und ein Passwort von RPASS bereitgestellt. Eine Konnektivitätsprüfung von L nach R verwendet den Benutzernamen RFRAG:LFRAG und ein Passwort von RPASS. Eine Konnektivitätsprüfung von R nach L verwendet den Benutzernamen LFRAG:RFRAG und ein Passwort von LPASS. Die Antworten verwenden dieselben Benutzernamen und Passwörter wie die Anfragen (beachten Sie, dass das USERNAME-Attribut in der Antwort nicht vorhanden ist).

7.1.2.4. DiffServ Treatment (DiffServ-Behandlung)

Wenn der Agent Diffserv Codepoint-Markierungen [RFC2475] in seinen Medienpaketen verwendet, SHOULD er dieselben Markierungen auf seine Konnektivitätsprüfungen anwenden.

7.1.3. Processing the Response (Verarbeitung der Antwort)

Wenn eine Binding-Antwort empfangen wird, wird sie unter Verwendung der Transaktions-ID, wie in [RFC5389] definiert, mit ihrer Binding-Anfrage korreliert, die sie dann mit dem Kandidatenpaar verknüpft, für das die Binding-Anfrage gesendet wurde. Dieser Abschnitt definiert zusätzliche Verfahren für die Verarbeitung von Binding-Antworten, die spezifisch für diese Verwendung von STUN sind.

7.1.3.1. Failure Cases (Fehlerfälle)

Wenn die STUN-Transaktion eine 487 (Role Conflict) Fehlerantwort generiert, prüft der Agent, ob er das ICE-CONTROLLED- oder ICE-CONTROLLING-Attribut in der Binding-Anfrage aufgenommen hat. Wenn die Anfrage das ICE-CONTROLLED-Attribut enthielt, MUST der Agent zur kontrollierenden Rolle wechseln, falls er dies noch nicht getan hat. Wenn die Anfrage das ICE-CONTROLLING-Attribut enthielt, MUST der Agent zur kontrollierten Rolle wechseln, falls er dies noch nicht getan hat. Sobald er gewechselt hat, MUST der Agent das Kandidatenpaar, dessen Prüfung die 487 generiert hat, in die Warteschlange für getriggerte Prüfungen einreihen. Der Zustand dieses Paares wird auf Waiting gesetzt. Wenn die getriggerte Prüfung gesendet wird, enthält sie ein ICE-CONTROLLING- oder ICE-CONTROLLED-Attribut, das ihre neue Rolle widerspiegelt. Beachten Sie jedoch, dass der Tie-Breaker-Wert MUST NOT neu ausgewählt werden.

Ein Rollenwechsel erfordert, dass ein Agent die Paarprioritäten neu berechnet (Abschnitt 5.7.2), da diese Prioritäten eine Funktion der kontrollierenden und kontrollierten Rollen sind. Der Rollenwechsel wirkt sich auch darauf aus, ob der Agent für die Auswahl nominierter Paare und die Generierung aktualisierter Angebote nach Abschluss von ICE verantwortlich ist.

Agenten MAY den Empfang von ICMP-Fehlern für Konnektivitätsprüfungen unterstützen. Wenn die STUN-Transaktion einen ICMP-Fehler generiert, setzt der Agent den Zustand des Paares auf Failed. Wenn die STUN-Transaktion eine STUN-Fehlerantwort generiert, die nicht behebbar ist (wie in [RFC5389] definiert) oder eine Zeitüberschreitung auftritt, setzt der Agent den Zustand des Paares auf Failed.

Der Agent MUST überprüfen, dass die Quell-IP-Adresse und der Port der Antwort gleich der Ziel-IP-Adresse und dem Port sind, an die die Binding-Anfrage gesendet wurde, und dass die Ziel-IP-Adresse und der Port der Antwort mit der Quell-IP-Adresse und dem Port übereinstimmen, von denen die Binding-Anfrage gesendet wurde. Mit anderen Worten, die Quell- und Zieltransportadressen in der Anfrage und den Antworten sind symmetrisch. Wenn sie nicht symmetrisch sind, setzt der Agent den Zustand des Paares auf Failed.

7.1.3.2. Success Cases (Erfolgsfälle)

Eine Prüfung gilt als erfolgreich, wenn alle folgenden Bedingungen erfüllt sind:

• Die STUN-Transaktion hat eine Erfolgsantwort generiert.
• Die Quell-IP-Adresse und der Port der Antwort entsprechen der Ziel-IP-Adresse und dem Port, an die die Binding-Anfrage gesendet wurde.
• Die Ziel-IP-Adresse und der Port der Antwort stimmen mit der Quell-IP-Adresse und dem Port überein, von denen die Binding-Anfrage gesendet wurde.

7.1.3.2.1. Discovering Peer Reflexive Candidates (Entdeckung von Peer-reflexiven Kandidaten)

Der Agent prüft die gemappte Adresse aus der STUN-Antwort. Wenn die Transportadresse mit keinem der lokalen Kandidaten übereinstimmt, die der Agent kennt, stellt die gemappte Adresse einen neuen Kandidaten dar -- einen Peer-reflexiven Kandidaten. Wie andere Kandidaten hat er einen Typ, eine Basis, eine Priorität und eine Foundation. Sie werden wie folgt berechnet:

• Sein Typ ist gleich Peer-reflexiv.
• Seine Basis wird gleich dem lokalen Kandidaten des Kandidatenpaares gesetzt, von dem die STUN-Prüfung gesendet wurde.
• Seine Priorität wird gleich dem Wert des PRIORITY-Attributs in der Binding-Anfrage gesetzt.
• Seine Foundation wird wie in Abschnitt 4.1.1.3 beschrieben ausgewählt.

Dieser Peer-reflexive Kandidat wird dann zur Liste der lokalen Kandidaten für den Medienstrom hinzugefügt. Sein Benutzernamenfragment und sein Passwort sind dieselben wie bei allen anderen lokalen Kandidaten für diesen Medienstrom.

Der Peer-reflexive Kandidat wird jedoch nicht mit anderen entfernten Kandidaten gepaart. Dies ist nicht notwendig; ein gültiges Paar wird basierend auf den Verfahren in Abschnitt 7.1.3.2.2 gleich daraus generiert. Wenn ein Agent den Peer-reflexiven Kandidaten mit anderen entfernten Kandidaten neben dem im gültigen Paar, das generiert wird, paaren möchte, MAY der Agent ein aktualisiertes Angebot generieren, das den Peer-reflexiven Kandidaten enthält. Dies führt dazu, dass er mit allen anderen entfernten Kandidaten gepaart wird.

7.1.3.2.2. Constructing a Valid Pair (Konstruktion eines gültigen Paares)

Der Agent konstruiert ein Kandidatenpaar, dessen lokaler Kandidat der gemappten Adresse der Antwort entspricht und dessen entfernter Kandidat der Zieladresse entspricht, an die die Anfrage gesendet wurde. Dies wird als gültiges Paar bezeichnet, da es durch eine STUN-Konnektivitätsprüfung validiert wurde. Das gültige Paar kann dem Paar entsprechen, das die Prüfung generiert hat, kann einem anderen Paar in der Checkliste entsprechen oder kann ein Paar sein, das sich derzeit nicht auf einer Checkliste befindet. Wenn das Paar dem Paar entspricht, das die Prüfung generiert hat, oder sich derzeit auf einer Checkliste befindet, wird es auch zur VALID LIST hinzugefügt, die vom Agenten für jeden Medienstrom verwaltet wird. Diese Liste ist zu Beginn der ICE-Verarbeitung leer und füllt sich, wenn Prüfungen durchgeführt werden, was zu gültigen Kandidatenpaaren führt.

Es wird sehr häufig vorkommen, dass das Paar nicht auf einer Checkliste steht. Erinnern Sie sich, dass die Checkliste Paare enthält, deren lokale Kandidaten niemals Server-reflexiv sind; diese Paare ließen ihre lokalen Kandidaten in die Basis der Server-reflexiven Kandidaten umwandeln und wurden dann bereinigt, wenn sie redundant waren. Wenn die Antwort auf die STUN-Prüfung eintrifft, wird die gemappte Adresse reflexiv sein, wenn sich ein NAT zwischen den beiden befindet. In diesem Fall wird das gültige Paar einen lokalen Kandidaten haben, der mit keinem der Paare in der Checkliste übereinstimmt.

Wenn das Paar nicht auf einer Checkliste steht, berechnet der Agent die Priorität für das Paar basierend auf der Priorität jedes Kandidaten unter Verwendung des Algorithmus in Abschnitt 5.7. Die Priorität des lokalen Kandidaten hängt von seinem Typ ab. Wenn er nicht Peer-reflexiv ist, ist er gleich der für diesen Kandidaten im SDP signalisierten Priorität. Wenn er Peer-reflexiv ist, ist er gleich dem PRIORITY-Attribut, das der Agent in die gerade abgeschlossene Binding-Anfrage gesetzt hat. Die Priorität des entfernten Kandidaten wird aus dem SDP des Peers entnommen. Wenn der Kandidat dort nicht erscheint, muss die Prüfung eine getriggerte Prüfung an einen neuen entfernten Kandidaten gewesen sein. In diesem Fall wird die Priorität als Wert des PRIORITY-Attributs in der Binding-Anfrage genommen, die die gerade abgeschlossene Prüfung ausgelöst hat. Das Paar wird dann zur VALID LIST hinzugefügt.

7.1.3.2.3. Updating Pair States (Aktualisierung von Paar-Zuständen)

Der Agent setzt den Zustand des Paares, das die Prüfung generiert hat, auf Succeeded. Beachten Sie, dass das Paar, das die Prüfung generiert hat, sich von dem gültigen Paar unterscheiden kann, das in Abschnitt 7.1.3.2.2 als Folge der Antwort konstruiert wurde. Der Erfolg dieser Prüfung kann auch dazu führen, dass sich der Zustand anderer Prüfungen ändert. Der Agent MUST die folgenden zwei Schritte ausführen:

1. Der Agent ändert die Zustände für alle anderen Frozen Paare für denselben Medienstrom und dieselbe Foundation auf Waiting. Typischerweise, aber nicht immer, haben diese anderen Paare unterschiedliche Komponenten-IDs.

2. Wenn es ein Paar in der gültigen Liste für jede Komponente dieses Medienstroms gibt (wobei dies die tatsächliche Anzahl der verwendeten Komponenten ist, in Fällen, in denen die Anzahl der im SDP signalisierten Komponenten vom Anbieter zum Antwortenden abweicht), kann der Erfolg dieser Prüfung Prüfungen für andere Medienströme auftauen. Beachten Sie, dass dieser Schritt nicht nur befolgt wird, wenn die betrachtete gültige Liste zum ersten Mal ein Paar für jede Komponente hat, sondern jedes Mal, wenn eine Prüfung erfolgreich ist und ein weiteres Paar zu dieser gültigen Liste hinzufügt. Der Agent untersucht die Checkliste für jeden anderen Medienstrom der Reihe nach:

   • Wenn die Checkliste aktiv ist, ändert der Agent den Zustand aller Frozen Paare in dieser Checkliste, deren Foundation mit einem Paar in der betrachteten gültigen Liste übereinstimmt, auf Waiting.

   • Wenn die Checkliste eingefroren ist und es mindestens ein Paar in der Checkliste gibt, dessen Foundation mit einem Paar in der betrachteten gültigen Liste übereinstimmt, wird der Zustand aller Paare in der Checkliste, deren Foundation mit einem Paar in der betrachteten gültigen Liste übereinstimmt, auf Waiting gesetzt. Dies führt dazu, dass die Checkliste aktiv wird und gewöhnliche Prüfungen für sie beginnen, wie in Abschnitt 5.8 beschrieben.

   • Wenn die Checkliste eingefroren ist und es keine Paare in der Checkliste gibt, deren Foundation mit einem Paar in der betrachteten gültigen Liste übereinstimmt,

     • gruppiert der Agent alle Paare mit derselben Foundation zusammen und

     • setzt für jede Gruppe den Zustand des Paares mit der niedrigsten Komponenten-ID auf Waiting. Wenn es mehr als ein solches Paar gibt, wird dasjenige mit der höchsten Priorität verwendet.

7.1.3.2.4. Updating the Nominated Flag (Aktualisierung des Nominated-Flags)

Wenn der Agent ein kontrollierender Agent war und ein USE-CANDIDATE-Attribut in die Binding-Anfrage aufgenommen hatte, wird das Nominated-Flag des aus dieser Prüfung generierten gültigen Paares auf true gesetzt. Dieses Flag zeigt an, dass dieses gültige Paar für Medien verwendet werden sollte, wenn es das mit der höchsten Priorität unter denen ist, deren Nominated-Flag gesetzt ist. Dies kann die ICE-Verarbeitung für diesen Medienstrom oder alle Medienströme abschließen; siehe Abschnitt 8.

Wenn der Agent der kontrollierte Agent ist, kann die Antwort das Ergebnis einer getriggerten Prüfung sein, die als Reaktion auf eine Anfrage gesendet wurde, die selbst das USE-CANDIDATE-Attribut hatte. Dieser Fall wird in Abschnitt 7.2.1.5 beschrieben und kann nun dazu führen, dass das Nominated-Flag für das aus der ursprünglichen Anfrage gelernte Paar gesetzt wird.

7.1.3.3. Check List and Timer State Updates (Checklisten- und Timer-Zustandsaktualisierungen)

Unabhängig davon, ob die Prüfung erfolgreich war oder fehlgeschlagen ist, kann der Abschluss der Transaktion eine Aktualisierung der Checklisten- und Timer-Zustände erfordern.

Wenn alle Paare in der Checkliste jetzt entweder im Failed- oder Succeeded-Zustand sind:

• Wenn es kein Paar in der gültigen Liste für jede Komponente des Medienstroms gibt, wird der Zustand der Checkliste auf Failed gesetzt.

• Für jede eingefrorene Checkliste

  • gruppiert der Agent alle Paare mit derselben Foundation zusammen und

  • setzt für jede Gruppe den Zustand des Paares mit der niedrigsten Komponenten-ID auf Waiting. Wenn es mehr als ein solches Paar gibt, wird dasjenige mit der höchsten Priorität verwendet.

Wenn keines der Paare in der Checkliste im Waiting- oder Frozen-Zustand ist, wird die Checkliste nicht mehr als aktiv betrachtet und zählt nicht mehr zum Wert von N bei der Berechnung von Timern für gewöhnliche Prüfungen, wie in Abschnitt 5.8 beschrieben.

7.2. STUN Server Procedures (STUN-Server-Verfahren)

Ein Agent MUST bereit sein, eine Binding-Anfrage auf der Basis jedes Kandidaten zu empfangen, den er in sein jüngstes Angebot oder seine jüngste Antwort aufgenommen hat. Diese Anforderung gilt auch dann, wenn der Peer eine Lite-Implementierung ist.

Der Agent MUST eine Kurzzeit-Anmeldeinformation verwenden, um die Anfrage zu authentifizieren und eine Nachrichtenintegritätsprüfung durchzuführen. Der Agent MUST den Benutzernamen als gültig betrachten, wenn er aus zwei Werten besteht, die durch einen Doppelpunkt getrennt sind, wobei der erste Wert gleich dem Benutzernamenfragment ist, das vom Agenten in einem Angebot oder einer Antwort für eine laufende Sitzung generiert wurde. Es ist möglich (und tatsächlich sehr wahrscheinlich), dass ein Anbieter eine Binding-Anfrage erhält, bevor er die Antwort von seinem Peer erhält. Wenn dies geschieht, MUST der Agent sofort eine Antwort generieren (einschließlich der Berechnung der gemappten Adresse wie in Abschnitt 7.2.1.2 beschrieben). Der Agent verfügt zu diesem Zeitpunkt über ausreichende Informationen, um die Antwort zu generieren; das Passwort vom Peer ist nicht erforderlich. Sobald die Antwort empfangen wurde, MUST er mit den verbleibenden erforderlichen Schritten fortfahren, nämlich 7.2.1.3, 7.2.1.4 und 7.2.1.5 für vollständige Implementierungen. In Fällen, in denen mehrere STUN-Anfragen vor der Antwort empfangen werden, kann dies dazu führen, dass mehrere Paare in die Warteschlange für getriggerte Prüfungen eingereiht werden.

Ein Agent MUST NOT den ALTERNATE-SERVER-Mechanismus verwenden und MUST NOT die Rückwärtskompatibilitätsmechanismen zu RFC 3489 unterstützen. Er MUST den FINGERPRINT-Mechanismus verwenden.

Wenn der Agent Diffserv Codepoint-Markierungen [RFC2475] in seinen Medienpaketen verwendet, SHOULD er dieselben Markierungen auf seine Antworten auf Binding-Anfragen anwenden. Dasselbe würde für alle Layer-2-Markierungen gelten, die der Endpunkt möglicherweise auf Medienpakete anwendet.

7.2.1. Additional Procedures for Full Implementations (Zusätzliche Verfahren für vollständige Implementierungen)

Dieser Unterabschnitt definiert die zusätzlichen Serververfahren, die für vollständige Implementierungen gelten.

7.2.1.1. Detecting and Repairing Role Conflicts (Erkennung und Reparatur von Rollenkonflikten)

Normalerweise führen die Regeln für die Auswahl einer Rolle in Abschnitt 5.2 dazu, dass jeder Agent eine andere Rolle auswählt -- eine kontrollierende und eine kontrollierte. In ungewöhnlichen Anrufabläufen, die typischerweise eine Anrufsteuerung durch Dritte verwenden, ist es jedoch möglich, dass beide Agenten dieselbe Rolle auswählen. Dieser Abschnitt beschreibt Verfahren zur Überprüfung auf diesen Fall und zu dessen Reparatur.

Ein Agent MUST die Binding-Anfrage entweder auf das ICE-CONTROLLING- oder das ICE-CONTROLLED-Attribut untersuchen. Er MUST diesen Verfahren folgen:

• Wenn weder ICE-CONTROLLING noch ICE-CONTROLLED in der Anfrage vorhanden ist, hat der Peer-Agent möglicherweise eine frühere Version dieser Spezifikation implementiert. Es kann ein Konflikt vorliegen, aber er kann nicht erkannt werden.

• Wenn der Agent in der kontrollierenden Rolle ist und das ICE-CONTROLLING-Attribut in der Anfrage vorhanden ist:

  • Wenn der Tie-Breaker des Agenten größer oder gleich dem Inhalt des ICE-CONTROLLING-Attributs ist, generiert der Agent eine Binding-Fehlerantwort und enthält ein ERROR-CODE-Attribut mit einem Wert von 487 (Role Conflict), behält aber seine Rolle bei.

  • Wenn der Tie-Breaker des Agenten kleiner als der Inhalt des ICE-CONTROLLING-Attributs ist, wechselt der Agent zur kontrollierten Rolle.

• Wenn der Agent in der kontrollierten Rolle ist und das ICE-CONTROLLED-Attribut in der Anfrage vorhanden ist:

  • Wenn der Tie-Breaker des Agenten größer oder gleich dem Inhalt des ICE-CONTROLLED-Attributs ist, wechselt der Agent zur kontrollierenden Rolle.

  • Wenn der Tie-Breaker des Agenten kleiner als der Inhalt des ICE-CONTROLLED-Attributs ist, generiert der Agent eine Binding-Fehlerantwort und enthält ein ERROR-CODE-Attribut mit einem Wert von 487 (Role Conflict), behält aber seine Rolle bei.

• Wenn der Agent in der kontrollierten Rolle ist und das ICE-CONTROLLING-Attribut in der Anfrage vorhanden war, oder der Agent in der kontrollierenden Rolle war und das ICE-CONTROLLED-Attribut in der Anfrage vorhanden war, liegt kein Konflikt vor.

Ein Rollenwechsel erfordert, dass ein Agent die Paarprioritäten neu berechnet (Abschnitt 5.7.2), da diese Prioritäten eine Funktion der kontrollierenden und kontrollierten Rollen sind. Der Rollenwechsel wirkt sich auch darauf aus, ob der Agent für die Auswahl nominierter Paare und die Generierung aktualisierter Angebote nach Abschluss von ICE verantwortlich ist.

Die verbleibenden Abschnitte in Abschnitt 7.2.1 werden befolgt, wenn der Server eine erfolgreiche Antwort auf die Binding-Anfrage generiert hat, auch wenn der Agent die Rolle gewechselt hat.

7.2.1.2. Computing Mapped Address (Berechnung der gemappten Adresse)

Für Anfragen, die auf einem weitergeleiteten Kandidaten empfangen werden, ist die Quelltransportadresse, die für die STUN-Verarbeitung verwendet wird (nämlich Generierung des XOR-MAPPED-ADDRESS-Attributs), die Transportadresse, wie sie vom TURN-Server gesehen wird. Diese Quelltransportadresse wird im XOR-PEER-ADDRESS-Attribut einer Data Indication-Nachricht vorhanden sein, wenn die Binding-Anfrage über eine Data Indication zugestellt wurde. Wenn die Binding-Anfrage über eine ChannelData-Nachricht zugestellt wurde, ist die Quelltransportadresse diejenige, die an den Kanal gebunden war.

7.2.1.3. Learning Peer Reflexive Candidates (Lernen von Peer-reflexiven Kandidaten)

Wenn die Quelltransportadresse der Anfrage mit keinen bestehenden entfernten Kandidaten übereinstimmt, stellt sie einen neuen Peer-reflexiven entfernten Kandidaten dar. Dieser Kandidat wird wie folgt konstruiert:

• Die Priorität des Kandidaten wird auf das PRIORITY-Attribut aus der Anfrage gesetzt.
• Der Typ des Kandidaten wird auf Peer-reflexiv gesetzt.
• Die Foundation des Kandidaten wird auf einen beliebigen Wert gesetzt, der sich von der Foundation für alle anderen entfernten Kandidaten unterscheidet. Wenn nachfolgende Angebots-/Antwortaustausche diesen Peer-reflexiven Kandidaten im SDP enthalten, wird dies die tatsächliche Foundation für den Kandidaten signalisieren.
• Die Komponenten-ID dieses Kandidaten wird auf die Komponenten-ID für den lokalen Kandidaten gesetzt, an den die Anfrage gesendet wurde.

Dieser Kandidat wird zur Liste der entfernten Kandidaten hinzugefügt. Der Agent paart diesen Kandidaten jedoch nicht mit lokalen Kandidaten.

7.2.1.4. Triggered Checks (Getriggerte Prüfungen)

Als nächstes konstruiert der Agent ein Paar, dessen lokaler Kandidat gleich der Transportadresse ist, auf der die STUN-Anfrage empfangen wurde, und einen entfernten Kandidaten gleich der Quelltransportadresse, von der die Anfrage kam (die der gerade gelernte Peer-reflexive entfernte Kandidat sein kann). Der lokale Kandidat wird entweder ein Host-Kandidat (für Fälle, in denen die Anfrage nicht über ein Relay empfangen wurde) oder ein weitergeleiteter Kandidat (für Fälle, in denen sie über ein Relay empfangen wird) sein. Der lokale Kandidat kann niemals ein Server-reflexiver Kandidat sein. Da beide Kandidaten dem Agenten bekannt sind, kann er ihre Prioritäten erhalten und die Kandidatenpaarpriorität berechnen. Dieses Paar wird dann in der Checkliste nachgeschlagen. Es kann eines von mehreren Ergebnissen geben:

• Wenn das Paar bereits auf der Checkliste steht:

  • Wenn der Zustand dieses Paares Waiting oder Frozen ist, wird eine Prüfung für dieses Paar in die Warteschlange für getriggerte Prüfungen eingereiht, falls noch nicht vorhanden.

  • Wenn der Zustand dieses Paares In-Progress ist, bricht der Agent die laufende Transaktion ab. Abbruch bedeutet, dass der Agent die Anfrage nicht erneut sendet, das Fehlen einer Antwort nicht als Fehler behandelt, sondern die Dauer des Transaktions-Timeouts auf eine Antwort wartet. Darüber hinaus MUST der Agent eine neue Konnektivitätsprüfung für dieses Paar erstellen (die eine neue STUN-Binding-Anfrage-Transaktion darstellt), indem er das Paar in die Warteschlange für getriggerte Prüfungen einreiht. Der Zustand des Paares wird dann auf Waiting geändert.

  • Wenn der Zustand des Paares Failed ist, wird er auf Waiting geändert, und der Agent MUST eine neue Konnektivitätsprüfung für dieses Paar erstellen (die eine neue STUN-Binding-Anfrage-Transaktion darstellt), indem er das Paar in die Warteschlange für getriggerte Prüfungen einreiht.

  • Wenn der Zustand dieses Paares Succeeded ist, wird nichts weiter getan.

  Diese Schritte werden durchgeführt, um den schnellen Abschluss von ICE zu erleichtern, wenn beide Agenten hinter NAT sind.

• Wenn das Paar nicht bereits auf der Checkliste steht:

  • Das Paar wird basierend auf seiner Priorität in die Checkliste eingefügt.

  • Sein Zustand wird auf Waiting gesetzt.

  • Das Paar wird in die Warteschlange für getriggerte Prüfungen eingereiht.

Wenn eine getriggerte Prüfung gesendet werden soll, wird sie wie in Abschnitt 7.1.2 beschrieben konstruiert und verarbeitet. Diese Verfahren erfordern, dass der Agent die Transportadresse, das Benutzernamenfragment und das Passwort für den Peer kennt. Das Benutzernamenfragment für den entfernten Kandidaten ist gleich dem Teil nach dem Doppelpunkt des USERNAME in der Binding-Anfrage, die gerade empfangen wurde. Unter Verwendung dieses Benutzernamenfragments kann der Agent die von seinem Peer empfangenen SDP-Nachrichten überprüfen (es kann mehr als eine geben in Fällen von Gabelung) und dieses Benutzernamenfragment finden. Das entsprechende Passwort wird dann ausgewählt.

7.2.1.5. Updating the Nominated Flag (Aktualisierung des Nominated-Flags)

Wenn die vom Agenten empfangene Binding-Anfrage das USE-CANDIDATE-Attribut gesetzt hatte und der Agent in der kontrollierten Rolle ist, betrachtet der Agent den Zustand des in Abschnitt 7.2.1.4 berechneten Paares:

• Wenn der Zustand dieses Paares Succeeded ist, bedeutet dies, dass die durch dieses Paar generierte Prüfung eine erfolgreiche Antwort produziert hat. Dies hätte dazu geführt, dass der Agent ein gültiges Paar konstruiert hat, als diese Erfolgsantwort empfangen wurde (siehe Abschnitt 7.1.3.2.2). Der Agent setzt nun das Nominated-Flag im gültigen Paar auf true. Dies kann die ICE-Verarbeitung für diesen Medienstrom beenden; siehe Abschnitt 8.

• Wenn der Zustand dieses Paares In-Progress ist, wenn seine Prüfung ein erfolgreiches Ergebnis produziert, hat das resultierende gültige Paar sein Nominated-Flag gesetzt, wenn die Antwort eintrifft. Dies kann die ICE-Verarbeitung für diesen Medienstrom beenden, wenn sie eintrifft; siehe Abschnitt 8.

7.2.2. Additional Procedures for Lite Implementations (Zusätzliche Verfahren für Lite-Implementierungen)

Wenn die gerade empfangene Prüfung ein USE-CANDIDATE-Attribut enthielt, konstruiert der Agent ein Kandidatenpaar, dessen lokaler Kandidat gleich der Transportadresse ist, auf der die Anfrage empfangen wurde, und dessen entfernter Kandidat gleich der Quelltransportadresse der empfangenen Anfrage ist. Diesem Kandidatenpaar wird eine beliebige Priorität zugewiesen, und es wird in eine Liste gültiger Kandidaten platziert, die Valid List genannt wird. Der Agent setzt das Nominated-Flag für dieses Paar auf true. Die ICE-Verarbeitung gilt als abgeschlossen für einen Medienstrom, wenn die Valid List ein Kandidatenpaar für jede Komponente enthält.