4. Sending the Initial Offer (Senden des initialen Angebots)

Um das initiale Angebot in einem Offer/Answer-Austausch zu senden, muss ein Agent (1) Kandidaten sammeln, (2) diese priorisieren, (3) redundante Kandidaten eliminieren, (4) Standardkandidaten auswählen und dann (5) das SDP-Angebot formulieren und senden. Alle bis auf den letzten dieser fünf Schritte unterscheiden sich für vollständige und Lite-Implementierungen.

4.1. Full Implementation Requirements (Anforderungen an die vollständige Implementierung)

4.1.1. Gathering Candidates (Sammeln von Kandidaten)

Ein Agent sammelt Kandidaten, wenn er glaubt, dass eine Kommunikation unmittelbar bevorsteht. Ein Offerer kann dies basierend auf einem Hinweis der Benutzeroberfläche oder basierend auf einer expliziten Anforderung zur Initiierung einer Sitzung tun. Jeder Kandidat ist eine Transportadresse. Er hat auch einen Typ und eine Basis. Diese Spezifikation definiert und sammelt vier Typen: Host-Kandidaten, Server-Reflexive Kandidaten, Peer-Reflexive Kandidaten und Relay-Kandidaten. Die Server-Reflexiven Kandidaten werden unter Verwendung von STUN oder TURN gesammelt, und Relay-Kandidaten werden über TURN erhalten. Peer-Reflexive Kandidaten werden in späteren Phasen von ICE als Folge von Konnektivitätsprüfungen erhalten. Die Basis eines Kandidaten ist der Kandidat, von dem ein Agent senden muss, wenn er diesen Kandidaten verwendet.

4.1.1.1. Host Candidates (Host-Kandidaten)

Der erste Schritt besteht darin, Host-Kandidaten zu sammeln. Host-Kandidaten werden durch Binden an Ports (typischerweise ephemere) auf einer IP-Adresse erhalten, die an eine Schnittstelle (physisch oder virtuell, einschließlich VPN-Schnittstellen) auf dem Host angeschlossen ist.

Für jeden UDP-Medienstrom, den der Agent verwenden möchte, SHOULD (sollte) der Agent einen Kandidaten für jede Komponente des Medienstroms auf jeder IP-Adresse erhalten, die der Host hat. Er erhält jeden Kandidaten durch Binden an einen UDP-Port auf der spezifischen IP-Adresse. Ein Host-Kandidat (und tatsächlich jeder Kandidat) ist immer mit einer bestimmten Komponente verbunden, für die er ein Kandidat ist. Jeder Komponente ist eine ID zugewiesen, die als Komponenten-ID bezeichnet wird. Für RTP-basierte Medienströme hat RTP selbst eine Komponenten-ID von 1 und RTCP eine Komponenten-ID von 2. Wenn ein Agent RTCP verwendet, MUST (muss) er einen Kandidaten dafür erhalten. Wenn ein Agent sowohl RTP als auch RTCP verwendet, würde er mit 2*K Host-Kandidaten enden, wenn ein Agent K IP-Adressen hat.

Die Basis für jeden Host-Kandidaten wird auf den Kandidaten selbst gesetzt.

4.1.1.2. Server Reflexive and Relayed Candidates (Server-Reflexive und Relay-Kandidaten)

Agenten SHOULD (sollten) Relay-Kandidaten erhalten und SHOULD (sollten) Server-Reflexive Kandidaten erhalten. Diese Anforderungen haben die Stärke SHOULD, um Variationen bei Anbietern zu ermöglichen. Die Verwendung von STUN- und TURN-Servern kann in geschlossenen Netzwerken unnötig sein, in denen Agenten niemals mit dem öffentlichen Internet oder mit Endpunkten außerhalb des geschlossenen Netzwerks verbunden sind. In solchen Fällen würde eine vollständige Implementierung für Agenten verwendet, die Dual-Stack oder Multihomed sind, um einen Host-Kandidaten auszuwählen. Die Verwendung von TURN-Servern ist teuer, und wenn ICE verwendet wird, werden sie nur genutzt, wenn sich beide Endpunkte hinter NATs befinden, die adress- und portabhängiges Mapping durchführen. Folglich könnten einige Bereitstellungen diesen Anwendungsfall als marginal betrachten und sich dafür entscheiden, keine TURN-Server zu verwenden. Wenn ein Agent keine Server-Reflexiven oder Relay-Kandidaten sammelt, ist es RECOMMENDED (empfohlen), dass die Funktionalität implementiert und nur durch Konfiguration deaktiviert wird, damit sie durch Konfiguration wieder aktiviert werden kann, wenn sich die Bedingungen in Zukunft ändern.

Wenn ein Agent sowohl Relay- als auch Server-Reflexive Kandidaten sammelt, verwendet er einen TURN-Server. Wenn er nur Server-Reflexive Kandidaten sammelt, verwendet er einen STUN-Server.

Der Agent paart als nächstes jeden Host-Kandidaten mit dem STUN- oder TURN-Server, mit dem er konfiguriert ist oder den er auf irgendeine Weise entdeckt hat. Wenn ein STUN- oder TURN-Server konfiguriert ist, ist es RECOMMENDED (empfohlen), dass ein Domänenname konfiguriert wird und die DNS-Verfahren in [RFC5389] (unter Verwendung von SRV-Einträgen mit dem Dienst "stun") verwendet werden, um den STUN-Server zu entdecken, und die DNS-Verfahren in [RFC5766] (unter Verwendung von SRV-Einträgen mit dem Dienst "turn") verwendet werden, um den TURN-Server zu entdecken.

Diese Spezifikation berücksichtigt nur die Verwendung eines einzelnen STUN- oder TURN-Servers. Wenn es mehrere Auswahlmöglichkeiten für diesen einzelnen STUN- oder TURN-Server gibt (wenn sie beispielsweise durch DNS-Einträge gelernt werden und mehrere Ergebnisse zurückgegeben werden), SHOULD (sollte) ein Agent einen einzelnen STUN- oder TURN-Server (basierend auf seiner IP-Adresse) für alle Kandidaten für eine bestimmte Sitzung verwenden. Dies verbessert die Leistung von ICE. Das Ergebnis ist ein Satz von Paaren von Host-Kandidaten mit STUN- oder TURN-Servern. Der Agent wählt dann ein Paar aus und sendet eine Binding- oder Allocate-Anforderung von diesem Host-Kandidaten an den Server. Binding-Anforderungen an einen STUN-Server werden nicht authentifiziert, und jedes ALTERNATE-SERVER-Attribut in einer Antwort wird ignoriert. Agenten MUST (müssen) den in [RFC5389] definierten Abwärtskompatibilitätsmodus für die Binding-Anforderung unterstützen. Allocate-Anforderungen SHOULD (sollten) unter Verwendung eines langfristigen Berechtigungsnachweises authentifiziert werden, den der Client auf andere Weise erhalten hat.

Alle Ta Millisekunden danach kann der Agent eine weitere neue STUN- oder TURN-Transaktion generieren. Diese Transaktion kann entweder eine Wiederholung einer vorherigen Transaktion sein, die mit einem behebbaren Fehler (wie z. B. Authentifizierungsfehler) fehlgeschlagen ist, oder eine Transaktion für einen neuen Host-Kandidaten und ein STUN- oder TURN-Serverpaar. Der Agent SHOULD NOT (sollte nicht) Transaktionen häufiger als eine alle Ta Millisekunden generieren. Siehe Abschnitt 16 für Anleitungen zum Festlegen von Ta und dem STUN-Neuübertragungstimer RTO.

Der Agent empfängt eine Binding- oder Allocate-Antwort. Eine erfolgreiche Allocate-Antwort liefert dem Agenten einen Server-Reflexiven Kandidaten (erhalten von der abgebildeten Adresse) und einen Relay-Kandidaten im XOR-RELAYED-ADDRESS-Attribut. Wenn die Allocate-Anforderung abgelehnt wird, weil dem Server die Ressourcen fehlen, um sie zu erfüllen, SHOULD (sollte) der Agent stattdessen eine Binding-Anforderung senden, um einen Server-Reflexiven Kandidaten zu erhalten. Eine Binding-Antwort liefert dem Agenten nur einen Server-Reflexiven Kandidaten (ebenfalls von der abgebildeten Adresse erhalten). Die Basis des Server-Reflexiven Kandidaten ist der Host-Kandidat, von dem die Allocate- oder Binding-Anforderung gesendet wurde. Die Basis eines Relay-Kandidaten ist dieser Kandidat selbst. Wenn ein Relay-Kandidat identisch mit einem Host-Kandidaten ist (was in seltenen Fällen vorkommen kann), MUST (muss) der Relay-Kandidat verworfen werden.

4.1.1.3. Computing Foundations (Berechnung von Foundations)

Schließlich weist der Agent jedem Kandidaten eine Foundation zu. Die Foundation ist ein Bezeichner, der innerhalb einer Sitzung gültig ist. Zwei Kandidaten MUST (müssen) dieselbe Foundation-ID haben, wenn alle folgenden Bedingungen erfüllt sind:

• sie sind vom gleichen Typ (Host, Relay, Server-Reflexiv oder Peer-Reflexiv).
• ihre Basen haben dieselbe IP-Adresse (die Ports können unterschiedlich sein).
• für Reflexive und Relay-Kandidaten haben die STUN- oder TURN-Server, die verwendet wurden, um sie zu erhalten, dieselbe IP-Adresse.
• sie wurden unter Verwendung desselben Transportprotokolls (TCP, UDP usw.) erhalten.

Ebenso MUST (müssen) zwei Kandidaten unterschiedliche Foundations haben, wenn ihre Typen unterschiedlich sind, ihre Basen unterschiedliche IP-Adressen haben, die STUN- oder TURN-Server, die verwendet wurden, um sie zu erhalten, unterschiedliche IP-Adressen haben oder ihre Transportprotokolle unterschiedlich sind.

4.1.1.4. Keeping Candidates Alive (Kandidaten am Leben erhalten)

Sobald Server-Reflexive und Relay-Kandidaten zugewiesen sind, MUST (müssen) sie am Leben erhalten werden, bis die ICE-Verarbeitung abgeschlossen ist, wie in Abschnitt 8.3 beschrieben. Für Server-Reflexive Kandidaten, die durch eine Binding-Anforderung gelernt wurden, MUST (müssen) die Bindungen durch zusätzliche Binding-Anforderungen an den Server am Leben erhalten werden. Aktualisierungen für Zuweisungen erfolgen unter Verwendung der Refresh-Transaktion, wie in [RFC5766] beschrieben. Die Refresh-Anforderungen aktualisieren auch den Server-Reflexiven Kandidaten.

4.1.2. Prioritizing Candidates (Priorisierung von Kandidaten)

Der Priorisierungsprozess führt zur Zuweisung einer Priorität an jeden Kandidaten. Jeder Kandidat für einen Medienstrom MUST (muss) eine eindeutige Priorität haben, die eine positive ganze Zahl zwischen 1 und (2**31 - 1) sein MUST (muss). Diese Priorität wird von ICE verwendet, um die Reihenfolge der Konnektivitätsprüfungen und die relative Präferenz für Kandidaten zu bestimmen.

Ein Agent SHOULD (sollte) diese Priorität unter Verwendung der Formel in Abschnitt 4.1.2.1 berechnen und seine Parameter unter Verwendung der Richtlinien in Abschnitt 4.1.2.2 auswählen. Wenn ein Agent eine andere Formel wählt, dauert es länger, bis ICE konvergiert, da beide Agenten bei ihren Prüfungen nicht koordiniert sind.

4.1.2.1. Recommended Formula (Empfohlene Formel)

Bei Verwendung der Formel berechnet ein Agent die Priorität, indem er eine Präferenz für jeden Kandidatentyp (Server-Reflexiv, Peer-Reflexiv, Relay und Host) bestimmt und, wenn der Agent Multihomed ist, eine Präferenz für seine IP-Adressen wählt. Diese beiden Präferenzen werden dann kombiniert, um die Priorität für einen Kandidaten zu berechnen. Diese Priorität wird unter Verwendung der folgenden Formel berechnet:

priority = (2^24)*(type preference) +
           (2^8)*(local preference) +
           (2^0)*(256 - component ID)

Die Typpräferenz (type preference) MUST (muss) eine ganze Zahl von 0 bis 126 einschließlich sein und stellt die Präferenz für den Typ des Kandidaten dar (wobei die Typen lokal, Server-Reflexiv, Peer-Reflexiv und Relay sind). 126 ist die höchste Präferenz und 0 die niedrigste. Das Setzen des Wertes auf 0 bedeutet, dass Kandidaten dieses Typs nur als letztes Mittel verwendet werden. Die Typpräferenz MUST (muss) für alle Kandidaten desselben Typs identisch sein und MUST (muss) für Kandidaten unterschiedlicher Typen unterschiedlich sein. Die Typpräferenz für Peer-Reflexive Kandidaten MUST (muss) höher sein als die von Server-Reflexiven Kandidaten. Beachten Sie, dass Kandidaten, die basierend auf den Verfahren von Abschnitt 4.1.1 gesammelt wurden, niemals Peer-Reflexive Kandidaten sind; Kandidaten dieses Typs werden aus den von ICE durchgeführten Konnektivitätsprüfungen gelernt.

Die lokale Präferenz (local preference) MUST (muss) eine ganze Zahl von 0 bis 65535 einschließlich sein. Sie stellt eine Präferenz für die jeweilige IP-Adresse dar, von der der Kandidat erhalten wurde, in Fällen, in denen ein Agent Multihomed ist. 65535 stellt die höchste Präferenz dar und Null die niedrigste. Wenn es nur eine einzige IP-Adresse gibt, SHOULD (sollte) dieser Wert auf 65535 gesetzt werden. Allgemeiner gesagt, wenn es mehrere Kandidaten für eine bestimmte Komponente für einen bestimmten Medienstrom gibt, die denselben Typ haben, MUST (muss) die lokale Präferenz für jeden eindeutig sein. In dieser Spezifikation geschieht dies nur bei Multihomed-Hosts. Wenn ein Host Multihomed ist, weil er Dual-Stack ist, SHOULD (sollte) die lokale Präferenz gleich dem Prioritätswert für IP-Adressen gesetzt werden, der in RFC 3484 [RFC3484] beschrieben ist.

Die Komponenten-ID ist die Komponenten-ID für den Kandidaten und MUST (muss) zwischen 1 und 256 einschließlich liegen.

4.1.2.2. Guidelines for Choosing Type and Local Preferences (Richtlinien zur Auswahl von Typ und lokalen Präferenzen)

Ein Kriterium für die Auswahl der Typ- und lokalen Präferenzwerte ist die Verwendung eines Medienvermittlers, wie z. B. eines TURN-Servers, VPN-Servers oder NAT. Bei einem Medienvermittler durchläuft das Medium, wenn es an diesen Kandidaten gesendet wird, zuerst den Medienvermittler, bevor es empfangen wird. Relay-Kandidaten sind eine Art von Kandidat, der einen Medienvermittler beinhaltet. Ein weiterer sind Host-Kandidaten, die von einer VPN-Schnittstelle erhalten wurden. Wenn Medien durch einen Medienvermittler geleitet werden, kann dies die Latenz zwischen Übertragung und Empfang erhöhen. Es kann die Paketverluste erhöhen, aufgrund der zusätzlichen Router-Hops, die möglicherweise genommen werden. Es kann die Kosten für die Bereitstellung des Dienstes erhöhen, da Medien in einen von einem Anbieter betriebenen Medienvermittler hinein- und wieder herausgeleitet werden. Wenn diese Bedenken wichtig sind, SHOULD (sollte) die Typpräferenz für Relay-Kandidaten niedriger sein als für Host-Kandidaten. Die empfohlenen Werte (RECOMMENDED) sind 126 für Host-Kandidaten, 100 für Server-Reflexive Kandidaten, 110 für Peer-Reflexive Kandidaten und 0 für Relay-Kandidaten. Darüber hinaus, wenn ein Agent Multihomed ist und mehrere IP-Adressen hat, SHOULD (sollte) die lokale Präferenz für Host-Kandidaten von einer VPN-Schnittstelle eine Priorität von 0 haben.

Ein weiteres Kriterium für die Auswahl von Präferenzen ist die IP-Adressfamilie. ICE funktioniert sowohl mit IPv4 als auch mit IPv6. Es bietet daher einen Übergangsmechanismus, der es Dual-Stack-Hosts ermöglicht, Konnektivität über IPv6 zu bevorzugen, aber auf IPv4 zurückzugreifen, falls die v6-Netzwerke getrennt sind (z. B. aufgrund eines Fehlers in einem 6to4-Relay) [RFC3056]. Es kann auch bei Hosts helfen, die sowohl eine native IPv6-Adresse als auch eine 6to4-Adresse haben. In einem solchen Fall könnten den v6-Adressen höhere lokale Präferenzen zugewiesen werden, gefolgt von den 6to4-Adressen, gefolgt von den v4-Adressen. Dies ermöglicht es einem Standort, native v6-Adressen sofort zu erhalten und zu verwenden, aber dennoch auf 6to4-Adressen zurückzugreifen, wenn mit Agenten an anderen Standorten kommuniziert wird, die noch keine native v6-Konnektivität haben.

Ein weiteres Kriterium für die Auswahl von Präferenzen ist die Sicherheit. Wenn ein Benutzer ein Telearbeiter ist und daher mit einem Unternehmensnetzwerk und einem lokalen Heimnetzwerk verbunden ist, zieht der Benutzer es möglicherweise vor, dass sein Sprachverkehr über das VPN geleitet wird, um ihn im Unternehmensnetzwerk zu halten, wenn er innerhalb des Unternehmens kommuniziert, aber das lokale Netzwerk zu verwenden, wenn er mit Benutzern außerhalb des Unternehmens kommuniziert. In einem solchen Fall hätte eine VPN-Adresse eine höhere lokale Präferenz als jede andere Adresse.

Ein weiteres Kriterium für die Auswahl von Präferenzen ist das topologische Bewusstsein. Dies ist am nützlichsten für Kandidaten, die Vermittler verwenden. In diesen Fällen, wenn ein Agent vorkonfiguriertes oder dynamisch entdecktes Wissen über die topologische Nähe der Vermittler zu sich selbst hat, kann er dies verwenden, um Kandidaten, die von näheren Vermittlern erhalten wurden, höhere lokale Präferenzen zuzuweisen.

4.1.3. Eliminating Redundant Candidates (Eliminierung redundanter Kandidaten)

Als nächstes eliminiert der Agent redundante Kandidaten. Ein Kandidat ist redundant, wenn seine Transportadresse einem anderen Kandidaten gleicht und seine Basis der Basis dieses anderen Kandidaten gleicht. Beachten Sie, dass zwei Kandidaten dieselbe Transportadresse haben können, aber unterschiedliche Basen, und diese würden nicht als redundant betrachtet. Häufig sind ein Server-Reflexiver Kandidat und ein Host-Kandidat redundant, wenn sich der Agent nicht hinter einem NAT befindet. Der Agent SHOULD (sollte) den redundanten Kandidaten mit der niedrigeren Priorität eliminieren.

4.1.4. Choosing Default Candidates (Auswahl von Standardkandidaten)

Ein Kandidat gilt als Standard, wenn er das Ziel von Medien von einem Nicht-ICE-Peer wäre; dieses Ziel wird als STANDARDZIEL (DEFAULT DESTINATION) bezeichnet. Wenn die Standardkandidaten vom ICE-Algorithmus bei der Kommunikation mit einem ICE-fähigen Peer nicht ausgewählt werden, ist ein aktualisiertes Offer/Answer erforderlich, nachdem die ICE-Verarbeitung abgeschlossen ist, um das SDP zu "reparieren", damit das Standardziel für Medien mit den von ICE ausgewählten Kandidaten übereinstimmt. Wenn ICE zufällig die Standardkandidaten auswählt, ist kein aktualisiertes Offer/Answer erforderlich.

Ein Agent MUST (muss) einen Satz von Kandidaten auswählen, einen für jede Komponente jedes verwendeten Medienstroms, um Standard zu sein. Ein Medienstrom wird verwendet, wenn er keinen Port von Null hat (was in RFC 3264 verwendet wird, um einen Medienstrom abzulehnen). Folglich wird ein Medienstrom auch dann verwendet, wenn er als a=inactive [RFC4566] markiert ist oder einen Bandbreitenwert von Null hat.

Es ist RECOMMENDED (empfohlen), dass Standardkandidaten basierend auf der Wahrscheinlichkeit ausgewählt werden, dass diese Kandidaten mit dem Peer funktionieren, der kontaktiert wird. Es ist RECOMMENDED (empfohlen), dass die Standardkandidaten die Relay-Kandidaten sind (wenn Relay-Kandidaten verfügbar sind), Server-Reflexive Kandidaten (wenn Server-Reflexive Kandidaten verfügbar sind) und schließlich Host-Kandidaten.

4.2. Lite Implementation Requirements (Anforderungen an die Lite-Implementierung)

Lite-Implementierungen nutzen nur Host-Kandidaten. Eine Lite-Implementierung MUST (muss) für jede Komponente jedes Medienstroms null oder einen IPv4-Kandidaten zuweisen. Sie MAY (kann) null oder mehr IPv6-Kandidaten zuweisen, aber nicht mehr als einen pro jeder vom Host genutzten IPv6-Adresse. Da es nicht mehr als einen IPv4-Kandidaten pro Komponente jedes Medienstroms geben kann, MUST (muss) ein Agent, wenn er mehrere IPv4-Adressen hat, eine für die Zuweisung des Kandidaten auswählen. Wenn ein Host Dual-Stack ist, ist es RECOMMENDED (empfohlen), dass er einen IPv4-Kandidaten und eine globale IPv6-Adresse zuweist. Mit der Lite-Implementierung kann ICE nicht verwendet werden, um dynamisch zwischen Kandidaten zu wählen. Daher ist das Einschließen von mehr als einem Kandidaten aus einem bestimmten Bereich NOT RECOMMENDED (nicht empfohlen), da nur eine Konnektivitätsprüfung wirklich bestimmen kann, ob die eine oder die andere Adresse verwendet werden soll.

Jeder Komponente ist eine ID zugewiesen, die als Komponenten-ID bezeichnet wird. Für RTP-basierte Medienströme hat RTP selbst eine Komponenten-ID von 1 und RTCP eine Komponenten-ID von 2. Wenn ein Agent RTCP verwendet, MUST (muss) er Kandidaten dafür erhalten.

Jedem Kandidaten wird eine Foundation zugewiesen. Die Foundation MUST (muss) für zwei Kandidaten, die von unterschiedlichen IP-Adressen zugewiesen wurden, unterschiedlich sein und MUST (muss) ansonsten gleich sein. Eine einfache ganze Zahl, die für jede IP-Adresse inkrementiert wird, reicht aus. Darüber hinaus MUST (muss) jedem Kandidaten eine eindeutige Priorität unter allen Kandidaten für denselben Medienstrom zugewiesen werden. Diese Priorität SHOULD (sollte) gleich sein:

priority = (2^24)*(126) +
           (2^8)*(IP precedence) +
           (2^0)*(256 - component ID)

Wenn ein Host nur v4 ist, SHOULD (sollte) er die IP-Priorität auf 65535 setzen. Wenn ein Host v6 oder Dual-Stack ist, SHOULD (sollte) die IP-Priorität der Prioritätswert für IP-Adressen sein, der in RFC 3484 [RFC3484] beschrieben ist.

Als nächstes wählt ein Agent einen Standardkandidaten für jede Komponente jedes Medienstroms. Wenn ein Host nur IPv4 ist, gäbe es nur einen Kandidaten für jede Komponente jedes Medienstroms, und daher ist dieser Kandidat der Standard. Wenn ein Host IPv6 oder Dual-Stack ist, ist die Auswahl des Standards eine Frage der lokalen Richtlinie. Dieser Standard SHOULD (sollte) so gewählt werden, dass er der Kandidat ist, der am wahrscheinlichsten mit einem Peer verwendet wird. Für IPv6-Only-Hosts wäre dies typischerweise eine global gültige IPv6-Adresse. Für Dual-Stack-Hosts ist die IPv4-Adresse RECOMMENDED (empfohlen).

4.3. Encoding the SDP (Codierung des SDP)

Der Prozess der Codierung des SDP ist zwischen vollständigen und Lite-Implementierungen identisch.

Der Agent fügt für jeden Medienstrom, den er verwenden möchte, eine m-Zeile hinzu. Die Reihenfolge der Medienströme im SDP ist für ICE relevant. ICE führt seine Konnektivitätsprüfungen zuerst für die erste m-Zeile durch, und folglich können Medien für diesen Strom zuerst fließen. Agenten SHOULD (sollten) ihren wichtigsten Medienstrom, falls vorhanden, zuerst im SDP platzieren.

Es wird ein Kandidatenattribut für jeden Kandidaten für einen bestimmten Medienstrom geben. Abschnitt 15 enthält detaillierte Regeln für die Konstruktion dieses Attributs. Das Attribut trägt die IP-Adresse, den Port und das Transportprotokoll für den Kandidaten sowie seine Eigenschaften, die dem Peer signalisiert werden müssen, damit ICE funktioniert: Priorität, Foundation und Komponenten-ID. Das Kandidatenattribut trägt auch Informationen über den Kandidaten, die für Diagnosen und andere Funktionen nützlich sind: seinen Typ und zugehörige Transportadressen.

STUN-Konnektivitätsprüfungen zwischen Agenten werden unter Verwendung des für STUN definierten kurzfristigen Berechtigungsnachweismechanismus [RFC5389] authentifiziert. Dieser Mechanismus beruht auf einem Benutzernamen und einem Passwort, die über einen Protokollmechanismus zwischen dem Client und dem Server ausgetauscht werden. Bei ICE wird der Offer/Answer-Austausch verwendet, um sie auszutauschen. Der Benutzernamensteil dieses Berechtigungsnachweises wird durch Verketten eines Benutzernamenfragments von jedem Agenten, getrennt durch einen Doppelpunkt, gebildet. Jeder Agent stellt auch ein Passwort bereit, das verwendet wird, um die Nachrichtenintegrität für empfangene Anforderungen zu berechnen. Das Benutzernamenfragment und das Passwort werden in den Attributen ice-ufrag bzw. ice-pwd ausgetauscht. Neben der Bereitstellung von Sicherheit bietet der Benutzername eine Disambiguierung und Korrelation von Prüfungen zu Medienströmen. Siehe Anhang B.4 für die Motivation.

Wenn ein Agent eine Lite-Implementierung ist, MUST (muss) er ein "a=ice-lite"-Attribut auf Sitzungsebene in sein SDP aufnehmen. Wenn ein Agent eine vollständige Implementierung ist, MUST NOT (darf er nicht) dieses Attribut enthalten.

Die Standardkandidaten werden als Standardziel für Medien zum SDP hinzugefügt. Für auf RTP basierende Ströme erfolgt dies durch Platzieren der IP-Adresse und des Ports des RTP-Kandidaten in die c- bzw. m-Zeilen. Wenn der Agent RTCP verwendet, MUST (muss) er den RTCP-Kandidaten unter Verwendung des in RFC 3605 [RFC3605] definierten Attributs a=rtcp codieren. Wenn RTCP nicht verwendet wird, MUST (muss) der Agent dies unter Verwendung von b=RS:0 und b=RR:0 signalisieren, wie in RFC 3556 [RFC3556] definiert.

Die Transportadressen, die das Standardziel für Medien bei der Kommunikation mit Nicht-ICE-Peers sind, MUST (müssen) ebenfalls als Kandidaten in einer oder mehreren a=candidate-Zeilen vorhanden sein.

ICE bietet Erweiterbarkeit, indem es einem Angebot oder einer Antwort ermöglicht, eine Reihe von Token zu enthalten, die die von diesem Agenten verwendeten ICE-Erweiterungen identifizieren. Wenn ein Agent eine ICE-Erweiterung unterstützt, MUST (muss) er das für diese Erweiterung definierte Token in das ice-options-Attribut aufnehmen.

Das Folgende ist eine beispielhafte SDP-Nachricht, die ICE-Attribute enthält (Zeilen zur besseren Lesbarkeit umgebrochen):

    v=0
    o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
    s=
    c=IN IP4 192.0.2.3
    t=0 0
    a=ice-pwd:asd88fgpdd777uzjYhagZg
    a=ice-ufrag:8hhY
    m=audio 45664 RTP/AVP 0
    b=RS:0
    b=RR:0
    a=rtpmap:0 PCMU/8000
    a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
    a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998

Sobald ein Agent sein Angebot oder seine Antwort gesendet hat, MUST (muss) dieser Agent bereit sein, sowohl STUN- als auch Medienpakete auf jedem Kandidaten zu empfangen. Wie in Abschnitt 11.1 erläutert, können Medienpakete an einen Kandidaten gesendet werden, bevor er als Standardziel für Medien in einem Angebot oder einer Antwort erscheint.