Aller au contenu principal

11. Media Handling (Gestion des médias)

11.1. Sending Media (Envoi de média)​

Les procédures d'envoi de média diffèrent pour les implémentations complètes et Lite.

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

Les agents envoient toujours le média en utilisant une paire de candidats, appelée paire de candidats sélectionnée. Un agent enverra le média au candidat distant dans la paire sélectionnée (en définissant l'adresse et le port de destination du paquet égaux à ce candidat distant), et l'enverra à partir du candidat local de la paire sélectionnée. Lorsque le candidat local est réflexif serveur ou pair, le média provient de la base. Le média envoyé depuis un candidat relayé est envoyé depuis la base via ce serveur TURN, en utilisant les procédures définies dans [RFC5766].

Si le candidat local est un candidat relayé, il est RECOMMENDED qu'un agent crée un canal sur le serveur TURN vers le candidat distant. Cela se fait en utilisant les procédures de création de canal telles que définies dans la section 11 de [RFC5766].

La paire sélectionnée pour un composant d'un flux média est :

  • vide si l'état de la liste de vérification pour ce flux média est Running, et qu'il n'y a pas de paire sélectionnée précédente pour ce composant en raison d'un redémarrage ICE

  • égale à la paire sélectionnée précédente pour un composant d'un flux média si l'état de la liste de vérification pour ce flux média est Running, et qu'il y avait une paire sélectionnée précédente pour ce composant en raison d'un redémarrage ICE

  • égale à la paire nommée la plus prioritaire pour ce composant dans la liste valide si l'état de la liste de vérification est Completed

Si la paire sélectionnée pour au moins un composant d'un flux média est vide, un agent MUST NOT envoyer de média pour aucun composant de ce flux média. Si la paire sélectionnée pour chaque composant d'un flux média a une valeur, un agent MAY envoyer le média pour tous les composants de ce flux média.

Notez que la paire sélectionnée pour un composant d'un flux média peut ne pas être égale à la paire par défaut pour ce même composant issue de l'échange d'offre/réponse le plus récent. Lorsque cela se produit, la paire sélectionnée est utilisée pour le média, pas la paire par défaut. Lorsque ICE se termine pour la première fois, si les paires sélectionnées ne correspondent pas aux paires par défaut, l'agent contrôlant envoie un échange d'offre/réponse mis à jour pour remédier à cette disparité. Cependant, jusqu'à ce que cette offre mise à jour arrive, il n'y aura pas de correspondance. De plus, dans des cas très inhabituels, les candidats par défaut dans l'offre/réponse mise à jour ne seront pas une correspondance.

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

Une implémentation Lite MUST NOT envoyer de média tant qu'elle n'a pas une liste Valide contenant une paire de candidats pour chaque composant de ce flux média. Une fois que cela se produit, l'agent MAY commencer à envoyer des paquets média. Pour ce faire, il envoie le média au candidat distant dans la paire (en définissant l'adresse et le port de destination du paquet égaux à ce candidat distant), et l'enverra à partir du candidat local.

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

ICE a des interactions avec les mécanismes d'adaptation du tampon de gigue. Un flux RTP peut commencer à utiliser un candidat et passer à un autre, bien que cela se produise rarement avec ICE. Le candidat le plus récent peut entraîner le passage des paquets RTP par un chemin différent à travers le réseau -- un chemin avec des caractéristiques de délai différentes. Comme indiqué ci-dessous, les agents sont encouragés à réajuster les tampons de gigue lorsqu'il y a des changements dans l'adresse source ou de destination des paquets média. De plus, de nombreux codecs audio utilisent le bit marqueur pour signaler le début d'une bouffée de parole, à des fins d'adaptation du tampon de gigue. Pour de tels codecs, il est RECOMMENDED que l'expéditeur définisse le bit marqueur [RFC3550] lorsqu'un agent bascule la transmission de média d'une paire de candidats à une autre.

11.2. Receiving Media (Réception de média)​

Les implémentations ICE MUST être prêtes à recevoir le média sur chaque composant sur tous les candidats fournis pour ce composant dans l'échange d'offre/réponse le plus récent (dans le cas de RTP, cela inclurait à la fois RTP et RTCP si des candidats étaient fournis pour les deux).

Il est RECOMMENDED que, lorsqu'un agent reçoit un paquet RTP avec une nouvelle adresse IP source ou de destination pour un flux média particulier, l'agent réajuste ses tampons de gigue.

La RFC 3550 [RFC3550] décrit un algorithme dans la section 8.2 pour détecter les collisions et les boucles de source de synchronisation (SSRC). Ces algorithmes sont basés, en partie, sur la vue de différentes adresses de transport source avec le même SSRC. Cependant, lorsque ICE est utilisé, de tels changements se produiront parfois lorsque les flux média basculent entre les candidats. Un agent sera en mesure de déterminer qu'un flux média provient du même pair à la suite de l'échange STUN qui précède la transmission de média. Ainsi, s'il y a un changement d'adresse de transport source, mais que les paquets média proviennent du même agent pair, cela SHOULD NOT être traité comme une collision SSRC.

Dernière mise à jour le