Aller au contenu principal

4. Sending the Initial Offer (Envoi de l'offre initiale)

Afin d'envoyer l'offre initiale dans un échange offre/réponse, un agent doit (1) collecter des candidats, (2) les classer par priorité, (3) éliminer les candidats redondants, (4) choisir des candidats par défaut, puis (5) formuler et envoyer l'offre SDP. Toutes ces cinq étapes, sauf la dernière, diffèrent pour les implémentations complètes et légères.

4.1. Full Implementation Requirements (Exigences de l'implémentation complète)​

4.1.1. Gathering Candidates (Collecte des candidats)​

Un agent collecte des candidats lorsqu'il pense que la communication est imminente. Un offrant peut le faire sur la base d'un signal de l'interface utilisateur, ou sur la base d'une demande explicite d'initier une session. Chaque candidat est une adresse de transport. Il a également un type et une base. Quatre types sont définis et collectés par cette spécification : les candidats hôtes, les candidats réflexifs serveur, les candidats réflexifs pair et les candidats relayés. Les candidats réflexifs serveur sont collectés à l'aide de STUN ou TURN, et les candidats relayés sont obtenus via TURN. Les candidats réflexifs pair sont obtenus dans les phases ultérieures d'ICE, en conséquence des vérifications de connectivité. La base d'un candidat est le candidat à partir duquel un agent doit envoyer lorsqu'il utilise ce candidat.

4.1.1.1. Host Candidates (Candidats hôtes)​

La première étape consiste à collecter des candidats hôtes. Les candidats hôtes sont obtenus en se liant à des ports (généralement éphémères) sur une adresse IP attachée à une interface (physique ou virtuelle, y compris les interfaces VPN) sur l'hôte.

Pour chaque flux média UDP que l'agent souhaite utiliser, l'agent SHOULD (devrait) obtenir un candidat pour chaque composant du flux média sur chaque adresse IP que l'hôte possède. Il obtient chaque candidat en se liant à un port UDP sur l'adresse IP spécifique. Un candidat hôte (et en fait chaque candidat) est toujours associé à un composant spécifique pour lequel il est un candidat. Chaque composant a un identifiant qui lui est attribué, appelé ID de composant. Pour les flux média basés sur RTP, le RTP lui-même a un ID de composant de 1, et RTCP un ID de composant de 2. Si un agent utilise RTCP, il MUST (doit) obtenir un candidat pour celui-ci. Si un agent utilise à la fois RTP et RTCP, il se retrouverait avec 2*K candidats hôtes si un agent a K adresses IP.

La base pour chaque candidat hôte est définie sur le candidat lui-même.

4.1.1.2. Server Reflexive and Relayed Candidates (Candidats réflexifs serveur et relayés)​

Les agents SHOULD (devraient) obtenir des candidats relayés et SHOULD (devraient) obtenir des candidats réflexifs serveur. Ces exigences sont de niveau SHOULD pour permettre la variation des fournisseurs. L'utilisation de serveurs STUN et TURN peut être inutile dans les réseaux fermés où les agents ne sont jamais connectés à l'Internet public ou à des points de terminaison en dehors du réseau fermé. Dans de tels cas, une implémentation complète serait utilisée pour les agents qui sont à double pile ou multihomés, pour sélectionner un candidat hôte. L'utilisation de serveurs TURN est coûteuse, et lorsque ICE est utilisé, ils ne seront utilisés que lorsque les deux points de terminaison sont derrière des NAT qui effectuent un mappage dépendant de l'adresse et du port. Par conséquent, certains déploiements pourraient considérer ce cas d'utilisation comme marginal et choisir de ne pas utiliser de serveurs TURN. Si un agent ne collecte pas de candidats réflexifs serveur ou relayés, il est RECOMMENDED (recommandé) que la fonctionnalité soit implémentée et simplement désactivée par la configuration, afin qu'elle puisse être réactivée par la configuration si les conditions changent à l'avenir.

Si un agent collecte à la fois des candidats relayés et réflexifs serveur, il utilise un serveur TURN. S'il ne collecte que des candidats réflexifs serveur, il utilise un serveur STUN.

L'agent associe ensuite chaque candidat hôte au serveur STUN ou TURN avec lequel il est configuré ou qu'il a découvert par un moyen quelconque. Si un serveur STUN ou TURN est configuré, il est RECOMMENDED (recommandé) qu'un nom de domaine soit configuré, et que les procédures DNS de la [RFC5389] (utilisant des enregistrements SRV avec le service "stun") soient utilisées pour découvrir le serveur STUN, et que les procédures DNS de la [RFC5766] (utilisant des enregistrements SRV avec le service "turn") soient utilisées pour découvrir le serveur TURN.

Cette spécification ne considère que l'utilisation d'un seul serveur STUN ou TURN. Lorsqu'il y a plusieurs choix pour ce serveur STUN ou TURN unique (lorsque, par exemple, ils sont appris via des enregistrements DNS et que plusieurs résultats sont renvoyés), un agent SHOULD (devrait) utiliser un seul serveur STUN ou TURN (basé sur son adresse IP) pour tous les candidats d'une session particulière. Cela améliore les performances d'ICE. Le résultat est un ensemble de paires de candidats hôtes avec des serveurs STUN ou TURN. L'agent choisit ensuite une paire et envoie une requête Binding ou Allocate au serveur à partir de ce candidat hôte. Les requêtes Binding vers un serveur STUN ne sont pas authentifiées, et tout attribut ALTERNATE-SERVER dans une réponse est ignoré. Les agents MUST (doivent) prendre en charge le mode de rétrocompatibilité pour la requête Binding défini dans la [RFC5389]. Les requêtes Allocate SHOULD (devraient) être authentifiées à l'aide d'un identifiant à long terme obtenu par le client par un autre moyen.

Toutes les Ta millisecondes par la suite, l'agent peut générer une autre nouvelle transaction STUN ou TURN. Cette transaction peut être soit une nouvelle tentative d'une transaction précédente qui a échoué avec une erreur récupérable (telle qu'un échec d'authentification), soit une transaction pour un nouveau candidat hôte et une paire de serveurs STUN ou TURN. L'agent SHOULD NOT (ne devrait pas) générer de transactions plus fréquemment qu'une toutes les Ta millisecondes. Voir la section 16 pour des conseils sur la façon de définir Ta et le temporisateur de retransmission STUN, RTO.

L'agent recevra une réponse Binding ou Allocate. Une réponse Allocate réussie fournira à l'agent un candidat réflexif serveur (obtenu à partir de l'adresse mappée) et un candidat relayé dans l'attribut XOR-RELAYED-ADDRESS. Si la requête Allocate est rejetée parce que le serveur manque de ressources pour la satisfaire, l'agent SHOULD (devrait) envoyer à la place une requête Binding pour obtenir un candidat réflexif serveur. Une réponse Binding fournira à l'agent uniquement un candidat réflexif serveur (également obtenu à partir de l'adresse mappée). La base du candidat réflexif serveur est le candidat hôte à partir duquel la requête Allocate ou Binding a été envoyée. La base d'un candidat relayé est ce candidat lui-même. Si un candidat relayé est identique à un candidat hôte (ce qui peut arriver dans de rares cas), le candidat relayé MUST (doit) être écarté.

4.1.1.3. Computing Foundations (Calcul des fondations)​

Enfin, l'agent attribue à chaque candidat une fondation. La fondation est un identifiant, dont la portée est limitée à une session. Deux candidats MUST (doivent) avoir le même ID de fondation lorsque toutes les conditions suivantes sont vraies :

  • ils sont du même type (hôte, relayé, réflexif serveur ou réflexif pair).
  • leurs bases ont la même adresse IP (les ports peuvent être différents).
  • pour les candidats réflexifs et relayés, les serveurs STUN ou TURN utilisés pour les obtenir ont la même adresse IP.
  • ils ont été obtenus en utilisant le même protocole de transport (TCP, UDP, etc.).

De même, deux candidats MUST (doivent) avoir des fondations différentes si leurs types sont différents, leurs bases ont des adresses IP différentes, les serveurs STUN ou TURN utilisés pour les obtenir ont des adresses IP différentes, ou leurs protocoles de transport sont différents.

4.1.1.4. Keeping Candidates Alive (Maintien des candidats en vie)​

Une fois que les candidats réflexifs serveur et relayés sont alloués, ils MUST (doivent) être maintenus en vie jusqu'à ce que le traitement ICE soit terminé, comme décrit dans la section 8.3. Pour les candidats réflexifs serveur appris via une requête Binding, les liaisons MUST (doivent) être maintenues en vie par des requêtes Binding supplémentaires au serveur. Les rafraîchissements pour les allocations sont effectués à l'aide de la transaction Refresh, comme décrit dans la [RFC5766]. Les requêtes Refresh rafraîchiront également le candidat réflexif serveur.

4.1.2. Prioritizing Candidates (Classement par priorité des candidats)​

Le processus de classement par priorité aboutit à l'attribution d'une priorité à chaque candidat. Chaque candidat pour un flux média MUST (doit) avoir une priorité unique qui MUST (doit) être un entier positif compris entre 1 et (2**31 - 1). Cette priorité sera utilisée par ICE pour déterminer l'ordre des vérifications de connectivité et la préférence relative pour les candidats.

Un agent SHOULD (devrait) calculer cette priorité en utilisant la formule de la section 4.1.2.1 et choisir ses paramètres en utilisant les directives de la section 4.1.2.2. Si un agent choisit d'utiliser une formule différente, ICE prendra plus de temps pour converger car les deux agents ne seront pas coordonnés dans leurs vérifications.

Lors de l'utilisation de la formule, un agent calcule la priorité en déterminant une préférence pour chaque type de candidat (réflexif serveur, réflexif pair, relayé et hôte), et, lorsque l'agent est multihomé, en choisissant une préférence pour ses adresses IP. Ces deux préférences sont ensuite combinées pour calculer la priorité d'un candidat. Cette priorité est calculée à l'aide de la formule suivante :

priority = (2^24)*(type preference) +
           (2^8)*(local preference) +
           (2^0)*(256 - component ID)

La préférence de type (type preference) MUST (doit) être un entier de 0 à 126 inclus, et représente la préférence pour le type du candidat (où les types sont local, réflexif serveur, réflexif pair et relayé). 126 est la préférence la plus élevée et 0 est la plus basse. Définir la valeur à 0 signifie que les candidats de ce type ne seront utilisés qu'en dernier recours. La préférence de type MUST (doit) être identique pour tous les candidats du même type et MUST (doit) être différente pour les candidats de types différents. La préférence de type pour les candidats réflexifs pair MUST (doit) être supérieure à celle des candidats réflexifs serveur. Notez que les candidats collectés sur la base des procédures de la section 4.1.1 ne seront jamais des candidats réflexifs pair ; les candidats de ce type sont appris à partir des vérifications de connectivité effectuées par ICE.

La préférence locale (local preference) MUST (doit) être un entier de 0 à 65535 inclus. Elle représente une préférence pour l'adresse IP particulière à partir de laquelle le candidat a été obtenu, dans les cas où un agent est multihomé. 65535 représente la préférence la plus élevée et zéro la plus basse. Lorsqu'il n'y a qu'une seule adresse IP, cette valeur SHOULD (devrait) être définie à 65535. Plus généralement, s'il existe plusieurs candidats pour un composant particulier d'un flux média particulier qui ont le même type, la préférence locale MUST (doit) être unique pour chacun d'eux. Dans cette spécification, cela ne se produit que pour les hôtes multihomés. Si un hôte est multihomé parce qu'il est à double pile, la préférence locale SHOULD (devrait) être définie égale à la valeur de priorité pour les adresses IP décrite dans la RFC 3484 [RFC3484].

L'ID de composant est l'ID de composant pour le candidat, et MUST (doit) être compris entre 1 et 256 inclus.

4.1.2.2. Guidelines for Choosing Type and Local Preferences (Directives pour choisir le type et les préférences locales)​

Un critère de sélection des valeurs de type et de préférence locale est l'utilisation d'un intermédiaire média, tel qu'un serveur TURN, un serveur VPN ou un NAT. Avec un intermédiaire média, si le média est envoyé à ce candidat, il transitera d'abord par l'intermédiaire média avant d'être reçu. Les candidats relayés sont un type de candidat qui implique un intermédiaire média. Un autre type sont les candidats hôtes obtenus à partir d'une interface VPN. Lorsque le média transite par un intermédiaire média, cela peut augmenter la latence entre la transmission et la réception. Cela peut augmenter les pertes de paquets, en raison des sauts de routeur supplémentaires qui peuvent être effectués. Cela peut augmenter le coût de la fourniture du service, car le média sera acheminé vers et depuis un intermédiaire média géré par un fournisseur. Si ces préoccupations sont importantes, la préférence de type pour les candidats relayés SHOULD (devrait) être inférieure à celle des candidats hôtes. Les valeurs RECOMMENDED (recommandées) sont 126 pour les candidats hôtes, 100 pour les candidats réflexifs serveur, 110 pour les candidats réflexifs pair et 0 pour les candidats relayés. De plus, si un agent est multihomé et possède plusieurs adresses IP, la préférence locale pour les candidats hôtes d'une interface VPN SHOULD (devrait) avoir une priorité de 0.

Un autre critère de sélection des préférences est la famille d'adresses IP. ICE fonctionne avec IPv4 et IPv6. Il fournit donc un mécanisme de transition qui permet aux hôtes à double pile de préférer la connectivité via IPv6, mais de se replier sur IPv4 au cas où les réseaux v6 seraient déconnectés (en raison, par exemple, d'une défaillance d'un relais 6to4) [RFC3056]. Il peut également aider les hôtes qui ont à la fois une adresse IPv6 native et une adresse 6to4. Dans un tel cas, des préférences locales plus élevées pourraient être attribuées aux adresses v6, suivies des adresses 6to4, suivies des adresses v4. Cela permet à un site d'obtenir et de commencer à utiliser immédiatement des adresses v6 natives, tout en pouvant se replier sur des adresses 6to4 lors de la communication avec des agents d'autres sites qui n'ont pas encore de connectivité v6 native.

Un autre critère de sélection des préférences est la sécurité. Si un utilisateur est un télétravailleur, et donc connecté à un réseau d'entreprise et à un réseau domestique local, l'utilisateur peut préférer que son trafic vocal soit acheminé via le VPN afin de le maintenir sur le réseau d'entreprise lors de la communication au sein de l'entreprise, mais utiliser le réseau local lors de la communication avec des utilisateurs en dehors de l'entreprise. Dans un tel cas, une adresse VPN aurait une préférence locale plus élevée que toute autre adresse.

Un autre critère de sélection des préférences est la connaissance topologique. Ceci est particulièrement utile pour les candidats qui utilisent des intermédiaires. Dans ces cas, si un agent a une connaissance préconfigurée ou découverte dynamiquement de la proximité topologique des intermédiaires par rapport à lui-même, il peut l'utiliser pour attribuer des préférences locales plus élevées aux candidats obtenus auprès d'intermédiaires plus proches.

4.1.3. Eliminating Redundant Candidates (Élimination des candidats redondants)​

Ensuite, l'agent élimine les candidats redondants. Un candidat est redondant si son adresse de transport est égale à un autre candidat et si sa base est égale à la base de cet autre candidat. Notez que deux candidats peuvent avoir la même adresse de transport tout en ayant des bases différentes, et ceux-ci ne seraient pas considérés comme redondants. Fréquemment, un candidat réflexif serveur et un candidat hôte seront redondants lorsque l'agent n'est pas derrière un NAT. L'agent SHOULD (devrait) éliminer le candidat redondant ayant la priorité la plus basse.

4.1.4. Choosing Default Candidates (Choix des candidats par défaut)​

Un candidat est dit par défaut s'il serait la cible du média d'un pair non-ICE ; cette cible est appelée DESTINATION PAR DÉFAUT (DEFAULT DESTINATION). Si les candidats par défaut ne sont pas sélectionnés par l'algorithme ICE lors de la communication avec un pair compatible ICE, une offre/réponse mise à jour sera nécessaire après la fin du traitement ICE afin de "corriger" le SDP pour que la destination par défaut du média corresponde aux candidats sélectionnés par ICE. Si ICE sélectionne par hasard les candidats par défaut, aucune offre/réponse mise à jour n'est requise.

Un agent MUST (doit) choisir un ensemble de candidats, un pour chaque composant de chaque flux média utilisé, pour être par défaut. Un flux média est utilisé s'il n'a pas de port zéro (qui est utilisé dans la RFC 3264 pour rejeter un flux média). Par conséquent, un flux média est utilisé même s'il est marqué comme a=inactive [RFC4566] ou a une valeur de bande passante de zéro.

Il est RECOMMENDED (recommandé) que les candidats par défaut soient choisis en fonction de la probabilité que ces candidats fonctionnent avec le pair contacté. Il est RECOMMENDED (recommandé) que les candidats par défaut soient les candidats relayés (si des candidats relayés sont disponibles), les candidats réflexifs serveur (si des candidats réflexifs serveur sont disponibles), et enfin les candidats hôtes.

4.2. Lite Implementation Requirements (Exigences de l'implémentation légère)​

Les implémentations légères utilisent uniquement des candidats hôtes. Une implémentation légère MUST (doit), pour chaque composant de chaque flux média, allouer zéro ou un candidat IPv4. Elle MAY (peut) allouer zéro ou plusieurs candidats IPv6, mais pas plus d'un par adresse IPv6 utilisée par l'hôte. Comme il ne peut y avoir plus d'un candidat IPv4 par composant de chaque flux média, si un agent possède plusieurs adresses IPv4, il MUST (doit) en choisir une pour allouer le candidat. Si un hôte est à double pile, il est RECOMMENDED (recommandé) qu'il alloue un candidat IPv4 et une adresse IPv6 globale. Avec l'implémentation légère, ICE ne peut pas être utilisé pour choisir dynamiquement parmi les candidats. Par conséquent, inclure plus d'un candidat d'une portée particulière n'est NOT RECOMMENDED (pas recommandé), car seule une vérification de connectivité peut vraiment déterminer s'il faut utiliser une adresse ou l'autre.

Chaque composant a un identifiant qui lui est attribué, appelé ID de composant. Pour les flux média basés sur RTP, le RTP lui-même a un ID de composant de 1, et RTCP un ID de composant de 2. Si un agent utilise RTCP, il MUST (doit) obtenir des candidats pour celui-ci.

Chaque candidat se voit attribuer une fondation. La fondation MUST (doit) être différente pour deux candidats alloués à partir d'adresses IP différentes, et MUST (doit) être la même sinon. Un simple entier qui s'incrémente pour chaque adresse IP suffira. De plus, chaque candidat MUST (doit) se voir attribuer une priorité unique parmi tous les candidats pour le même flux média. Cette priorité SHOULD (devrait) être égale à :

priority = (2^24)*(126) +
           (2^8)*(IP precedence) +
           (2^0)*(256 - component ID)

Si un hôte est v4 uniquement, il SHOULD (devrait) définir la priorité IP à 65535. Si un hôte est v6 ou à double pile, la priorité IP SHOULD (devrait) être la valeur de priorité pour les adresses IP décrite dans la RFC 3484 [RFC3484].

Ensuite, un agent choisit un candidat par défaut pour chaque composant de chaque flux média. Si un hôte est IPv4 uniquement, il n'y aurait qu'un seul candidat pour chaque composant de chaque flux média, et par conséquent ce candidat est le candidat par défaut. Si un hôte est IPv6 ou à double pile, la sélection du candidat par défaut est une question de politique locale. Ce candidat par défaut SHOULD (devrait) être choisi de manière à ce qu'il soit le candidat le plus susceptible d'être utilisé avec un pair. Pour les hôtes IPv6 uniquement, il s'agirait généralement d'une adresse IPv6 à portée globale. Pour les hôtes à double pile, l'adresse IPv4 est RECOMMENDED (recommandée).

4.3. Encoding the SDP (Encodage du SDP)​

Le processus d'encodage du SDP est identique entre les implémentations complètes et légères.

L'agent inclura une ligne m pour chaque flux média qu'il souhaite utiliser. L'ordre des flux média dans le SDP est pertinent pour ICE. ICE effectuera ses vérifications de connectivité pour la première ligne m en premier, et par conséquent le média pourra circuler pour ce flux en premier. Les agents SHOULD (devraient) placer leur flux média le plus important, s'il y en a un, en premier dans le SDP.

Il y aura un attribut candidat pour chaque candidat pour un flux média particulier. La section 15 fournit des règles détaillées pour la construction de cet attribut. L'attribut transporte l'adresse IP, le port et le protocole de transport pour le candidat, en plus de ses propriétés qui doivent être signalées au pair pour qu'ICE fonctionne : la priorité, la fondation et l'ID de composant. L'attribut candidat transporte également des informations sur le candidat qui sont utiles pour les diagnostics et d'autres fonctions : son type et les adresses de transport associées.

Les vérifications de connectivité STUN entre agents sont authentifiées à l'aide du mécanisme d'identification à court terme défini pour STUN [RFC5389]. Ce mécanisme repose sur un nom d'utilisateur et un mot de passe qui sont échangés via un mécanisme de protocole entre le client et le serveur. Avec ICE, l'échange offre/réponse est utilisé pour les échanger. La partie nom d'utilisateur de cet identifiant est formée en concaténant un fragment de nom d'utilisateur de chaque agent, séparé par deux points. Chaque agent fournit également un mot de passe, utilisé pour calculer l'intégrité du message pour les requêtes qu'il reçoit. Le fragment de nom d'utilisateur et le mot de passe sont échangés respectivement dans les attributs ice-ufrag et ice-pwd. En plus de fournir la sécurité, le nom d'utilisateur permet la désambiguïsation et la corrélation des vérifications avec les flux média. Voir l'annexe B.4 pour la motivation.

Si un agent est une implémentation légère, il MUST (doit) inclure un attribut de niveau session "a=ice-lite" dans son SDP. Si un agent est une implémentation complète, il MUST NOT (ne doit pas) inclure cet attribut.

Les candidats par défaut sont ajoutés au SDP comme destination par défaut pour le média. Pour les flux basés sur RTP, cela se fait en plaçant l'adresse IP et le port du candidat RTP dans les lignes c et m, respectivement. Si l'agent utilise RTCP, il MUST (doit) encoder le candidat RTCP à l'aide de l'attribut a=rtcp tel que défini dans la RFC 3605 [RFC3605]. Si RTCP n'est pas utilisé, l'agent MUST (doit) le signaler en utilisant b=RS:0 et b=RR:0 tels que définis dans la RFC 3556 [RFC3556].

Les adresses de transport qui seront la destination par défaut pour le média lors de la communication avec des pairs non-ICE MUST (doivent) également être présentes en tant que candidats dans une ou plusieurs lignes a=candidate.

ICE assure l'extensibilité en permettant à une offre ou à une réponse de contenir une série de jetons qui identifient les extensions ICE utilisées par cet agent. Si un agent prend en charge une extension ICE, il MUST (doit) inclure le jeton défini pour cette extension dans l'attribut ice-options.

Voici un exemple de message SDP qui inclut des attributs ICE (lignes pliées pour la lisibilité) :

    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

Une fois qu'un agent a envoyé son offre ou sa réponse, cet agent MUST (doit) être prêt à recevoir à la fois des paquets STUN et des paquets média sur chaque candidat. Comme indiqué dans la section 11.1, les paquets média peuvent être envoyés à un candidat avant son apparition en tant que destination par défaut pour le média dans une offre ou une réponse.

Dernière mise à jour le