17. Example (Exemple)
L'exemple est basé sur la topologie simplifiée de la figure 8.
+-----+
| |
|STUN |
| Srvr|
+-----+
|
+---------------------+
| |
| Internet |
| |
| |
+---------------------+
| |
| |
+---------+ |
| NAT | |
+---------+ |
| |
| |
| |
+-----+ +-----+
| | | |
| L | | R |
| | | |
+-----+ +-----+
Figure 8: Example Topology
Deux agents, L et R, utilisent ICE. Tous deux sont des implémentations ICE en mode complet et utilisent la nomination agressive (aggressive nomination) lorsqu'ils contrôlent. Les deux agents ont une seule adresse IPv4. Pour l'agent L, c'est 10.0.1.1 dans l'espace d'adressage privé [RFC1918], et pour l'agent R, 192.0.2.1 sur l'Internet public. Tous deux sont configurés avec le même serveur STUN (montré dans cet exemple pour plus de simplicité, bien qu'en pratique les agents n'aient pas besoin d'utiliser le même serveur STUN), qui écoute les requêtes STUN Binding à une adresse IP de 192.0.2.2 et au port 3478. Les serveurs TURN ne sont pas utilisés dans cet exemple. L'agent L est derrière un NAT et l'agent R est sur l'Internet public. Le NAT a une propriété de mappage indépendant du point de terminaison et une propriété de filtrage dépendant de l'adresse. Le côté public du NAT a une adresse IP de 192.0.2.3.
Pour faciliter la compréhension, les adresses de transport sont répertoriées à l'aide de variables ayant des noms mnémoniques. Le format du nom est entity-type-seqno, où entity fait référence à l'entité sur laquelle se trouve l'adresse IP de l'adresse de transport, et est l'un de "L", "R", "STUN" ou "NAT". Le type est soit "PUB" pour les adresses de transport publiques, soit "PRIV" pour les adresses de transport privées. Enfin, seq-no est un numéro de séquence différent pour chaque adresse de transport du même type sur une entité particulière. Chaque variable a une adresse IP et un port, notés respectivement varname.IP et varname.PORT, où varname est le nom de la variable.
Le serveur STUN a annoncé l'adresse de transport STUN-PUB-1 (qui est 192.0.2.2:3478).
Dans le flux d'appel lui-même, les messages STUN sont annotés avec plusieurs attributs. L'attribut "S=" indique l'adresse de transport source du message. L'attribut "D=" indique l'adresse de transport de destination du message. L'attribut "MA=" est utilisé dans les messages de réponse STUN Binding et fait référence à l'adresse mappée. "USE-CAND" implique la présence de l'attribut USE-CANDIDATE.
Les exemples de flux d'appels omettent les opérations d'authentification STUN et RTCP, et se concentrent sur RTP pour un seul flux multimédia entre deux implémentations complètes.
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
Premièrement, l'agent L obtient un candidat host à partir de son adresse IP locale (non représentée) et, à partir de là, envoie une requête STUN Binding au serveur STUN pour obtenir un candidat server reflexive (messages 1-4). Rappelons que le NAT a la propriété de mappage indépendant de l'adresse et du port. Ici, il crée une liaison de NAT-PUB-1 pour cette requête UDP, et cela devient le candidat server reflexive pour RTP.
L'agent L définit une préférence de type de 126 pour le candidat host et de 100 pour le server reflexive. La préférence locale est 65535. Sur cette base, la priorité du candidat host est 2130706431 et pour le candidat server reflexive est 1694498815. Le candidat host se voit attribuer une foundation de 1 et le server reflexive une foundation de 2. Il choisit son candidat server reflexive comme candidat par défaut et l'encode dans les lignes m et c. L'offre résultante (message 5) ressemble à (lignes pliées pour plus de clarté) :
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
L'offre, avec les variables remplacées par leurs valeurs, ressemblera à (lignes pliées pour plus de clarté) :
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
Cette offre est reçue à l'agent R. L'agent R obtiendra un candidat host et, à partir de celui-ci, obtiendra un candidat server reflexive (messages 6-7). Puisque R n'est pas derrière un NAT, ce candidat est identique à son candidat host, et ils partagent la même base. Il rejette donc ce candidat redondant et se retrouve avec un seul candidat host. Avec des préférences de type et locales identiques à L, la priorité de ce candidat est 2130706431. Il choisit une foundation de 1 pour son unique candidat. Sa réponse résultante ressemble à :
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
Avec les variables remplies :
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
Puisqu'aucun des deux côtés n'a indiqué qu'il est lite, l'agent qui a envoyé l'offre qui a commencé le traitement ICE (agent L) devient l'agent de contrôle.
Les agents L et R apparient tous deux les candidats. Ils ont tous deux initialement deux paires. Cependant, l'agent L élaguera la paire contenant son candidat server reflexive, ce qui n'en laissera qu'une seule. Au niveau de l'agent L, cette paire a un candidat local de $L_PRIV_1 et un candidat distant de $R_PUB_1, et a une priorité de paire de candidats de 4,57566E+18 (notez qu'une implémentation représenterait cela comme un entier de 64 bits afin de ne pas perdre en précision). Au niveau de l'agent R, il y a deux paires. La priorité la plus élevée a un candidat local de $R_PUB_1 et un candidat distant de $L_PRIV_1 et a une priorité de 4,57566E+18, et la seconde a un candidat local de $R_PUB_1 et un candidat distant de $NAT_PUB_1 et une priorité de 3,63891E+18.
L'agent R commence sa vérification de connectivité (message 9) pour la première paire (entre les deux candidats host). Puisque R est l'agent contrôlé pour cette session, la vérification omet l'attribut USE-CANDIDATE. Le candidat host de l'agent L est privé et derrière un NAT, et donc cette vérification ne réussira pas, car le paquet ne peut pas être routé de R vers L.
Lorsque l'agent L obtient la réponse, il effectue sa seule et unique vérification de connectivité (messages 10-13). Il implémente l'algorithme de nomination agressive et inclut donc un attribut USE-CANDIDATE dans cette vérification. Puisque la vérification réussit, l'agent L crée une nouvelle paire, dont le candidat local provient de l'adresse mappée dans la réponse Binding (NAT-PUB-1 du message 13) et dont le candidat distant est la destination de la requête (R-PUB-1 du message 10). Celle-ci est ajoutée à la liste valide (Valid list). De plus, elle est marquée comme sélectionnée (selected) puisque la requête Binding contenait l'attribut USE-CANDIDATE. Puisqu'il y a un candidat sélectionné dans la liste valide pour l'unique composant de ce flux multimédia, le traitement ICE pour ce flux passe à l'état Terminé (Completed). L'agent L peut maintenant envoyer des médias s'il le choisit.
Peu de temps après la réception de la requête STUN Binding de l'agent L (message 11), l'agent R générera sa vérification déclenchée. Cette vérification correspond par hasard à la suivante sur sa liste de vérification -- de son candidat host vers le candidat server reflexive de l'agent L. Cette vérification (messages 14-17) réussira. Par conséquent, l'agent R construit une nouvelle paire de candidats en utilisant l'adresse mappée de la réponse comme candidat local (R-PUB-1) et la destination de la requête (NAT-PUB-1) comme candidat distant. Cette paire est ajoutée à la liste valide pour ce flux multimédia. Puisque la vérification a été générée dans la direction inverse d'une vérification qui contenait l'attribut USE-CANDIDATE, la paire de candidats est marquée comme sélectionnée. Par conséquent, le traitement pour ce flux passe à l'état Terminé, et l'agent R peut également envoyer des médias.