9. Subsequent Offer/Answer Exchanges (Échanges d'offre/réponse ultérieurs)

L'un ou l'autre des agents MAY générer une offre ultérieure à tout moment autorisé par la RFC 3264 [RFC3264]. Les règles de la section 8 amèneront l'agent contrôlant à envoyer une offre mise à jour à la conclusion du traitement ICE lorsque ICE a sélectionné des paires de candidats différentes des paires par défaut. Cette section définit les règles pour la construction des offres et réponses ultérieures.

Si une offre ultérieure est rejetée, le traitement ICE continue comme si l'offre ultérieure n'avait jamais été faite.

9.1. Generating the Offer (Génération de l'offre)

9.1.1. Procedures for All Implementations (Procédures pour toutes les implémentations)

9.1.1.1. ICE Restarts (Redémarrages ICE)

Un agent MAY redémarrer le traitement ICE pour un flux média existant. Un redémarrage ICE, comme son nom l'indique, entraînera la purge de tous les états précédents du traitement ICE et le redémarrage des vérifications. La seule différence entre un redémarrage ICE et une toute nouvelle session média est que, pendant le redémarrage, le média peut continuer à être envoyé à la paire précédemment validée.

Un agent MUST redémarrer ICE pour un flux média si :

• L'offre est générée dans le but de changer la cible du flux média. En d'autres termes, si un agent souhaite générer une offre mise à jour qui, si ICE n'avait pas été utilisé, entraînerait une nouvelle valeur pour la destination d'un composant média.

• Un agent change son niveau d'implémentation. Cela ne se produit généralement que dans les cas d'utilisation de contrôle d'appel tiers, où l'entité effectuant la signalisation n'est pas l'entité recevant le média, et elle a changé la cible du média en cours de session pour une autre entité qui a une implémentation ICE différente.

Ces règles impliquent que le réglage de l'adresse IP dans la ligne c à 0.0.0.0 entraînera un redémarrage ICE. Par conséquent, les implémentations ICE MUST NOT utiliser ce mécanisme pour la mise en attente d'appel, et MUST utiliser à la place a=inactive et a=sendonly comme décrit dans [RFC3264].

Pour redémarrer ICE, un agent MUST changer à la fois ice-pwd et ice-ufrag pour le flux média dans une offre. Notez qu'il est permis d'utiliser un attribut au niveau de la session dans une offre, mais de fournir le même ice-pwd ou ice-ufrag comme attribut au niveau du média dans une offre ultérieure. Ce n'est pas un changement de mot de passe, juste un changement dans sa représentation, et ne provoque pas un redémarrage ICE.

Un agent définit le reste des champs dans le SDP pour ce flux média comme il le ferait dans une offre initiale de ce flux média (voir la section 4.3). Par conséquent, l'ensemble des candidats MAY inclure certains, aucun ou tous les candidats précédents pour ce flux et MAY inclure un ensemble totalement nouveau de candidats rassemblés comme décrit dans la section 4.1.1.

9.1.1.2. Removing a Media Stream (Suppression d'un flux média)

Si un agent supprime un flux média en réglant son port à zéro, il MUST NOT inclure d'attributs de candidat pour ce flux média et SHOULD NOT inclure d'autres attributs liés à ICE définis dans la section 15 pour ce flux média.

9.1.1.3. Adding a Media Stream (Ajout d'un flux média)

Si un agent souhaite ajouter un nouveau flux média, il définit les champs dans le SDP pour ce flux média comme s'il s'agissait d'une offre initiale pour ce flux média (voir la section 4.3). Cela entraînera le début du traitement ICE pour ce flux média.

9.1.2. Procedures for Full Implementations (Procédures pour les implémentations complètes)

Cette section décrit des procédures supplémentaires pour les implémentations complètes, couvrant les flux média existants.

Les fragments de nom d'utilisateur, le mot de passe et le niveau d'implémentation MUST rester les mêmes que ceux utilisés précédemment. Si un agent doit changer l'un d'eux, il MUST redémarrer ICE pour ce flux média.

Le comportement supplémentaire dépend de l'état du traitement ICE pour ce flux média.

9.1.2.1. Existing Media Streams with ICE Running (Flux média existants avec ICE en cours d'exécution)

Si un agent génère une offre mise à jour incluant un flux média qui a été précédemment établi, et pour lequel les vérifications ICE sont dans l'état Running, l'agent suit les procédures définies ici.

Un agent MUST inclure des attributs de candidat pour tous les candidats locaux qu'il avait signalés précédemment pour ce flux média. Les propriétés de ce candidat telles que signalées dans le SDP -- la priorité, la fondation, le type et l'adresse de transport associée -- SHOULD rester les mêmes. L'adresse IP, le port et le protocole de transport, qui identifient fondamentalement ce candidat, MUST rester les mêmes (s'ils changent, ce serait un nouveau candidat). L'ID de composant MUST rester le même. L'agent MAY inclure des candidats supplémentaires qu'il n'avait pas offerts précédemment, mais qu'il a rassemblés depuis le dernier échange d'offre/réponse, y compris les candidats réflexifs pairs.

L'agent MAY changer la destination par défaut pour le média. Comme pour les offres initiales, il MUST y avoir un ensemble d'attributs de candidat dans l'offre correspondant à cette destination par défaut.

9.1.2.2. Existing Media Streams with ICE Completed (Flux média existants avec ICE terminé)

Si un agent génère une offre mise à jour incluant un flux média qui a été précédemment établi, et pour lequel les vérifications ICE sont dans l'état Completed, l'agent suit les procédures définies ici.

La destination par défaut pour le média (c'est-à-dire les valeurs des adresses IP et des ports dans les lignes m et c utilisées pour ce flux média) MUST être le candidat local de la paire nommée la plus prioritaire dans la liste valide pour chaque composant. Cela "fixe" la destination par défaut pour le média pour qu'elle soit égale à la destination qu'ICE a sélectionnée pour le média.

L'agent MUST inclure des attributs de candidat pour les candidats correspondant à la destination par défaut pour chaque composant du flux média, et MUST NOT inclure d'autres candidats.

De plus, si l'agent est contrôlant, il MUST inclure l'attribut a=remote-candidates pour chaque flux média dont la liste de vérification est dans l'état Completed. L'attribut contient les candidats distants de la paire nommée la plus prioritaire dans la liste valide pour chaque composant de ce flux média. Il est nécessaire pour éviter une condition de concurrence par laquelle l'agent contrôlant choisit ses paires, mais l'offre mise à jour arrive avant les vérifications de connectivité à l'agent contrôlé, qui ne sait même pas que ces paires sont valides, et encore moins sélectionnées. Voir l'annexe B.6 pour plus de détails sur cette condition de concurrence.

9.1.3. Procedures for Lite Implementations (Procédures pour les implémentations Lite)

9.1.3.1. Existing Media Streams with ICE Running (Flux média existants avec ICE en cours d'exécution)

Cette section décrit les procédures pour les implémentations Lite pour les flux existants pour lesquels ICE est en cours d'exécution.

Une implémentation Lite MUST inclure tous ses candidats pour chaque composant de chaque flux média dans un attribut a=candidate dans toute offre ultérieure. Ces candidats sont formés de manière identique aux procédures pour les offres initiales, comme décrit dans la section 4.2.

Une implémentation Lite MUST NOT ajouter de candidats hôtes supplémentaires dans une offre ultérieure. Si un agent doit offrir des candidats supplémentaires, il MUST redémarrer ICE.

Les fragments de nom d'utilisateur, le mot de passe et le niveau d'implémentation MUST rester les mêmes que ceux utilisés précédemment. Si un agent doit changer l'un d'eux, il MUST redémarrer ICE pour ce flux média.

9.1.3.2. Existing Media Streams with ICE Completed (Flux média existants avec ICE terminé)

Si ICE est terminé pour un flux média, la destination par défaut pour ce flux média MUST être définie sur le candidat distant de la paire de candidats pour ce composant dans la liste valide. Pour une implémentation Lite, il y a toujours juste une seule paire de candidats dans la liste valide pour chaque composant d'un flux média. De plus, l'agent MUST inclure un attribut de candidat pour chaque destination par défaut.

De plus, si l'agent est contrôlant (ce qui ne se produit que lorsque les deux agents sont Lite), l'agent MUST inclure l'attribut a=remote-candidates pour chaque flux média. L'attribut contient les candidats distants des paires de candidats dans la liste valide (une paire pour chaque composant de chaque flux média).

9.2. Receiving the Offer and Generating an Answer (Réception de l'offre et génération d'une réponse)

9.2.1. Procedures for All Implementations (Procédures pour toutes les implémentations)

Lors de la réception d'une offre ultérieure au sein d'une session existante, un agent MUST réappliquer les procédures de vérification de la section 5.1 sans tenir compte des résultats de la vérification de tout échange d'offre/réponse précédent. En effet, il est possible qu'un échange d'offre/réponse précédent ait abouti à ce qu'ICE ne soit pas utilisé, mais qu'il soit utilisé à la suite d'un échange ultérieur.

9.2.1.1. Detecting ICE Restart (Détection du redémarrage ICE)

Si l'offre contenait un changement dans les attributs a=ice-ufrag ou a=ice-pwd par rapport au SDP précédent du pair, cela indique qu'ICE redémarre pour ce flux média. Si tous les flux média redémarrent, alors ICE redémarre globalement.

Si ICE redémarre pour un flux média :

• L'agent MUST changer les attributs a=ice-ufrag et a=ice-pwd dans la réponse.

• L'agent MAY changer son niveau d'implémentation dans la réponse.

Un agent définit le reste des champs dans le SDP pour ce flux média comme il le ferait dans une réponse initiale à ce flux média (voir la section 4.3). Par conséquent, l'ensemble des candidats MAY inclure certains, aucun ou tous les candidats précédents pour ce flux et MAY inclure un ensemble totalement nouveau de candidats rassemblés comme décrit dans la section 4.1.1.

9.2.1.2. New Media Stream (Nouveau flux média)

Si l'offre contient un nouveau flux média, l'agent définit les champs dans la réponse comme s'il avait reçu une offre initiale contenant ce flux média (voir la section 4.3). Cela entraînera le début du traitement ICE pour ce flux média.

9.2.1.3. Removed Media Stream (Flux média supprimé)

Si une offre contient un flux média dont le port est zéro, l'agent MUST NOT inclure d'attributs de candidat pour ce flux média dans sa réponse et SHOULD NOT inclure d'autres attributs liés à ICE définis dans la section 15 pour ce flux média.

9.2.2. Procedures for Full Implementations (Procédures pour les implémentations complètes)

À moins que l'agent n'ait détecté un redémarrage ICE à partir de l'offre, les fragments de nom d'utilisateur, le mot de passe et le niveau d'implémentation MUST rester les mêmes que ceux utilisés précédemment. Si un agent doit changer l'un d'eux, il MUST redémarrer ICE pour ce flux média en générant une offre ; ICE ne peut pas être redémarré dans une réponse.

Les comportements supplémentaires dépendent de l'état du traitement ICE pour ce flux média.

9.2.2.1. Existing Media Streams with ICE Running and no remote-candidates (Flux média existants avec ICE en cours d'exécution et pas de remote-candidates)

Si ICE est en cours d'exécution pour un flux média, et que l'offre pour ce flux média manquait de l'attribut remote-candidates, les règles de construction de la réponse sont identiques à celles de l'offrant décrites dans la section 9.1.2.1.

9.2.2.2. Existing Media Streams with ICE Completed and no remote-candidates (Flux média existants avec ICE terminé et pas de remote-candidates)

Si ICE est terminé pour un flux média, et que l'offre pour ce flux média manquait de l'attribut remote-candidates, les règles de construction de la réponse sont identiques à celles de l'offrant décrites dans la section 9.1.2.2, sauf que le répondeur MUST NOT inclure l'attribut a=remote-candidates dans la réponse.

9.2.2.3. Existing Media Streams and remote-candidates (Flux média existants et remote-candidates)

Un agent contrôlé recevra une offre avec l'attribut a=remote-candidates pour un flux média lorsque son pair aura terminé le traitement ICE pour ce flux média. Cet attribut est présent dans l'offre pour faire face à une condition de concurrence entre la réception de l'offre et la réception de la réponse Binding qui indique au répondeur le candidat qui sera sélectionné par ICE. Voir l'annexe B.6 pour une explication de cette condition de concurrence. Par conséquent, le traitement d'une offre avec cet attribut dépend du gagnant de la course.

L'agent forme une paire de candidats pour chaque composant du flux média en :

• Réglant le candidat distant égal à la destination par défaut de l'offrant pour ce composant (par exemple, le contenu des lignes m et c pour RTP, et l'attribut a=rtcp pour RTCP)

• Réglant le candidat local égal à l'adresse de transport pour ce même composant dans l'attribut a=remote-candidates dans l'offre.

L'agent vérifie ensuite si chacune de ces paires de candidats est présente dans la liste valide. Si une paire particulière n'est pas dans la liste valide, la vérification a "perdu" la course. Appelez une telle paire une "paire perdante".

L'agent trouve toutes les paires dans la liste de vérification dont les candidats distants sont égaux au candidat distant dans la paire perdante :

• Si aucune des paires n'est In-Progress, et qu'au moins une est Failed, il est très probable qu'une défaillance du réseau, telle qu'une partition réseau ou une perte de paquets grave, se soit produite. L'agent SHOULD générer une réponse pour ce flux média comme si l'attribut remote-candidates n'avait pas été présent, puis redémarrer ICE pour ce flux.

• Si au moins une des paires est In-Progress, l'agent SHOULD attendre que ces vérifications se terminent, et à mesure que chacune se termine, refaire le traitement de cette section jusqu'à ce qu'il n'y ait plus de paires perdantes.

Une fois qu'il n'y a plus de paires perdantes, l'agent peut générer la réponse. Il MUST définir la destination par défaut pour le média sur les candidats de l'attribut remote-candidates de l'offre (chacun d'eux sera maintenant le candidat local d'une paire de candidats dans la liste valide). Il MUST inclure un attribut de candidat dans la réponse pour chaque candidat de l'attribut remote-candidates dans l'offre.

9.2.3. Procedures for Lite Implementations (Procédures pour les implémentations Lite)

Si l'offre reçue contient l'attribut remote-candidates pour un flux média, l'agent forme une paire de candidats pour chaque composant du flux média en :

• Réglant le candidat distant égal à la destination par défaut de l'offrant pour ce composant (par exemple, le contenu des lignes m et c pour RTP, et l'attribut a=rtcp pour RTCP).

• Réglant le candidat local égal à l'adresse de transport pour ce même composant dans l'attribut a=remote-candidates dans l'offre.

Il place ensuite ces candidats dans la liste Valide pour le flux média. L'état du traitement ICE pour ce flux média est défini sur Completed.

De plus, si l'agent croyait qu'il contrôlait, mais que l'offre contenait l'attribut remote-candidates, les deux agents croient qu'ils contrôlent. Dans ce cas, les deux auraient envoyé des offres mises à jour à peu près au même moment. Cependant, le protocole de signalisation transportant les échanges d'offre/réponse aura résolu cette condition d'éblouissement, de sorte qu'un agent est toujours le 'gagnant' en ayant son offre reçue avant que son pair n'ait envoyé une offre. Le gagnant prend le rôle de contrôlé, de sorte que le perdant (le répondeur considéré dans cette section) MUST changer son rôle en contrôlé. Par conséquent, si l'agent allait envoyer une offre mise à jour puisque, sur la base des règles de la section 8.2.2, il contrôlait, il n'a plus besoin de le faire.

Outre le changement de rôle potentiel, le changement dans la liste Valide et les changements d'état, la construction de la réponse est effectuée de manière identique à la construction d'une offre comme décrit dans la section 9.1.3.

9.3. Updating the Check and Valid Lists (Mise à jour des listes de vérification et valide)

9.3.1. Procedures for Full Implementations (Procédures pour les implémentations complètes)

9.3.1.1. ICE Restarts (Redémarrages ICE)

L'agent MUST se souvenir des paires nommées les plus prioritaires dans la liste Valide pour chaque composant du flux média, appelées paires sélectionnées précédentes, avant le redémarrage. L'agent continuera d'envoyer le média en utilisant ces paires, comme décrit dans la section 11.1. Une fois ces destinations notées, l'agent MUST purger les listes valide et de vérification, puis recalculer la liste de vérification et ses états comme décrit dans la section 5.7.

9.3.1.2. New Media Stream (Nouveau flux média)

Si l'échange d'offre/réponse a ajouté un nouveau flux média, l'agent MUST créer une nouvelle liste de vérification pour celui-ci (et une liste Valide vide pour commencer bien sûr), comme décrit dans la section 5.7.

9.3.1.3. Removed Media Stream (Flux média supprimé)

Si l'échange d'offre/réponse a supprimé un flux média, ou qu'une réponse a rejeté un flux média offert, un agent MUST purger la liste Valide pour ce flux média. Il MUST terminer toutes les transactions STUN en cours pour ce flux média. Un agent MUST supprimer la liste de vérification pour ce flux média et annuler toutes les vérifications ordinaires en attente pour celui-ci.

9.3.1.4. ICE Continuing for Existing Media Stream (ICE continuant pour un flux média existant)

La liste valide n'est pas affectée par un échange d'offre/réponse mis à jour à moins qu'ICE ne redémarre.

Si un agent est dans l'état Running pour ce flux média, la liste de vérification est mise à jour (la liste de vérification n'est pas pertinente si l'état est terminé). Pour ce faire, l'agent recalcule la liste de vérification en utilisant les procédures décrites dans la section 5.7. Si une paire sur la nouvelle liste de vérification était également sur la liste de vérification précédente, et que son état était Waiting, In-Progress, Succeeded ou Failed, son état est copié. Sinon, son état est défini sur Frozen.

Si aucune des listes de vérification n'est active (ce qui signifie que les paires dans chaque liste de vérification sont Frozen), l'agent en mode complet définit la première paire dans la liste de vérification pour le premier flux média sur Waiting, puis définit l'état de toutes les autres paires dans cette liste de vérification pour le même ID de composant et avec la même fondation sur Waiting également.

Ensuite, l'agent parcourt chaque liste de vérification, en commençant par la paire la plus prioritaire. Si une paire a un état Succeeded, et qu'elle a un ID de composant de 1, alors toutes les paires Frozen dans la même liste de vérification avec la même fondation dont les ID de composant ne sont pas 1 ont leur état défini sur Waiting. Si, pour une liste de vérification particulière, il y a des paires pour chaque composant de ce flux média dans l'état Succeeded, l'agent déplace l'état de toutes les paires Frozen pour le premier composant de tous les autres flux média (et donc dans différentes listes de vérification) avec la même fondation vers Waiting.

9.3.2. Procedures for Lite Implementations (Procédures pour les implémentations Lite)

Si ICE redémarre pour un flux média, l'agent MUST démarrer une nouvelle liste Valide pour ce flux média. Il MUST se souvenir des paires dans la liste Valide précédente pour chaque composant du flux média, appelées paires sélectionnées précédentes, et continuer à y envoyer le média comme décrit dans la section 11.1. L'état du traitement ICE pour chaque flux média MUST passer à Running, et l'état du traitement ICE MUST passer à Running.