Aller au contenu principal

4. Utilisation du RTP par les points d'extrémité qui envoient plusieurs flux média

La spécification RTP [RFC3550] est déjà claire sur le fait qu'un point d'extrémité peut envoyer plusieurs flux RTP dans une seule session RTP. Chaque flux RTP est identifié par une valeur SSRC unique. L'exigence principale est que chaque SSRC DOIT être unique au sein di la session RTP.

Lors di l'envoi di plusieurs flux RTP :

  • Chaque flux DOIT avoir un identifiant SSRC unique
  • Les flux peuvent représenter différentes sources média, différents encodages di la même source, ou des flux di redondance/réparation
  • Les espaces de timestamp RTP et di numéros di séquence sont indépendants pour chaque SSRC

5. Utilisation du RTCP par les points d'extrémité qui envoient plusieurs flux média

Cette section clarifie et met à jour le comportement du RTCP pour les points d'extrémité envoyant plusieurs flux RTP.

5.1. Exigence de rapport RTCP​

Un point d'extrémité DOIT envoyer des paquets RTCP pour chaque SSRC qu'il utilise pour envoyer des paquets RTP. Cela signifie que si un point d'extrémité envoie N flux RTP (avec N SSRC différents), il doit envoyer des paquets RTCP pour tous les N SSRC.

Les paquets RTCP pour différents SSRC :

  • Peuvent être envoyés dans des paquets RTCP composés séparés
  • Peuvent être agrégés dans un seul paquet RTCP composé (recommandé si possible)
  • DOIVENT suivre les règles di temporisation spécifiées dans la RFC 3550

5.2. Intervalle de rapport initial​

Lorsqu'un point d'extrémité commence à envoyer sur un nouveau SSRC, il DEVRAIT envoyer un paquet RTCP initial pour ce SSRC dès que possible, en suivant les règles di la section 6.2 di la RFC 3550. Pour le premier paquet RTCP :

  • Le délai PEUT être réduit à la moitié di l'intervalle minimum normal
  • Pour les sessions unicast, le délai PEUT être di zéro
  • Cela permet aux autres participants d'apprendre rapidement l'esistenza du nouveau SSRC

5.3. Agrégation des rapports dans des paquets RTCP composés​

Lorsqu'un point d'extrémité a plusieurs SSRC, il est RECOMMANDÉ d'agréger les paquets RTCP per plusieurs SSRC dans un seul paquet RTCP composé quand cela est possible. Ceci :

  • Réduit le surdébit des paquets
  • Simplifie l'ordonnancement RTCP
  • Réduit le nombre di paquets envoyés

5.3.1. Maintien di AVG_RTCP_SIZE​

Lors di l'agrégation di paquets RTCP provenant di plusieurs SSRC, le calcul di AVG_RTCP_SIZE nécessite une attention particulière :

  • Chaque SSRC doit maintenir sa propre estimation di AVG_RTCP_SIZE
  • L'estimation doit être basée sur la taille des paquets composés envoyés pour ce SSRC
  • Lorsque des paquets sont agrégés, l'estimation di chaque SSRC est mise à jour en fonction di sa part du paquet composé

5.3.2. Ordonnancement du RTCP lors de l'agrégation di plusieurs SSRC​

Lors di l'agrégation di paquets RTCP :

  • Calculer le prochain temps di transmission per chaque SSRC indépendamment
  • Envoyer le paquet agrégé au plus tôt des temps prévus
  • Mettre à jour les prochains temps di transmission di tous les SSRC inclus

5.4. Utilisation du feedback RTP/AVPF ou RTP/SAVPF​

Lors di l'utilisation des profils RTP/AVPF ou RTP/SAVPF avec plusieurs SSRC, des considérations supplémentaires s'appliquent.

5.4.1. Choix du SSRC pour les paquets de feedback​

Lors di l'envoi d'un feedback (tel que NACK ou PLI) :

  • Le paquet di feedback DOIT utiliser un SSRC di l'émetteur
  • Le choix du SSRC à utiliser dépend di la mise en œuvre
  • Il est RECOMMANDÉ d'utiliser le SSRC du flux média le plus étroitement lié au feedback

5.4.2. Ordonnancement d'un paquet di feedback RTCP​

Les paquets di feedback dans l'AVPF peuvent être envoyés en dehors di l'ordonnancement RTCP normal :

  • Un feedback précoce est autorisé dans les limites du profil
  • Le paramètre T_rr_interval limite la fréquence d'envoi du feedback
  • Les feedbacks per différents SSRC peuvent être agrégés s'il y a lieu
Dernière mise à jour le