5.1.2. Profile Names and Interoperability (Noms de profil et interopérabilité)

5.1.2. Profile Names and Interoperability (Noms de profil et interopérabilité)

Pour les sections "m=" média, les implémentations JSEP DOIVENT supporter le profil "UDP/TLS/RTP/SAVPF" spécifié dans [RFC5764] ainsi que le profil "TCP/DTLS/RTP/SAVPF" spécifié dans [RFC7850] et DOIVENT indiquer l'un de ces profils pour chaque ligne "m=" média qu'elles produisent dans une offre. Pour les sections "m=" données, les implémentations DOIVENT supporter le profil "UDP/DTLS/SCTP" ainsi que le profil "TCP/DTLS/SCTP" et DOIVENT indiquer l'un de ces profils pour chaque ligne "m=" données qu'elles produisent dans une offre. Le profil exact à utiliser est déterminé par le protocole associé au candidat ICE par défaut ou sélectionné actuel, comme décrit dans [RFC8839], Section 4.2.1.2.

Malheureusement, dans une tentative de compatibilité, certains points d'extrémité génèrent d'autres chaînes de profil même lorsqu'ils ont l'intention de supporter l'un de ces profils. Par exemple, un point d'extrémité peut générer "RTP/AVP" mais fournir des attributs "a=fingerprint" et "a=rtcp-fb", indiquant sa volonté de supporter "UDP/TLS/RTP/SAVPF" ou "TCP/DTLS/RTP/SAVPF". Afin de simplifier la compatibilité avec de tels points d'extrémité, les implémentations JSEP DOIVENT suivre les règles suivantes lors du traitement des sections "m=" média dans une offre reçue:

• Tout profil dans l'offre correspondant à l'un des suivants DOIT être accepté:

  • "RTP/AVP" (défini dans [RFC4566], Section 8.2.2)
  • "RTP/AVPF" (défini dans [RFC4585], Section 9)
  • "RTP/SAVP" (défini dans [RFC3711], Section 12)
  • "RTP/SAVPF" (défini dans [RFC5124], Section 6)
  • "TCP/DTLS/RTP/SAVP" (défini dans [RFC7850], Section 3.4)
  • "TCP/DTLS/RTP/SAVPF" (défini dans [RFC7850], Section 3.5)
  • "UDP/TLS/RTP/SAVP" (défini dans [RFC5764], Section 9)
  • "UDP/TLS/RTP/SAVPF" (défini dans [RFC5764], Section 9)

• Le profil dans toute ligne "m=" dans toute réponse générée DOIT correspondre exactement au profil fourni dans l'offre.

• Parce que DTLS-SRTP est REQUIS, le choix de SAVP ou AVP n'a aucun effet; le support de DTLS-SRTP est déterminé par la présence d'un ou plusieurs attributs "a=fingerprint". Notez que l'absence d'un attribut "a=fingerprint" entraînera un échec de négociation.

• L'utilisation d'AVPF ou AVP contrôle simplement les règles de temporisation utilisées pour le retour RTCP. Si AVPF est fourni ou si un attribut "a=rtcp-fb" est présent, supposez une temporisation AVPF, c'est-à-dire une valeur par défaut de "trr-int=0". Sinon, supposez qu'AVPF est utilisé en mode compatible AVP et utilisez une valeur de "trr-int=4000".

• Pour les sections "m=" données, les implémentations DOIVENT supporter la réception des profils "UDP/DTLS/SCTP", "TCP/DTLS/SCTP" ou "DTLS/SCTP" (pour la compatibilité ascendante).

Notez que les re-offres par les implémentations JSEP DOIVENT utiliser les chaînes de profil correctes même si l'échange offre/réponse initial a utilisé une chaîne de profil (incorrecte) plus ancienne. Cela simplifie le comportement JSEP, avec un inconvénient minimal, car tout point d'extrémité distant qui ne parvient pas à gérer une telle re-offre ne parviendra pas non plus à gérer l'offre initiale d'un point d'extrémité JSEP.