5.10. Applying a Remote Description (Application d'une description distante)

5.10. Applying a Remote Description (Application d'une description distante)

Les étapes suivantes sont exécutées pour appliquer une description distante (remote description). Si une erreur est renvoyée, la session DOIT être restaurée à l'état dans lequel elle se trouvait avant l'exécution de ces étapes.

Si la réponse contient des attributs « a=ice-options » où « trickle » est listé comme attribut, mettre à jour la propriété canTrickleIceCandidates de PeerConnection à « true ». Sinon, définir cette propriété à « false ».

Les étapes suivantes DOIVENT être exécutées pour les attributs au niveau de la session ; si un paramètre est hors limites ou ne peut pas être appliqué, le traitement DOIT s'arrêter et une erreur DOIT être renvoyée.

• Pour toute valeur de bande passante « CT » spécifiée, définir cette valeur comme limite du débit binaire total maximal pour toutes les sections « m= », comme spécifié dans [RFC4566], section 5.8. Dans cette limite globale, l'implémentation peut décider dynamiquement comment mieux allouer la bande passante disponible entre les sections « m= », en respectant les limites spécifiques éventuellement spécifiées pour des sections « m= » individuelles.

• Pour toute valeur de bande passante « RR » ou « RS » spécifiée, traiter comme spécifié dans [RFC3556], section 2.

• Toute valeur de bande passante « AS » ([RFC4566], section 5.8) DOIT être ignorée, car la signification de cette construction au niveau de la session n'est pas bien définie.

Pour chaque section « m= », les étapes suivantes DOIVENT être exécutées ; si un paramètre est hors limites ou ne peut pas être appliqué, le traitement DOIT s'arrêter et une erreur DOIT être renvoyée.

• Si l'ICE ufrag ou le mot de passe a changé par rapport à la description distante précédente :

  • Si la description est de type « offer », l'implémentation DOIT noter qu'un redémarrage ICE est nécessaire, comme décrit dans [RFC8839], section 4.4.1.1.1.

  • Si la description est de type « answer » ou « pranswer », vérifier si la description locale actuelle est un redémarrage ICE, et sinon, générer une erreur. Si l'état de PeerConnection est « have-remote-pranswer » et que l'ICE ufrag ou le mot de passe a changé par rapport à la réponse provisoire précédente, signaler à l'agent ICE d'abandonner tout état de liste de contrôle ICE précédent pour la section « m= ». Enfin, signaler à l'agent ICE de commencer les vérifications.

• Si la description locale actuelle indique un redémarrage ICE mais ni l'ICE ufrag ni le mot de passe n'ont changé par rapport à la description distante précédente (comme prescrit par [RFC8445], section 9), générer une erreur.

• Configurer les composants ICE associés à cette section média pour utiliser l'ICE ufrag distant et le mot de passe fournis pour leurs vérifications de connectivité.

• Apparier tout candidat ICE fourni avec les candidats locaux recueillis, comme décrit dans [RFC8445], section 6.1.2, et démarrer les vérifications de connectivité avec les identifiants appropriés.

• Si un attribut « a=end-of-candidates » est présent, traiter l'indication de fin de candidats comme décrit dans [RFC8838], section 14.

• Si la valeur du champ proto de la section « m= » indique l'utilisation de RTP :

  • Si la section « m= » est recyclée (voir section 5.2.2), dissocier le RtpTransceiver actuellement associé en définissant sa propriété mid à null, et abandonner la correspondance entre le transceiver et l'indice de sa section « m= ».

  • Si la section « m= » n'est associée à aucun RtpTransceiver (éventuellement parce qu'elle a été dissociée à l'étape précédente), soit trouver un RtpTransceiver soit en créer un selon les étapes suivantes :

    • Si la section « m= » est sendrecv ou recvonly, et qu'il existe des RtpTransceivers du même type ajoutés à PeerConnection par addTrack qui ne sont associés à aucune section « m= » et ne sont pas arrêtés, trouver le premier (selon l'ordre canonique décrit en section 5.2.1) de ces RtpTransceivers.

    • Si aucun RtpTransceiver n'a été trouvé à l'étape précédente, en créer un avec une direction recvonly.

    • Associer le RtpTransceiver trouvé ou créé à la section « m= » en définissant la valeur de la propriété mid du RtpTransceiver sur le MID de la section « m= », et établir une correspondance entre le transceiver et l'indice de la section « m= ». Si la section « m= » n'inclut pas de MID (c'est-à-dire que le point de terminaison distant ne prend pas en charge l'extension MID), générer une valeur pour la propriété mid du RtpTransceiver, en suivant les indications pour « a=mid » mentionnées en section 5.2.1.

  • Pour chaque format média spécifié également pris en charge par l'implémentation locale, établir une correspondance entre le type de charge utile spécifié et le format média, comme décrit dans [RFC3264], section 6.1. Concrètement, l'implémentation enregistre le type de charge utile à utiliser dans les paquets RTP sortants lors de l'envoi de chaque format média spécifié, ainsi que la préférence relative pour chaque format indiquée par leur ordre. Si un format média indiqué n'est pas pris en charge par l'implémentation locale, il DOIT être ignoré.

  • Pour chaque format média « rtx » spécifié, établir une correspondance entre le type de charge utile RTX et son type de charge utile principal associé, comme décrit dans [RFC4588], section 4. Si des types de charge utile principaux référencés sont absents, cela DOIT entraîner une erreur. Notez que les types de charge utile RTX peuvent référencer des types de charge utile principaux non pris en charge par l'implémentation média locale, auquel cas le type de charge utile RTX DOIT également être ignoré.

  • Pour chaque paramètre fmtp spécifié pris en charge par l'implémentation locale, les activer sur les formats média associés.

  • Pour chaque source de synchronisation (Synchronization Source, SSRC) spécifiée signalisée dans la section « m= », préparer le démultiplexage des flux RTP destinés à cette section « m= » en utilisant ce SSRC, comme décrit dans [RFC8843], section 9.2.

  • Pour chaque extension d'en-tête RTP spécifiée également prise en charge par l'implémentation locale, établir une correspondance entre l'ID d'extension et l'URI, comme décrit dans [RFC5285], section 5. Concrètement, l'implémentation enregistre l'ID d'extension à utiliser dans les paquets RTP sortants lors de l'envoi de chaque extension d'en-tête spécifiée. Si une extension d'en-tête RTP indiquée n'est pas prise en charge par l'implémentation locale, elle DOIT être ignorée.

  • Pour chaque mécanisme de retour RTCP spécifié pris en charge par l'implémentation locale, les activer sur les formats média associés.

  • Pour toute valeur de bande passante « TIAS » (« Transport Independent Application Specific Maximum ») spécifiée, définir cette valeur comme contrainte sur le débit binaire RTP maximal à utiliser lors de l'envoi de médias, comme spécifié dans [RFC3890]. Si une valeur « TIAS » n'est pas présente mais qu'une valeur « AS » est spécifiée, générer une valeur « TIAS » avec cette formule :

    TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)

    Le facteur 1000 convertit l'unité de kbps en bps (comme requis par TIAS), et 0,95 alloue 5 % au RTCP. Une estimation de la surcharge d'en-tête est ensuite soustraite, où 50 est basé sur 50 paquets par seconde, 40 sur une taille d'en-tête typique (en octets), et 8 convertit les octets en bits. Notez que « TIAS » est préféré à « AS » car il permet un contrôle plus précis de la bande passante.

  • Pour toute valeur de bande passante « RR » ou « RS », traiter comme spécifié dans [RFC3556], section 2.

  • Toute valeur de bande passante « CT » spécifiée DOIT être ignorée, car la signification de cette construction au niveau média n'est pas bien définie.

  • Si la section « m= » est de type « audio » :

    • Pour chaque format média « CN » spécifié, configurer la suppression de silence pour tous les formats média pris en charge avec la même fréquence d'horloge, comme décrit dans [RFC3389], section 5, sauf pour les formats qui ont leurs propres mécanismes internes de suppression de silence. La suppression de silence pour de tels formats (par ex. Opus) est contrôlée via les paramètres fmtp, comme discuté en section 5.2.3.2.

    • Pour chaque format média « telephone-event » spécifié, activer la transmission multifréquence à deux tons (DTMF) pour tous les formats média pris en charge avec la même fréquence d'horloge, comme décrit dans [RFC4733], section 2.5.1.2. S'il existe des formats média pris en charge sans format telephone-event correspondant, désactiver la transmission DTMF pour ces formats.

    • Pour toute valeur « ptime » spécifiée, configurer les formats média disponibles pour utiliser la taille de paquet spécifiée lors de l'envoi. Si la taille spécifiée n'est pas prise en charge pour un format média, utiliser la valeur la plus proche à la place.

Enfin, si cette description est de type « pranswer » ou « answer », suivre le traitement défini dans la section 5.11.