7. Performing Connectivity Checks (Exécution des vérifications de connectivité)

Cette section décrit comment les vérifications de connectivité sont effectuées. Toutes les implémentations ICE doivent être conformes à [RFC5389], par opposition à l'ancienne [RFC3489]. Cependant, alors qu'une implémentation complète générera à la fois des vérifications (agissant comme un client STUN) et les recevra (agissant comme un serveur STUN), une implémentation Lite ne recevra que des vérifications, et n'agira donc que comme un serveur STUN.

7.1. STUN Client Procedures (Procédures client STUN)

Ces procédures définissent comment un agent envoie une vérification de connectivité, qu'il s'agisse d'une vérification ordinaire ou déclenchée. Ces procédures ne sont applicables qu'aux implémentations complètes.

7.1.1. Creating Permissions for Relayed Candidates (Création de permissions pour les candidats relayés)

Si la vérification de connectivité est envoyée à l'aide d'un candidat local relayé, le client MUST créer une permission d'abord s'il n'en a pas déjà créé une précédemment. Il en aurait créé une précédemment s'il avait dit au serveur TURN de créer une permission pour le candidat relayé donné vers l'adresse IP du candidat distant. Pour créer la permission, l'agent suit les procédures définies dans [RFC5766]. La permission MUST être créée vers l'adresse IP du candidat distant. Il est RECOMMENDED que l'agent diffère la création d'un canal TURN jusqu'à ce que ICE soit terminé, auquel cas les permissions pour les vérifications de connectivité sont normalement créées à l'aide d'une requête CreatePermission. Une fois établie, l'agent MUST maintenir la permission active jusqu'à la conclusion d'ICE.

7.1.2. Sending the Request (Envoi de la requête)

La vérification est générée en envoyant une requête Binding d'un candidat local à un candidat distant. [RFC5389] décrit comment les requêtes Binding sont construites et générées. Une vérification de connectivité MUST utiliser le mécanisme d'authentification à court terme STUN. La prise en charge de la rétrocompatibilité avec la RFC 3489 MUST NOT être utilisée ou supposée avec les vérifications de connectivité. Le mécanisme FINGERPRINT MUST être utilisé pour les vérifications de connectivité.

ICE étend STUN en définissant plusieurs nouveaux attributs, notamment PRIORITY, USE-CANDIDATE, ICE-CONTROLLED et ICE-CONTROLLING. Ces nouveaux attributs sont formellement définis dans la section 19.1, et leur utilisation est décrite dans les sous-sections ci-dessous. Ces extensions STUN sont applicables uniquement aux vérifications de connectivité utilisées pour ICE.

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

Un agent MUST inclure l'attribut PRIORITY dans sa requête Binding. L'attribut MUST être défini égal à la priorité qui serait attribuée, sur la base de l'algorithme de la section 4.1.2, à un candidat réflexif pair, si l'on devait en apprendre un à la suite de cette vérification (voir la section 7.1.3.2.1 pour savoir comment les candidats réflexifs pairs sont appris). Cette valeur de priorité sera calculée de manière identique à la façon dont la priorité pour le candidat local de la paire a été calculée, sauf que la préférence de type est définie sur la valeur pour les types de candidats réflexifs pairs.

L'agent contrôlant MAY inclure l'attribut USE-CANDIDATE dans la requête Binding. L'agent contrôlé MUST NOT l'inclure dans sa requête Binding. Cet attribut signale que l'agent contrôlant souhaite cesser les vérifications pour ce composant et utiliser la paire de candidats résultant de la vérification pour ce composant. La section 8.1.1 fournit des conseils sur la détermination du moment où l'inclure.

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

L'agent MUST inclure l'attribut ICE-CONTROLLED dans la requête s'il est dans le rôle contrôlé, et MUST inclure l'attribut ICE-CONTROLLING dans la requête s'il est dans le rôle contrôlant. Le contenu de l'un ou l'autre attribut MUST être le tie-breaker qui a été déterminé dans la section 5.2. Ces attributs sont définis complètement dans la section 19.1.

7.1.2.3. Forming Credentials (Formation des informations d'identification)

Une requête Binding servant de vérification de connectivité MUST utiliser le mécanisme d'authentification à court terme STUN. Le nom d'utilisateur pour les informations d'identification est formé en concaténant le fragment de nom d'utilisateur fourni par le pair avec le fragment de nom d'utilisateur de l'agent envoyant la requête, séparés par un deux-points (":"). Le mot de passe est égal au mot de passe fourni par le pair. Par exemple, considérons le cas où l'agent L est l'offrant, et l'agent R est le répondeur. L'agent L a inclus un fragment de nom d'utilisateur de LFRAG pour ses candidats et un mot de passe de LPASS. L'agent R a fourni un fragment de nom d'utilisateur de RFRAG et un mot de passe de RPASS. Une vérification de connectivité de L à R utilise le nom d'utilisateur RFRAG:LFRAG et un mot de passe de RPASS. Une vérification de connectivité de R à L utilise le nom d'utilisateur LFRAG:RFRAG et un mot de passe de LPASS. Les réponses utilisent les mêmes noms d'utilisateur et mots de passe que les requêtes (notez que l'attribut USERNAME n'est pas présent dans la réponse).

7.1.2.4. DiffServ Treatment (Traitement DiffServ)

Si l'agent utilise des marquages Diffserv Codepoint [RFC2475] dans ses paquets média, il SHOULD appliquer ces mêmes marquages à ses vérifications de connectivité.

7.1.3. Processing the Response (Traitement de la réponse)

Lorsqu'une réponse Binding est reçue, elle est corrélée à sa requête Binding à l'aide de l'ID de transaction, tel que défini dans [RFC5389], qui la lie ensuite à la paire de candidats pour laquelle la requête Binding a été envoyée. Cette section définit des procédures supplémentaires pour le traitement des réponses Binding spécifiques à cette utilisation de STUN.

7.1.3.1. Failure Cases (Cas d'échec)

Si la transaction STUN génère une réponse d'erreur 487 (Role Conflict), l'agent vérifie s'il a inclus l'attribut ICE-CONTROLLED ou ICE-CONTROLLING dans la requête Binding. Si la requête contenait l'attribut ICE-CONTROLLED, l'agent MUST passer au rôle contrôlant s'il ne l'a pas déjà fait. Si la requête contenait l'attribut ICE-CONTROLLING, l'agent MUST passer au rôle contrôlé s'il ne l'a pas déjà fait. Une fois qu'il a changé, l'agent MUST mettre en file d'attente la paire de candidats dont la vérification a généré le 487 dans la file d'attente des vérifications déclenchées. L'état de cette paire est défini sur Waiting. Lorsque la vérification déclenchée est envoyée, elle contiendra un attribut ICE-CONTROLLING ou ICE-CONTROLLED reflétant son nouveau rôle. Notez cependant que la valeur du tie-breaker MUST NOT être resélectionnée.

Un changement de rôle nécessitera qu'un agent recalcule les priorités des paires (Section 5.7.2), car ces priorités sont fonction des rôles contrôlant et contrôlé. Le changement de rôle aura également un impact sur la question de savoir si l'agent est responsable de la sélection des paires nommées et de la génération d'offres mises à jour à la conclusion d'ICE.

Les agents MAY prendre en charge la réception d'erreurs ICMP pour les vérifications de connectivité. Si la transaction STUN génère une erreur ICMP, l'agent définit l'état de la paire sur Failed. Si la transaction STUN génère une réponse d'erreur STUN qui est irrécupérable (telle que définie dans [RFC5389]) ou expire, l'agent définit l'état de la paire sur Failed.

L'agent MUST vérifier que l'adresse IP et le port source de la réponse sont égaux à l'adresse IP et au port de destination auxquels la requête Binding a été envoyée, et que l'adresse IP et le port de destination de la réponse correspondent à l'adresse IP et au port source à partir desquels la requête Binding a été envoyée. En d'autres termes, les adresses de transport source et destination dans la requête et les réponses sont symétriques. Si elles ne sont pas symétriques, l'agent définit l'état de la paire sur Failed.

7.1.3.2. Success Cases (Cas de succès)

Une vérification est considérée comme un succès si toutes les conditions suivantes sont vraies :

• La transaction STUN a généré une réponse de succès.
• L'adresse IP et le port source de la réponse sont égaux à l'adresse IP et au port de destination auxquels la requête Binding a été envoyée.
• L'adresse IP et le port de destination de la réponse correspondent à l'adresse IP et au port source à partir desquels la requête Binding a été envoyée.

7.1.3.2.1. Discovering Peer Reflexive Candidates (Découverte de candidats réflexifs pairs)

L'agent vérifie l'adresse mappée de la réponse STUN. Si l'adresse de transport ne correspond à aucun des candidats locaux que l'agent connaît, l'adresse mappée représente un nouveau candidat -- un candidat réflexif pair. Comme les autres candidats, il a un type, une base, une priorité et une fondation. Ils sont calculés comme suit :

• Son type est égal à réflexif pair.
• Sa base est définie égale au candidat local de la paire de candidats à partir de laquelle la vérification STUN a été envoyée.
• Sa priorité est définie égale à la valeur de l'attribut PRIORITY dans la requête Binding.
• Sa fondation est sélectionnée comme décrit dans la section 4.1.1.3.

Ce candidat réflexif pair est ensuite ajouté à la liste des candidats locaux pour le flux média. Son fragment de nom d'utilisateur et son mot de passe sont les mêmes que tous les autres candidats locaux pour ce flux média.

Cependant, le candidat réflexif pair n'est pas apparié avec d'autres candidats distants. Ce n'est pas nécessaire ; une paire valide sera générée à partir de celui-ci momentanément sur la base des procédures de la section 7.1.3.2.2. Si un agent souhaite apparier le candidat réflexif pair avec d'autres candidats distants en plus de celui de la paire valide qui sera générée, l'agent MAY générer une offre mise à jour qui inclut le candidat réflexif pair. Cela entraînera son appariement avec tous les autres candidats distants.

7.1.3.2.2. Constructing a Valid Pair (Construction d'une paire valide)

L'agent construit une paire de candidats dont le candidat local est égal à l'adresse mappée de la réponse, et dont le candidat distant est égal à l'adresse de destination à laquelle la requête a été envoyée. C'est ce qu'on appelle une paire valide, car elle a été validée par une vérification de connectivité STUN. La paire valide peut être égale à la paire qui a généré la vérification, peut être égale à une paire différente dans la liste de vérification, ou peut être une paire qui n'est actuellement sur aucune liste de vérification. Si la paire est égale à la paire qui a généré la vérification ou est sur une liste de vérification actuellement, elle est également ajoutée à la VALID LIST, qui est maintenue par l'agent pour chaque flux média. Cette liste est vide au début du traitement ICE, et se remplit à mesure que les vérifications sont effectuées, résultant en des paires de candidats valides.

Il sera très courant que la paire ne soit sur aucune liste de vérification. Rappelons que la liste de vérification contient des paires dont les candidats locaux ne sont jamais réflexifs serveur ; ces paires ont vu leurs candidats locaux convertis à la base des candidats réflexifs serveur, puis élagués s'ils étaient redondants. Lorsque la réponse à la vérification STUN arrive, l'adresse mappée sera réflexive s'il y a un NAT entre les deux. Dans ce cas, la paire valide aura un candidat local qui ne correspond à aucune des paires de la liste de vérification.

Si la paire n'est sur aucune liste de vérification, l'agent calcule la priorité de la paire sur la base de la priorité de chaque candidat, en utilisant l'algorithme de la section 5.7. La priorité du candidat local dépend de son type. S'il n'est pas réflexif pair, il est égal à la priorité signalée pour ce candidat dans le SDP. S'il est réflexif pair, il est égal à l'attribut PRIORITY que l'agent a placé dans la requête Binding qui vient de se terminer. La priorité du candidat distant est tirée du SDP du pair. Si le candidat n'y apparaît pas, alors la vérification doit avoir été une vérification déclenchée vers un nouveau candidat distant. Dans ce cas, la priorité est prise comme la valeur de l'attribut PRIORITY dans la requête Binding qui a déclenché la vérification qui vient de se terminer. La paire est ensuite ajoutée à la VALID LIST.

7.1.3.2.3. Updating Pair States (Mise à jour des états des paires)

L'agent définit l'état de la paire qui a généré la vérification sur Succeeded. Notez que la paire qui a généré la vérification peut être différente de la paire valide construite dans la section 7.1.3.2.2 à la suite de la réponse. Le succès de cette vérification peut également entraîner le changement d'état d'autres vérifications. L'agent MUST effectuer les deux étapes suivantes :

1. L'agent change les états pour toutes les autres paires Frozen pour le même flux média et la même fondation en Waiting. Typiquement, mais pas toujours, ces autres paires auront des ID de composants différents.

2. S'il y a une paire dans la liste valide pour chaque composant de ce flux média (où c'est le nombre réel de composants utilisés, dans les cas où le nombre de composants signalés dans le SDP diffère de l'offrant au répondeur), le succès de cette vérification peut dégeler les vérifications pour d'autres flux média. Notez que cette étape est suivie non seulement la première fois que la liste valide considérée a une paire pour chaque composant, mais chaque fois qu'une vérification réussit et ajoute encore une autre paire à cette liste valide. L'agent examine la liste de vérification pour chaque autre flux média tour à tour :

   • Si la liste de vérification est active, l'agent change l'état de toutes les paires Frozen dans cette liste de vérification dont la fondation correspond à une paire dans la liste valide considérée en Waiting.

   • Si la liste de vérification est gelée, et qu'il y a au moins une paire dans la liste de vérification dont la fondation correspond à une paire dans la liste valide considérée, l'état de toutes les paires dans la liste de vérification dont la fondation correspond à une paire dans la liste valide considérée est défini sur Waiting. Cela entraînera l'activation de la liste de vérification, et les vérifications ordinaires commenceront pour elle, comme décrit dans la section 5.8.

   • Si la liste de vérification est gelée, et qu'il n'y a pas de paires dans la liste de vérification dont la fondation correspond à une paire dans la liste valide considérée, l'agent

     • regroupe toutes les paires avec la même fondation, et

     • pour chaque groupe, définit l'état de la paire avec l'ID de composant le plus bas sur Waiting. S'il y a plus d'une telle paire, celle avec la priorité la plus élevée est utilisée.

7.1.3.2.4. Updating the Nominated Flag (Mise à jour du drapeau nommé)

Si l'agent était un agent contrôlant, et qu'il avait inclus un attribut USE-CANDIDATE dans la requête Binding, la paire valide générée à partir de cette vérification a son drapeau nommé défini sur true. Ce drapeau indique que cette paire valide doit être utilisée pour le média si elle est la plus prioritaire parmi celles dont le drapeau nommé est défini. Cela peut conclure le traitement ICE pour ce flux média ou tous les flux média ; voir la section 8.

Si l'agent est l'agent contrôlé, la réponse peut être le résultat d'une vérification déclenchée qui a été envoyée en réponse à une requête qui avait elle-même l'attribut USE-CANDIDATE. Ce cas est décrit dans la section 7.2.1.5, et peut maintenant entraîner la définition du drapeau nommé pour la paire apprise à partir de la requête originale.

7.1.3.3. Check List and Timer State Updates (Mises à jour de la liste de vérification et de l'état du minuteur)

Que la vérification ait réussi ou échoué, l'achèvement de la transaction peut nécessiter la mise à jour des états de la liste de vérification et du minuteur.

Si toutes les paires dans la liste de vérification sont maintenant dans l'état Failed ou Succeeded :

• S'il n'y a pas de paire dans la liste valide pour chaque composant du flux média, l'état de la liste de vérification est défini sur Failed.

• Pour chaque liste de vérification gelée, l'agent

  • regroupe toutes les paires avec la même fondation, et

  • pour chaque groupe, définit l'état de la paire avec l'ID de composant le plus bas sur Waiting. S'il y a plus d'une telle paire, celle avec la priorité la plus élevée est utilisée.

Si aucune des paires dans la liste de vérification n'est dans l'état Waiting ou Frozen, la liste de vérification n'est plus considérée comme active, et ne comptera pas pour la valeur de N dans le calcul des minuteurs pour les vérifications ordinaires comme décrit dans la section 5.8.

7.2. STUN Server Procedures (Procédures serveur STUN)

Un agent MUST être prêt à recevoir une requête Binding sur la base de chaque candidat qu'il a inclus dans son offre ou sa réponse la plus récente. Cette exigence tient même si le pair est une implémentation Lite.

L'agent MUST utiliser des informations d'identification à court terme pour authentifier la requête et effectuer une vérification de l'intégrité du message. L'agent MUST considérer le nom d'utilisateur comme valide s'il se compose de deux valeurs séparées par un deux-points, où la première valeur est égale au fragment de nom d'utilisateur généré par l'agent dans une offre ou une réponse pour une session en cours. Il est possible (et en fait très probable) qu'un offrant reçoive une requête Binding avant de recevoir la réponse de son pair. Si cela se produit, l'agent MUST générer immédiatement une réponse (y compris le calcul de l'adresse mappée comme décrit dans la section 7.2.1.2). L'agent dispose d'informations suffisantes à ce stade pour générer la réponse ; le mot de passe du pair n'est pas requis. Une fois la réponse reçue, il MUST procéder aux étapes restantes requises, à savoir 7.2.1.3, 7.2.1.4 et 7.2.1.5 pour les implémentations complètes. Dans les cas où plusieurs requêtes STUN sont reçues avant la réponse, cela peut entraîner la mise en file d'attente de plusieurs paires dans la file d'attente des vérifications déclenchées.

Un agent MUST NOT utiliser le mécanisme ALTERNATE-SERVER, et MUST NOT prendre en charge les mécanismes de rétrocompatibilité avec la RFC 3489. Il MUST utiliser le mécanisme FINGERPRINT.

Si l'agent utilise des marquages Diffserv Codepoint [RFC2475] dans ses paquets média, il SHOULD appliquer ces mêmes marquages à ses réponses aux requêtes Binding. La même chose s'appliquerait à tout marquage de couche 2 que le point de terminaison pourrait appliquer aux paquets média.

7.2.1. Additional Procedures for Full Implementations (Procédures supplémentaires pour les implémentations complètes)

Cette sous-section définit les procédures serveur supplémentaires applicables aux implémentations complètes.

7.2.1.1. Detecting and Repairing Role Conflicts (Détection et réparation des conflits de rôles)

Normalement, les règles de sélection d'un rôle dans la section 5.2 entraîneront la sélection d'un rôle différent par chaque agent -- un contrôlant et un contrôlé. Cependant, dans des flux d'appels inhabituels, utilisant généralement un contrôle d'appel tiers, il est possible que les deux agents sélectionnent le même rôle. Cette section décrit les procédures pour vérifier ce cas et le réparer.

Un agent MUST examiner la requête Binding pour l'attribut ICE-CONTROLLING ou ICE-CONTROLLED. Il MUST suivre ces procédures :

• Si ni ICE-CONTROLLING ni ICE-CONTROLLED n'est présent dans la requête, l'agent pair peut avoir implémenté une version précédente de cette spécification. Il peut y avoir un conflit, mais il ne peut pas être détecté.

• Si l'agent est dans le rôle contrôlant, et que l'attribut ICE-CONTROLLING est présent dans la requête :

  • Si le tie-breaker de l'agent est supérieur ou égal au contenu de l'attribut ICE-CONTROLLING, l'agent génère une réponse d'erreur Binding et inclut un attribut ERROR-CODE avec une valeur de 487 (Role Conflict) mais conserve son rôle.

  • Si le tie-breaker de l'agent est inférieur au contenu de l'attribut ICE-CONTROLLING, l'agent passe au rôle contrôlé.

• Si l'agent est dans le rôle contrôlé, et que l'attribut ICE-CONTROLLED est présent dans la requête :

  • Si le tie-breaker de l'agent est supérieur ou égal au contenu de l'attribut ICE-CONTROLLED, l'agent passe au rôle contrôlant.

  • Si le tie-breaker de l'agent est inférieur au contenu de l'attribut ICE-CONTROLLED, l'agent génère une réponse d'erreur Binding et inclut un attribut ERROR-CODE avec une valeur de 487 (Role Conflict) mais conserve son rôle.

• Si l'agent est dans le rôle contrôlé et que l'attribut ICE-CONTROLLING était présent dans la requête, ou si l'agent était dans le rôle contrôlant et que l'attribut ICE-CONTROLLED était présent dans la requête, il n'y a pas de conflit.

Un changement de rôle nécessitera qu'un agent recalcule les priorités des paires (Section 5.7.2), car ces priorités sont fonction des rôles contrôlant et contrôlé. Le changement de rôle aura également un impact sur la question de savoir si l'agent est responsable de la sélection des paires nommées et de la génération d'offres mises à jour à la conclusion d'ICE.

Les sections restantes de la section 7.2.1 sont suivies si le serveur a généré une réponse positive à la requête Binding, même si l'agent a changé de rôle.

7.2.1.2. Computing Mapped Address (Calcul de l'adresse mappée)

Pour les requêtes reçues sur un candidat relayé, l'adresse de transport source utilisée pour le traitement STUN (à savoir, la génération de l'attribut XOR-MAPPED-ADDRESS) est l'adresse de transport vue par le serveur TURN. Cette adresse de transport source sera présente dans l'attribut XOR-PEER-ADDRESS d'un message Data Indication, si la requête Binding a été livrée via un Data Indication. Si la requête Binding a été livrée via un message ChannelData, l'adresse de transport source est celle qui a été liée au canal.

7.2.1.3. Learning Peer Reflexive Candidates (Apprentissage des candidats réflexifs pairs)

Si l'adresse de transport source de la requête ne correspond à aucun candidat distant existant, elle représente un nouveau candidat distant réflexif pair. Ce candidat est construit comme suit :

• La priorité du candidat est définie sur l'attribut PRIORITY de la requête.
• Le type du candidat est défini sur réflexif pair.
• La fondation du candidat est définie sur une valeur arbitraire, différente de la fondation de tous les autres candidats distants. Si des échanges offre/réponse ultérieurs contiennent ce candidat réflexif pair dans le SDP, cela signalera la fondation réelle pour le candidat.
• L'ID de composant de ce candidat est défini sur l'ID de composant pour le candidat local auquel la requête a été envoyée.

Ce candidat est ajouté à la liste des candidats distants. Cependant, l'agent n'apparie pas ce candidat avec des candidats locaux.

7.2.1.4. Triggered Checks (Vérifications déclenchées)

Ensuite, l'agent construit une paire dont le candidat local est égal à l'adresse de transport sur laquelle la requête STUN a été reçue, et un candidat distant égal à l'adresse de transport source d'où provenait la requête (qui peut être le candidat distant réflexif pair qui vient d'être appris). Le candidat local sera soit un candidat hôte (pour les cas où la requête n'a pas été reçue via un relais) soit un candidat relayé (pour les cas où elle est reçue via un relais). Le candidat local ne peut jamais être un candidat réflexif serveur. Comme les deux candidats sont connus de l'agent, il peut obtenir leurs priorités et calculer la priorité de la paire de candidats. Cette paire est ensuite recherchée dans la liste de vérification. Il peut y avoir l'un des résultats suivants :

• Si la paire est déjà sur la liste de vérification :

  • Si l'état de cette paire est Waiting ou Frozen, une vérification pour cette paire est mise en file d'attente dans la file d'attente des vérifications déclenchées si elle n'est pas déjà présente.

  • Si l'état de cette paire est In-Progress, l'agent annule la transaction en cours. L'annulation signifie que l'agent ne retransmettra pas la requête, ne traitera pas l'absence de réponse comme un échec, mais attendra la durée du délai d'expiration de la transaction pour une réponse. De plus, l'agent MUST créer une nouvelle vérification de connectivité pour cette paire (représentant une nouvelle transaction de requête Binding STUN) en mettant la paire en file d'attente dans la file d'attente des vérifications déclenchées. L'état de la paire est ensuite changé en Waiting.

  • Si l'état de la paire est Failed, il est changé en Waiting et l'agent MUST créer une nouvelle vérification de connectivité pour cette paire (représentant une nouvelle transaction de requête Binding STUN), en mettant la paire en file d'attente dans la file d'attente des vérifications déclenchées.

  • Si l'état de cette paire est Succeeded, rien de plus n'est fait.

  Ces étapes sont effectuées pour faciliter l'achèvement rapide d'ICE lorsque les deux agents sont derrière un NAT.

• Si la paire n'est pas déjà sur la liste de vérification :

  • La paire est insérée dans la liste de vérification en fonction de sa priorité.

  • Son état est défini sur Waiting.

  • La paire est mise en file d'attente dans la file d'attente des vérifications déclenchées.

Lorsqu'une vérification déclenchée doit être envoyée, elle est construite et traitée comme décrit dans la section 7.1.2. Ces procédures exigent que l'agent connaisse l'adresse de transport, le fragment de nom d'utilisateur et le mot de passe pour le pair. Le fragment de nom d'utilisateur pour le candidat distant est égal à la partie après le deux-points du USERNAME dans la requête Binding qui vient d'être reçue. En utilisant ce fragment de nom d'utilisateur, l'agent peut vérifier les messages SDP reçus de son pair (il peut y en avoir plus d'un en cas de bifurcation), et trouver ce fragment de nom d'utilisateur. Le mot de passe correspondant est ensuite sélectionné.

7.2.1.5. Updating the Nominated Flag (Mise à jour du drapeau nommé)

Si la requête Binding reçue par l'agent avait l'attribut USE-CANDIDATE défini, et que l'agent est dans le rôle contrôlé, l'agent regarde l'état de la paire calculée dans la section 7.2.1.4 :

• Si l'état de cette paire est Succeeded, cela signifie que la vérification générée par cette paire a produit une réponse positive. Cela aurait amené l'agent à construire une paire valide lorsque cette réponse positive a été reçue (voir la section 7.1.3.2.2). L'agent définit maintenant le drapeau nommé dans la paire valide sur true. Cela peut mettre fin au traitement ICE pour ce flux média ; voir la section 8.

• Si l'état de cette paire est In-Progress, si sa vérification produit un résultat positif, la paire valide résultante a son drapeau nommé défini lorsque la réponse arrive. Cela peut mettre fin au traitement ICE pour ce flux média lorsqu'elle arrive ; voir la section 8.

7.2.2. Additional Procedures for Lite Implementations (Procédures supplémentaires pour les implémentations Lite)

Si la vérification qui vient d'être reçue contenait un attribut USE-CANDIDATE, l'agent construit une paire de candidats dont le candidat local est égal à l'adresse de transport sur laquelle la requête a été reçue, et dont le candidat distant est égal à l'adresse de transport source de la requête qui a été reçue. Cette paire de candidats se voit attribuer une priorité arbitraire, et est placée dans une liste de candidats valides appelée la liste valide. L'agent définit le drapeau nommé pour cette paire sur true. Le traitement ICE est considéré comme terminé pour un flux média si la liste valide contient une paire de candidats pour chaque composant.