5.11. Applying an Answer (Application d'une réponse)

5.11. Applying an Answer (Application d'une réponse)

En plus des étapes mentionnées ci-dessus pour le traitement d'une description locale ou distante, les étapes suivantes sont exécutées lors du traitement d'une description de type « pranswer » ou « answer ».

Pour chaque section « m= », les étapes suivantes DOIVENT être exécutées :

• Si la section « m= » a été rejetée (c'est-à-dire que la valeur du champ port est mise à zéro dans la réponse), arrêter toute réception ou transmission de média pour cette section et, sauf si une section « m= » non rejetée est regroupée en bundle avec cette section, abandonner tout composant ICE associé, comme décrit dans [RFC8839], section 4.4.3.1.

• Si l'empreinte DTLS distante a changé ou si la valeur de l'attribut « a=tls-id » a changé, démonter la connexion DTLS. Cela inclut le cas où l'état de PeerConnection est « have-remote-pranswer ». Si une connexion DTLS doit être démontée mais que la réponse n'indique pas un redémarrage ICE ou, dans le cas de « have-remote-pranswer », de nouveaux identifiants ICE, une erreur DOIT être générée. Si un redémarrage ICE est effectué sans changement de la valeur tls-id ou de l'empreinte, la même connexion DTLS est poursuivie sur le nouveau canal ICE. Notez que bien que JSEP exige que les répondeurs modifient la valeur tls-id si et seulement si l'offreur le fait, les répondeurs non JSEP sont autorisés à modifier la valeur tls-id tant que l'offre contenait un redémarrage ICE. Ainsi, les implémentations JSEP qui traitent des données DTLS avant de recevoir une réponse DOIVENT être prêtes à recevoir soit un ClientHello soit des données de la connexion DTLS précédente.

• Si aucune connexion DTLS valide n'existe, préparer le démarrage d'une connexion DTLS, en utilisant les rôles et empreintes spécifiés, sur les composants ICE sous-jacents, une fois qu'ils sont actifs.

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

  • Si la section « m= » référence des mécanismes de retour RTCP qui n'étaient pas présents dans la section « m= » correspondante de l'offre, cela indique un problème de négociation et DOIT entraîner une erreur. Cependant, de nouveaux formats média et de nouvelles valeurs d'extension d'en-tête RTP sont autorisés dans la réponse, comme décrit dans [RFC3264], section 7 et [RFC5285], section 6.

  • Si la section « m= » a le mux RTCP activé, abandonner le composant ICE RTCP, s'il existe, et commencer ou poursuivre le mux de RTCP sur le composant ICE RTP, comme spécifié dans [RFC5761], section 5.1.3. Sinon, préparer la transmission de RTCP sur le composant ICE RTCP ; si aucun composant ICE RTCP n'existe parce que le mux RTCP était précédemment activé, cela DOIT entraîner une erreur.

  • Si la section « m= » a Reduced-Size RTCP activé, configurer la transmission RTCP pour cette section « m= » pour utiliser Reduced-Size RTCP, comme spécifié dans [RFC5506].

  • Si l'attribut de direction dans la réponse indique que l'implémentation JSEP doit envoyer des médias (« sendonly » pour les réponses locales, « recvonly » pour les réponses distantes, ou « sendrecv » pour l'un ou l'autre type de réponse), choisir le format média à envoyer comme le format média le plus préféré de la description distante également pris en charge localement, comme discuté dans les sections 6.1 et 7 de [RFC3264], et commencer à transmettre des médias RTP en utilisant ce format une fois les couches de transport sous-jacentes établies. Si un SSRC n'a pas déjà été choisi pour ce flux RTP sortant, choisir un SSRC aléatoire unique. Si des médias sont déjà transmis, le même SSRC DEVRAIT être utilisé sauf si la fréquence d'horloge du nouveau codec est différente, auquel cas un nouveau SSRC DOIT être choisi, comme spécifié dans [RFC7160], section 4.1.

  • La correspondance des types de charge utile de la description distante est utilisée pour déterminer les types de charge utile pour les flux RTP sortants, y compris le type de charge utile pour le format média d'envoi choisi ci-dessus. Toute extension d'en-tête RTP qui a été négociée devrait être incluse dans les flux RTP sortants, en utilisant la correspondance d'extension de la description distante. Si l'extension d'en-tête MID a été négociée, l'inclure dans les flux RTP sortants, comme indiqué dans [RFC8843], section 15. Si les extensions d'en-tête RtpStreamId ou RepairedRtpStreamId ont été négociées et que des rid-id ont été établis, inclure ces extensions d'en-tête dans les flux RTP sortants, comme indiqué dans [RFC8851], section 4.

  • Si la section « m= » est de type « audio », et si la suppression de silence a été (1) configurée pour le format média d'envoi suite au traitement de la description distante et (2) également activée pour ce format dans la description locale, utiliser la suppression de silence pour les médias sortants, conformément aux indications de la section 5.2.3.2. Si ces conditions ne sont pas remplies, la suppression de silence NE DOIT PAS être utilisée pour les médias sortants.

  • Si le simulcast a été négocié, envoyer le nombre approprié de flux RTP source (Source RTP Streams) comme spécifié dans [RFC8853], section 5.3.3.

  • Si le format média d'envoi choisi ci-dessus a un format média « rtx » correspondant ou si un mécanisme FEC a été négocié, établir un flux RTP de redondance avec un SSRC aléatoire unique pour chaque flux RTP source, et commencer ou poursuivre la transmission de paquets RTX/FEC selon les besoins.

  • Si le format média d'envoi choisi ci-dessus a un format média « red » correspondant de la même fréquence d'horloge, autoriser l'encodage redondant en utilisant le format spécifié à des fins de résilience, comme discuté dans [RFC8854], section 3.2. Notez que contrairement aux formats média RTX ou FEC, le format « red » est transmis sur le flux RTP source, pas sur le flux RTP de redondance.

  • Activer les mécanismes de retour RTCP référencés dans la section média pour tous les flux RTP source utilisant les formats média spécifiés. Concrètement, commencer ou poursuivre l'envoi des types de retour demandés et réagir au retour reçu, comme spécifié dans [RFC4585], section 4.2. Lors de l'envoi de retour RTCP, suivre les règles et recommandations de [RFC8108], section 5.4.1 pour sélectionner quel SSRC utiliser.

  • Si l'attribut de direction dans la réponse indique que l'implémentation JSEP ne doit pas envoyer de médias (« recvonly » pour les réponses locales, « sendonly » pour les réponses distantes, ou « inactive » pour l'un ou l'autre type de réponse), arrêter la transmission de tous les médias RTP, mais continuer à envoyer du RTCP, comme décrit dans [RFC3264], section 5.1.

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

  • Si une association SCTP existe et que le port SCTP distant a changé, abandonner l'association SCTP existante. Cela inclut le cas où l'état de PeerConnection est « have-remote-pranswer ».

  • Si aucune association SCTP valide n'existe, préparer l'initiation d'une association SCTP sur le composant ICE et la connexion DTLS associés, en utilisant la valeur du port SCTP local de la description locale et la valeur du port SCTP distant de la description distante, comme décrit dans [RFC8841], section 10.2.

Si la réponse contient des groupes de bundle valides, abandonner tout composant ICE pour les sections « m= » qui seront regroupées sur les composants ICE primaires de chaque bundle, et commencer le mux de ces sections « m= » en conséquence, comme décrit dans [RFC8843], section 7.4.

Si la description est de type « answer » et qu'il reste des candidats dans le pool de candidats ICE, les abandonner.