17. Example (Beispiel)
Das Beispiel basiert auf der vereinfachten Topologie von Abbildung 8.
+-----+
| |
|STUN |
| Srvr|
+-----+
|
+---------------------+
| |
| Internet |
| |
| |
+---------------------+
| |
| |
+---------+ |
| NAT | |
+---------+ |
| |
| |
| |
+-----+ +-----+
| | | |
| L | | R |
| | | |
+-----+ +-----+
Figure 8: Example Topology
Zwei Agenten, L und R, verwenden ICE. Beide sind ICE-Implementierungen im vollständigen Modus (full-mode) und verwenden aggressive Nominierung (aggressive nomination), wenn sie steuern. Beide Agenten haben eine einzelne IPv4-Adresse. Für Agent L ist es 10.0.1.1 im privaten Adressraum [RFC1918] und für Agent R 192.0.2.1 im öffentlichen Internet. Beide sind mit demselben STUN-Server konfiguriert (in diesem Beispiel der Einfachheit halber gezeigt, obwohl die Agenten in der Praxis nicht denselben STUN-Server verwenden müssen), der an der IP-Adresse 192.0.2.2 und Port 3478 auf STUN-Binding-Anfragen lauscht. TURN-Server werden in diesem Beispiel nicht verwendet. Agent L befindet sich hinter einem NAT und Agent R im öffentlichen Internet. Das NAT verfügt über eine endpunktunabhängige Abbildungseigenschaft und eine adressabhängige Filtereigenschaft. Die öffentliche Seite des NAT hat die IP-Adresse 192.0.2.3.
Um das Verständnis zu erleichtern, werden Transportadressen unter Verwendung von Variablen mit mnemonischen Namen aufgelistet. Das Format des Namens ist entity-type-seqno, wobei sich entity auf die Entität bezieht, auf der sich die IP-Adresse der Transportadresse befindet, und eine von „L“, „R“, „STUN“ oder „NAT“ ist. Der Typ ist entweder „PUB“ für öffentliche Transportadressen oder „PRIV“ für private Transportadressen. Schließlich ist seq-no eine Sequenznummer, die für jede Transportadresse desselben Typs auf einer bestimmten Entität unterschiedlich ist. Jede Variable hat eine IP-Adresse und einen Port, bezeichnet durch varname.IP bzw. varname.PORT, wobei varname der Name der Variablen ist.
Der STUN-Server hat die Transportadresse STUN-PUB-1 (das ist 192.0.2.2:3478) angekündigt.
Im Call-Flow selbst sind STUN-Nachrichten mit mehreren Attributen versehen. Das Attribut „S=“ gibt die Quelltransportadresse der Nachricht an. Das Attribut „D=“ gibt die Zieltransportadresse der Nachricht an. Das Attribut „MA=“ wird in STUN-Binding-Antwortnachrichten verwendet und bezieht sich auf die abgebildete Adresse (mapped address). „USE-CAND“ impliziert das Vorhandensein des USE-CANDIDATE-Attributs.
Die Call-Flow-Beispiele lassen STUN-Authentifizierungsvorgänge und RTCP weg und konzentrieren sich auf RTP für einen einzelnen Medienstrom zwischen zwei vollständigen Implementierungen.
L NAT STUN R
|RTP STUN alloc. | |
|(1) STUN Req | | |
|S=$L-PRIV-1 | | |
|D=$STUN-PUB-1 | | |
|------------->| | |
| |(2) STUN Req | |
| |S=$NAT-PUB-1 | |
| |D=$STUN-PUB-1 | |
| |------------->| |
| |(3) STUN Res | |
| |S=$STUN-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<-------------| |
|(4) STUN Res | | |
|S=$STUN-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|(5) Offer | | |
|------------------------------------------->|
| | | |RTP STUN
alloc.
| | |(6) STUN Req |
| | |S=$R-PUB-1 |
| | |D=$STUN-PUB-1 |
| | |<-------------|
| | |(7) STUN Res |
| | |S=$STUN-PUB-1 |
| | |D=$R-PUB-1 |
| |MA=$R-PUB-1 | |
| | |------------->|
|(8) answer | | |
|<-------------------------------------------|
| |(9) Bind Req | |Begin
| |S=$R-PUB-1 | |Connectivity
| |D=L-PRIV-1 | |Checks
| |<----------------------------|
| |Dropped | |
|(10) Bind Req | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|USE-CAND | | |
|------------->| | |
| |(11) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |USE-CAND | |
| |---------------------------->|
| |(12) Bind Res | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<----------------------------|
|(13) Bind Res | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|RTP flows | | |
| |(14) Bind Req | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |<----------------------------|
|(15) Bind Req | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|<-------------| | |
|(16) Bind Res | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|MA=$R-PUB-1 | | |
|------------->| | |
| |(17) Bind Res | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |MA=$R-PUB-1 | |
| |---------------------------->|
| | | |RTP flows
Figure 9: Example Flow
Zuerst erhält Agent L einen Host-Kandidaten von seiner lokalen IP-Adresse (nicht gezeigt) und sendet von dort eine STUN-Binding-Anfrage an den STUN-Server, um einen Server-Reflexive-Kandidaten zu erhalten (Nachrichten 1-4). Erinnern Sie sich, dass das NAT die adress- und portunabhängige Abbildungseigenschaft hat. Hier erstellt es eine Bindung von NAT-PUB-1 für diese UDP-Anfrage, und dies wird zum Server-Reflexive-Kandidaten für RTP.
Agent L setzt eine Typpräferenz von 126 für den Host-Kandidaten und 100 für den Server-Reflexive. Die lokale Präferenz ist 65535. Basierend darauf ist die Priorität des Host-Kandidaten 2130706431 und für den Server-Reflexive-Kandidaten 1694498815. Dem Host-Kandidaten wird eine Foundation von 1 zugewiesen und dem Server-Reflexive eine Foundation von 2. Er wählt seinen Server-Reflexive-Kandidaten als Standardkandidaten und codiert ihn in die m- und c-Zeilen. Das resultierende Angebot (Nachricht 5) sieht so aus (Zeilen der Übersichtlichkeit halber umgebrochen):
v=0
o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
s=
c=IN IP4 $NAT-PUB-1.IP
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio $NAT-PUB-1.PORT RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ
host
a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ
srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT
Das Angebot, bei dem die Variablen durch ihre Werte ersetzt sind, sieht so aus (Zeilen der Übersichtlichkeit halber 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
Dieses Angebot wird bei Agent R empfangen. Agent R erhält einen Host-Kandidaten und von ihm einen Server-Reflexive-Kandidaten (Nachrichten 6-7). Da R nicht hinter einem NAT steht, ist dieser Kandidat identisch mit seinem Host-Kandidaten, und sie teilen dieselbe Basis. Er verwirft daher diesen redundanten Kandidaten und endet mit einem einzigen Host-Kandidaten. Mit identischen Typ- und lokalen Präferenzen wie L ist die Priorität für diesen Kandidaten 2130706431. Er wählt eine Foundation von 1 für seinen einzigen Kandidaten. Seine resultierende Antwort sieht so aus:
v=0
o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
s=
c=IN IP4 $R-PUB-1.IP
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=audio $R-PUB-1.PORT RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 $R-PUB-1.IP $R-PUB-1.PORT typ host
Mit den ausgefüllten Variablen:
v=0
o=bob 2808844564 2808844564 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=audio 3478 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host
Da keine Seite angegeben hat, dass sie lite ist, wird der Agent, der das Angebot gesendet hat, das die ICE-Verarbeitung begann (Agent L), zum steuernden Agenten.
Die Agenten L und R paaren beide die Kandidaten. Beide haben zunächst zwei Paare. Agent L wird jedoch das Paar entfernen, das seinen Server-Reflexive-Kandidaten enthält, was zu nur einem führt. Bei Agent L hat dieses Paar einen lokalen Kandidaten von $L_PRIV_1 und einen Remote-Kandidaten von $R_PUB_1 und hat eine Kandidatenpaarpriorität von 4,57566E+18 (beachten Sie, dass eine Implementierung dies als 64-Bit-Ganzzahl darstellen würde, um keine Genauigkeit zu verlieren). Bei Agent R gibt es zwei Paare. Die höchste Priorität hat einen lokalen Kandidaten von $R_PUB_1 und einen Remote-Kandidaten von $L_PRIV_1 und hat eine Priorität von 4,57566E+18, und die zweite hat einen lokalen Kandidaten von $R_PUB_1 und einen Remote-Kandidaten von $NAT_PUB_1 und eine Priorität von 3,63891E+18.
Agent R beginnt seine Konnektivitätsprüfung (Nachricht 9) für das erste Paar (zwischen den beiden Host-Kandidaten). Da R der gesteuerte Agent für diese Sitzung ist, lässt die Prüfung das USE-CANDIDATE-Attribut weg. Der Host-Kandidat von Agent L ist privat und befindet sich hinter einem NAT, und daher wird diese Prüfung nicht erfolgreich sein, da das Paket nicht von R nach L geroutet werden kann.
Wenn Agent L die Antwort erhält, führt er seine einzige Konnektivitätsprüfung durch (Nachrichten 10-13). Er implementiert den aggressiven Nominierungsalgorithmus und fügt daher ein USE-CANDIDATE-Attribut in diese Prüfung ein. Da die Prüfung erfolgreich ist, erstellt Agent L ein neues Paar, dessen lokaler Kandidat von der abgebildeten Adresse in der Binding-Antwort (NAT-PUB-1 aus Nachricht 13) stammt und dessen Remote-Kandidat das Ziel der Anfrage (R-PUB-1 aus Nachricht 10) ist. Dies wird der gültigen Liste (Valid list) hinzugefügt. Darüber hinaus wird es als ausgewählt (selected) markiert, da die Binding-Anfrage das USE-CANDIDATE-Attribut enthielt. Da es in der gültigen Liste für die eine Komponente dieses Medienstroms einen ausgewählten Kandidaten gibt, geht die ICE-Verarbeitung für diesen Strom in den Status Abgeschlossen (Completed) über. Agent L kann nun Medien senden, wenn er dies wünscht.
Kurz nach Erhalt der STUN-Binding-Anfrage von Agent L (Nachricht 11) generiert Agent R seine ausgelöste Prüfung. Diese Prüfung stimmt zufällig mit der nächsten auf seiner Prüfliste überein – von seinem Host-Kandidaten zum Server-Reflexive-Kandidaten von Agent L. Diese Prüfung (Nachrichten 14-17) wird erfolgreich sein. Folglich konstruiert Agent R ein neues Kandidatenpaar unter Verwendung der abgebildeten Adresse aus der Antwort als lokalen Kandidaten (R-PUB-1) und des Ziels der Anfrage (NAT-PUB-1) als Remote-Kandidaten. Dieses Paar wird der gültigen Liste für diesen Medienstrom hinzugefügt. Da die Prüfung in umgekehrter Richtung einer Prüfung generiert wurde, die das USE-CANDIDATE-Attribut enthielt, wird das Kandidatenpaar als ausgewählt markiert. Folglich geht die Verarbeitung für diesen Strom in den Status Abgeschlossen über, und Agent R kann ebenfalls Medien senden.