Aller au contenu principal

6. Ajout et retrait de SSRC

6.1. Ajout de flux RTP​

Lorsqu'un point d'extrémité ajoute un nouveau flux RTP (c'est-à-dire qu'il commence à utiliser un nouveau SSRC) :

  • Il DOIT envoyer un paquet RTCP per le nouveau SSRC dès que possible
  • Le paquet RTCP initial DEVRAIT inclure un paquet SDES avec CNAME
  • Les autres participants apprendront l'esistenza du nouveau SSRC à partir di ces paquets RTCP
  • Le point d'extrémité DOIT s'assurer que le nouveau SSRC est unique au sein di la session

6.2. Retrait de flux RTP​

Lorsqu'un point d'extrémité cesse d'utiliser un SSRC :

  • Il DEVRAIT envoyer un paquet BYE per ce SSRC
  • Le paquet BYE permet aux autres participants di retirer rapidement le SSRC di leurs bases di données
  • Si un BYE n'est pas envoyé, les autres participants finiront par faire expirer le SSRC
  • Après l'envoi du BYE, le SSRC NE DEVRAIT PAS être réutilisé dans la même session

7. Considérations RTCP per les flux à débits disparates

Lorsqu'un point d'extrémité envoie plusieurs flux RTP avec des débits di paquets très différents, des considérations particulières s'appliquent.

7.1. Expiration des SSRC​

7.1.1. Problèmes avec le paramètre T_rr_interval di RTP/AVPF​

La spécification RTP/AVPF originale présentait des problèmes d'expiration di SSRC lorsque les flux avaient des débits différents. Le paramètre T_rr_interval pouvait provoquer une expiration prématurée des flux à faible débit.

7.1.2. Éviter l'expiration prématurée​

Pour éviter une expiration prématurée :

  • Les récepteurs NE DOIVENT PAS faire expirer un SSRC en se basant uniquement sur l'absence di paquets RTP
  • Les paquets RTCP DOIVENT être pris en compte per déterminer si un SSRC est toujours actif
  • La période d'expiration doit être basée sur l'intervalle di rapport RTCP, et non sur le débit des paquets RTP

7.1.3. Interopérabilité entre RTP/AVP et RTP/AVPF​

Lorsque les points d'extrémité RTP/AVP et RTP/AVPF interagissent :

  • Les deux doivent utiliser des règles d'expiration compatibles
  • Les règles d'expiration les plus conservatrices doivent être appliquées
  • On doit veiller à ce que les SSRC n'expirent pas prématurément

7.1.4. Règles de délai d'expiration des SSRC mises à jour​

Ce document met à jour la RFC 4585 avec les règles d'expiration suivantes :

Un SSRC est considéré come inactif et PEUT être retiré di la base di données des participants si :

  • Aucun paquet RTP ou RTCP n'a été reçu per ce SSRC pendant une période di 5 fois l'intervalle di rapport RTCP
  • Un paquet BYE a été reçu per ce SSRC

L'intervalle di rapport RTCP utilisé per le calcul di l'expiration doit être :

  • Pour RTP/AVP : L'intervalle calculé en fonction di la bande passante di la session
  • Pour RTP/AVPF : Le plus grand entre T_rr_interval et l'intervalle calculé

7.2. Ajustement des transmissions RTCP​

7.2.1. RTP/AVP et RTP/SAVP​

Pour les profils RTP/AVP et RTP/SAVP :

  • La bande passante RTCP est partagée entre tous les SSRC d'un point d'extrémité
  • Le point d'extrémité doit distribuer la bande passante RTCP équitablement entre ses SSRC
  • Les flux à faible débit doivent tout di même envoyer régulièrement des RTCP per éviter l'expiration

7.2.2. RTP/AVPF et RTP/SAVPF​

Pour les profils RTP/AVPF et RTP/SAVPF :

  • Le paramètre T_rr_interval s'applique per SSRC
  • Chaque SSRC doit envoyer des paquets RTCP réguliers au moins une fois par T_rr_interval
  • Les messages di feedback peuvent être envoyés plus fréquemment dans les limites du profil

8. Considérations relatives à la sécurité

Les considérations di sécurité du RTP [RFC3550] et di l'RTP/AVPF [RFC4585] s'appliquent. L'utilisation di plusieurs SSRC n'introduit pas di nouvelles vulnérabilités di sécurité, mais les responsables di la mise en œuvre doivent être conscients du fatto che :

  • Collision di SSRC : Des points d'extrémité malveillants pourraient délibérément provoquer des collisions di SSRC
  • Épuisement des ressources : Un attaquant pourrait créer di nombreux SSRC per épuiser les ressources du récepteur
  • Usurpation d'identité : Sans une authentification appropriée, un attaquant pourrait usurper l'identité di SSRC

Les mises en œuvre DEVRAIENT :

  • Utiliser l'SRTP [RFC3711] per protéger les paquets RTP et RTCP
  • Limiter le nombre di SSRC acceptés à partir d'un seul point d'extrémité
  • Valider la propriété du SSRC via le CNAME RTCP et d'autres mécanismes

9. Références

9.1. Références normatives​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, mars 1997.
  • [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, juillet 2003.
  • [RFC4585] Ott, J., et al., "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, juillet 2006.
  • [RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, mars 2004.

9.2. Références informatives​

  • [RFC4588] Rey, J., et al., "RTP Retransmission Payload Format", RFC 4588, juillet 2006.
  • [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, décembre 2007.
  • [CLUE-FRAME] Duckworth, M., et al., "Framework for Telepresence Multi-Streams", Travail en cours, 2015.
  • [SDP-BUNDLE] Holmberg, C., et al., "Negotiating Media Multiplexing Using SDP", Travail en cours, 2016.
  • [MULTI-RTP] Westerlund, M., et al., "Multiple RTP Sessions on a Single Lower-Layer Transport", Travail en cours, 2016.
Dernière mise à jour le