5. Receiving the Initial Offer (Réception de l'offre initiale)
Lorsqu'un agent reçoit une offre initiale, il vérifie si l'offrant prend en charge ICE, détermine son propre rôle, collecte des candidats, les classe par priorité, choisit des candidats par défaut, encode et envoie une réponse, et pour les implémentations complètes, forme les listes de vérification et commence les vérifications de connectivité.
5.1. Verifying ICE Support (Vérification de la prise en charge d'ICE)
L'agent procédera aux procédures ICE définies dans cette spécification si, pour chaque flux média dans le SDP qu'il a reçu, la destination par défaut pour chaque composant de ce flux média apparaît dans un attribut candidate. Par exemple, dans le cas de RTP, l'adresse IP et le port dans les lignes c et m, respectivement, apparaissent dans un attribut candidate et la valeur dans l'attribut rtcp apparaît dans un attribut candidate.
Si cette condition n'est pas remplie, l'agent MUST (doit) traiter le SDP sur la base des procédures normales de la RFC 3264, sans utiliser aucun des mécanismes ICE décrits dans le reste de cette spécification, à l'exception des exceptions suivantes :
-
L'agent MUST (doit) suivre les règles de la section 10, qui décrivent les procédures de maintien en vie pour tous les agents.
-
Si l'agent ne poursuit pas avec ICE parce qu'il y avait des attributs a=candidate, mais aucun qui correspondait à la destination par défaut du flux média, l'agent MUST (doit) inclure un attribut a=ice-mismatch dans sa réponse.
-
Si les candidats par défaut étaient des candidats relayés appris via un serveur TURN, l'agent MUST (doit) créer des autorisations dans le serveur TURN pour les adresses IP apprises de son pair dans le SDP qu'il vient de recevoir. Si cela n'est pas fait, les paquets initiaux dans le flux média du pair peuvent être perdus.
5.2. Determining Role (Détermination du rôle)
Pour chaque session, chaque agent assume un rôle. Il existe deux rôles : contrôlant (controlling) et contrôlé (controlled). L'agent contrôlant est responsable du choix des paires de candidats finales utilisées pour les communications. Pour un agent complet, cela signifie nommer les paires de candidats qui peuvent être utilisées par ICE pour chaque flux média, et générer l'offre mise à jour basée sur la sélection d'ICE, si nécessaire. Pour une implémentation légère, être l'agent contrôlant signifie sélectionner une paire de candidats basée sur celles de l'offre et de la réponse (pour IPv4, il n'y a jamais qu'une seule paire), puis générer une offre mise à jour reflétant cette sélection, si nécessaire (ce n'est jamais nécessaire pour un hôte IPv4 uniquement). L'agent contrôlé se voit dire quelles paires de candidats utiliser pour chaque flux média, et ne génère pas d'offre mise à jour pour signaler cette information. Les sections ci-dessous décrivent en détail les procédures réelles suivies par les nœuds contrôlants et contrôlés.
Les règles pour déterminer le rôle et l'impact sur le comportement sont les suivantes :
-
Les deux agents sont complets : L'agent qui a généré l'offre qui a lancé le traitement ICE MUST (doit) prendre le rôle contrôlant, et l'autre MUST (doit) prendre le rôle contrôlé. Les deux agents formeront des listes de vérification, exécuteront les machines d'état ICE et généreront des vérifications de connectivité. L'agent contrôlant exécutera la logique de la section 8.1 pour nommer les paires qui seront sélectionnées par ICE, puis les deux agents termineront ICE comme décrit dans la section 8.1.2. Dans des cas inhabituels, décrits à l'annexe B.11, il est possible que les deux agents croient à tort qu'ils sont contrôlés ou contrôlants. Pour résoudre ce problème, chaque agent MUST (doit) sélectionner un nombre aléatoire, appelé départage (tie-breaker), uniformément distribué entre 0 et (2**64) - 1 (c'est-à-dire un entier positif de 64 bits). Ce nombre est utilisé dans les vérifications de connectivité pour détecter et réparer ce cas, comme décrit dans la section 7.1.2.2.
-
Un agent complet, un léger : L'agent complet MUST (doit) prendre le rôle contrôlant, et l'agent léger MUST (doit) prendre le rôle contrôlé. L'agent complet formera des listes de vérification, exécutera les machines d'état ICE et générera des vérifications de connectivité. Cet agent exécutera la logique de la section 8.1 pour nommer les paires qui seront sélectionnées par ICE, et utilisera la logique de la section 8.1.2 pour terminer ICE. L'implémentation légère écoutera simplement les vérifications de connectivité, les recevra et y répondra, puis conclura ICE comme décrit dans la section 8.2. Pour l'implémentation légère, l'état du traitement ICE pour chaque flux média est considéré comme Running (En cours), et l'état d'ICE global est Running.
-
Les deux légers : L'agent qui a généré l'offre qui a lancé le traitement ICE MUST (doit) prendre le rôle contrôlant, et l'autre MUST (doit) prendre le rôle contrôlé. Dans ce cas, aucune vérification de connectivité n'est jamais envoyée. Au lieu de cela, une fois l'échange offre/réponse terminé, chaque agent effectue le traitement décrit à la section 8 sans vérifications de connectivité. Il est possible que les deux agents croient qu'ils sont contrôlés ou contrôlants. Dans ce dernier cas, le conflit est résolu grâce aux capacités de détection d'éblouissement (glare) dans le protocole de signalisation transportant l'échange offre/réponse. L'état du traitement ICE pour chaque flux média est considéré comme Running, et l'état d'ICE global est Running.
Une fois les rôles déterminés pour une session, ils persistent à moins qu'ICE ne soit redémarré. Un redémarrage d'ICE (section 9.1) entraîne une nouvelle sélection des rôles et des départages.
5.3. Gathering Candidates (Collecte des candidats)
Le processus de collecte des candidats chez le répondeur est identique au processus pour l'offrant tel que décrit dans la section 4.1.1 pour les implémentations complètes et la section 4.2 pour les implémentations légères. Il est RECOMMENDED (recommandé) que ce processus commence immédiatement à la réception de l'offre, avant d'alerter l'utilisateur. Une telle collecte MAY (peut) commencer lorsqu'un agent démarre.
5.4. Prioritizing Candidates (Classement par priorité des candidats)
Le processus de classement par priorité des candidats chez le répondeur est identique au processus suivi par l'offrant, comme décrit dans la section 4.1.2 pour les implémentations complètes et la section 4.2 pour les implémentations légères.
5.5. Choosing Default Candidates (Choix des candidats par défaut)
Le processus de sélection des candidats par défaut chez le répondeur est identique au processus suivi par l'offrant, comme décrit dans la section 4.1.4 pour les implémentations complètes et la section 4.2 pour les implémentations légères.
5.6. Encoding the SDP (Encodage du SDP)
Le processus d'encodage du SDP chez le répondeur est identique au processus suivi par l'offrant pour les implémentations complètes et légères, comme décrit dans la section 4.3.
5.7. Forming the Check Lists (Formation des listes de vérification)
La formation des listes de vérification est effectuée uniquement par des implémentations complètes. Les implémentations légères MUST (doivent) ignorer les étapes définies dans cette section.
Il y a une liste de vérification par flux média utilisé résultant de l'échange offre/réponse. Pour former la liste de vérification pour un flux média, l'agent forme des paires de candidats, calcule une priorité de paire de candidats, ordonne les paires par priorité, les élague et définit leurs états. Ces étapes sont décrites dans cette section.
5.7.1. Forming Candidate Pairs (Formation des paires de candidats)
Tout d'abord, l'agent prend chacun de ses candidats pour un flux média (appelés CANDIDATS LOCAUX) et les associe aux candidats qu'il a reçus de son pair (appelés CANDIDATS DISTANTS) pour ce flux média. Afin de prévenir les attaques décrites à la section 18.5.2, les agents MAY (peuvent) limiter le nombre de candidats qu'ils accepteront dans une offre ou une réponse. Un candidat local est associé à un candidat distant si et seulement si les deux candidats ont le même ID de composant et ont la même version d'adresse IP. Il est possible que certains des candidats locaux ne soient pas associés à des candidats distants, et que certains des candidats distants ne soient pas associés à des candidats locaux. Cela peut se produire si un agent n'inclut pas de candidats pour tous les composants d'un flux média. Si cela se produit, le nombre de composants pour ce flux média est effectivement réduit, et considéré comme égal au minimum entre les deux agents de l'ID de composant maximum fourni par chaque agent pour tous les composants du flux média.
Dans le cas de RTP, cela se produirait lorsqu'un agent fournit des candidats pour RTCP, et l'autre non. Autre exemple, l'offrant peut multiplexer RTP et RTCP sur le même port et signaler qu'il peut le faire dans le SDP via un attribut SDP [RFC5761]. Cependant, comme l'offrant ne sait pas si le répondeur peut effectuer un tel multiplexage, l'offrant inclut des candidats pour RTP et RTCP sur des ports séparés, de sorte que l'offre a deux composants par flux média. Si le répondeur peut effectuer un tel multiplexage, il inclurait un seul composant pour chaque candidat - pour le multiplex RTP/RTCP combiné. ICE finirait par agir comme s'il n'y avait qu'un seul composant pour ce candidat.
Les paires de candidats dont les candidats locaux et distants sont tous deux les candidats par défaut pour un composant particulier sont appelées, sans surprise, la paire de candidats par défaut pour ce composant. C'est la paire qui serait utilisée pour transmettre le média si les deux agents n'avaient pas été conscients d'ICE.
Afin de faciliter la compréhension, la figure 6 montre les relations entre plusieurs concepts clés -- adresses de transport, candidats, paires de candidats et listes de vérification, en plus d'indiquer les principales propriétés des candidats et des paires de candidats.
+------------------------------------------+
| |
| +---------------------+ |
| |+----+ +----+ +----+ | +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
Figure 6: Diagramme conceptuel d'une liste de vérification
5.7.2. Computing Pair Priority and Ordering Pairs (Calcul de la priorité des paires et ordonnancement des paires)
Une fois les paires formées, une priorité de paire de candidats est calculée. Soit G la priorité du candidat fourni par l'agent contrôlant. Soit D la priorité du candidat fourni par l'agent contrôlé. La priorité d'une paire est calculée comme suit :
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Où G>D?1:0 est une expression dont la valeur est 1 si G est supérieur à D, et 0 sinon. Une fois la priorité attribuée, l'agent trie les paires de candidats par ordre décroissant de priorité. Si deux paires ont une priorité identique, l'ordre entre elles est arbitraire.
5.7.3. Pruning the Pairs (Élagage des paires)
Cette liste triée de paires de candidats est utilisée pour déterminer une séquence de vérifications de connectivité qui seront effectuées. Chaque vérification implique l'envoi d'une requête d'un candidat local à un candidat distant. Puisqu'un agent ne peut pas envoyer de requêtes directement depuis un candidat réflexif, mais seulement depuis sa base, l'agent parcourt ensuite la liste triée de paires de candidats. Pour chaque paire où le candidat local est réflexif serveur, le candidat réflexif serveur MUST (doit) être remplacé par sa base. Une fois que cela a été fait, l'agent MUST (doit) élaguer la liste. Cela se fait en supprimant une paire si ses candidats locaux et distants sont identiques aux candidats locaux et distants d'une paire plus haut dans la liste de priorité. Le résultat est une séquence de paires de candidats ordonnées, appelée la liste de vérification pour ce flux média.
De plus, afin de limiter les attaques décrites à la section 18.5.2, un agent MUST (doit) limiter le nombre total de vérifications de connectivité que l'agent effectue sur toutes les listes de vérification à une valeur spécifique, et cette valeur MUST (doit) être configurable. Une valeur par défaut de 100 est RECOMMENDED (recommandée). Cette limite est appliquée en écartant les paires de candidats de priorité inférieure jusqu'à ce qu'il y en ait moins de 100. Il est RECOMMENDED (recommandé) qu'une valeur inférieure soit utilisée lorsque cela est possible, définie sur le nombre maximum de vérifications plausibles qui pourraient être observées dans une configuration de déploiement réelle. L'exigence de configuration vise à fournir un outil pour fixer cette valeur sur le terrain si, une fois déployée, elle s'avère problématique.
5.7.4. Computing States (Calcul des états)
Chaque paire de candidats dans la liste de vérification a une fondation et un état. La fondation est la combinaison des fondations des candidats locaux et distants dans la paire. L'état est attribué une fois que la liste de vérification pour chaque flux média a été calculée. Il y a cinq valeurs potentielles que l'état peut avoir :
-
Waiting (En attente) : Une vérification n'a pas été effectuée pour cette paire, et peut être effectuée dès qu'elle est la paire En attente de plus haute priorité sur la liste de vérification.
-
In-Progress (En cours) : Une vérification a été envoyée pour cette paire, mais la transaction est en cours.
-
Succeeded (Réussi) : Une vérification pour cette paire a déjà été effectuée et a produit un résultat positif.
-
Failed (Échoué) : Une vérification pour cette paire a déjà été effectuée et a échoué, ne produisant jamais de réponse ou produisant une réponse d'échec irrécupérable.
-
Frozen (Gelé) : Une vérification pour cette paire n'a pas été effectuée, et elle ne peut pas encore être effectuée jusqu'à ce qu'une autre vérification réussisse, permettant à cette paire de dégeler et de passer à l'état En attente.
Pendant l'exécution d'ICE, les paires se déplaceront entre les états comme indiqué à la figure 7.
+-----------+
| |
| |
| Frozen |
| |
| |
+-----------+
|
|unfreeze
|
V
+-----------+ +-----------+
| | | |
| | perform | |
| Waiting |-------->|In-Progress|
| | | |
| | | |
+-----------+ +-----------+
/ |
// |
// |
// |
/ |
// |
failure // |success
// |
/ |
// |
// |
// |
V V
+-----------+ +-----------+
| | | |
| | | |
| Failed | | Succeeded |
| | | |
| | | |
+-----------+ +-----------+
Figure 7: FSM d'état de la paire
Les états initiaux pour chaque paire dans une liste de vérification sont calculés en effectuant la séquence d'étapes suivante :
-
L'agent définit toutes les paires de chaque liste de vérification à l'état Gelé.
-
L'agent examine la liste de vérification pour le premier flux média (un flux média est le premier flux média lorsqu'il est décrit par la première ligne m dans l'offre et la réponse SDP). Pour ce flux média :
- Pour toutes les paires avec la même fondation, il définit l'état de la paire avec l'ID de composant le plus bas sur En attente. S'il y a plus d'une telle paire, celle avec la priorité la plus élevée est utilisée.
L'une des listes de vérification aura un certain nombre de paires à l'état En attente, et les autres listes de vérification auront toutes leurs paires à l'état Gelé. Une liste de vérification avec au moins une paire En attente est appelée une liste de vérification active, et une liste de vérification avec toutes les paires Gelées est appelée une liste de vérification gelée.
La liste de vérification elle-même est associée à un état, qui capture l'état des vérifications ICE pour ce flux média. Il y a trois états :
-
Running (En cours) : Dans cet état, les vérifications ICE sont toujours en cours pour ce flux média.
-
Completed (Terminé) : Dans cet état, les vérifications ICE ont produit des paires nommées pour chaque composant du flux média. Par conséquent, ICE a réussi et le média peut être envoyé.
-
Failed (Échoué) : Dans cet état, les vérifications ICE ne se sont pas terminées avec succès pour ce flux média.
Lorsqu'une liste de vérification est construite pour la première fois à la suite d'un échange offre/réponse, elle est placée à l'état En cours.
Le traitement ICE sur tous les flux média a également un état associé. Cet état est égal à Running tant que le traitement ICE est en cours. L'état est Completed lorsque le traitement ICE est terminé et Failed s'il a échoué sans succès. Les règles de transition entre les états sont décrites ci-dessous.
5.8. Scheduling Checks (Planification des vérifications)
Les vérifications sont générées uniquement par des implémentations complètes. Les implémentations légères MUST (doivent) ignorer les étapes décrites dans cette section.
Un agent effectue des vérifications ordinaires et des vérifications déclenchées. La génération des deux vérifications est régie par un temporisateur qui se déclenche périodiquement pour chaque flux média. L'agent maintient une file d'attente FIFO, appelée file d'attente de vérifications déclenchées (triggered check queue), qui contient des paires de candidats pour lesquelles des vérifications doivent être envoyées à la prochaine opportunité disponible. Lorsque le temporisateur se déclenche, l'agent supprime la paire supérieure de la file d'attente de vérifications déclenchées, effectue une vérification de connectivité sur cette paire et définit l'état de la paire de candidats sur En cours. S'il n'y a pas de paires dans la file d'attente de vérifications déclenchées, une vérification ordinaire est envoyée.
Une fois que l'agent a calculé les listes de vérification comme décrit à la section 5.7, il définit un temporisateur pour chaque liste de vérification active. Le temporisateur se déclenche toutes les Ta*N secondes, où N est le nombre de listes de vérification actives (initialement, il n'y a qu'une seule liste de vérification active). Les implémentations MAY (peuvent) régler le temporisateur pour qu'il se déclenche moins fréquemment que cela. Les implémentations SHOULD (devraient) veiller à étaler ces temporisateurs afin qu'ils ne se déclenchent pas en même temps pour chaque flux média. Ta et le temporisateur de retransmission RTO sont calculés comme décrit à la section 16. La multiplication par N permet de répartir ce débit de vérification global entre toutes les listes de vérification actives. Le premier temporisateur se déclenche immédiatement, de sorte que l'agent effectue une vérification de connectivité au moment où l'échange offre/réponse a été effectué, suivi de la vérification suivante Ta secondes plus tard (puisqu'il n'y a qu'une seule liste de vérification active).
Lorsque le temporisateur se déclenche et qu'il n'y a pas de vérification déclenchée à envoyer, l'agent MUST (doit) choisir une vérification ordinaire comme suit :
-
Trouver la paire de priorité la plus élevée dans cette liste de vérification qui est à l'état En attente.
-
S'il existe une telle paire :
- Envoyer une vérification STUN du candidat local de cette paire au candidat distant de cette paire. Les procédures pour former la requête STUN à cette fin sont décrites à la section 7.1.2.
- Définir l'état de la paire de candidats sur En cours.
-
S'il n'y a pas une telle paire :
- Trouver la paire de priorité la plus élevée dans cette liste de vérification qui est à l'état Gelé.
- S'il existe une telle paire :
- Dégeler la paire.
- Effectuer une vérification pour cette paire, provoquant la transition de son état vers En cours.
- S'il n'y a pas une telle paire :
- Mettre fin au temporisateur pour cette liste de vérification.
Pour calculer l'intégrité du message pour la vérification, l'agent utilise le fragment de nom d'utilisateur distant et le mot de passe appris du SDP de son pair. Le fragment de nom d'utilisateur local est connu directement par l'agent pour son propre candidat.