6. Ajout et suppression de SSRC

L'ensemble des SSRC présents dans une seule session RTP peut varier au fil du temps en raison de changements dans le nombre de points d'extrémité de la session ou de changements dans le nombre ou le type de flux RTP envoyés.

Chaque point d'extrémité d'une session RTP disposera d'au moins un SSRC qu'il utilise pour les rapports RTCP et, s'il le souhaite, pour l'envoi de médias. Il peut également disposer de SSRC supplémentaires, pour envoyer des sources média supplémentaires ou pour des rapports RTCP supplémentaires. Si l'ensemble des sources média envoyées change, alors l'ensemble des SSRC envoyés changera. Des changements dans le format média ou la cadence d'horloge peuvent également nécessiter des changements dans l'ensemble des SSRC utilisés. Un point d'extrémité peut aussi avoir plus de SSRC qu'il n'a de flux RTP actifs, et envoyer des rapports RTCP relatifs à des SSRC qui n'envoient pas actuellement de paquets de données RTP, afin que ses pairs aient connaissance de ces SSRC et disposent du contexte associé (par exemple, la synchronisation d'horloge et un CNAME SDES) pour pouvoir restituer les médias dès qu'ils deviennent actifs.

Dans ce qui suit, nous décrivons quelques considérations relatives à l'ajout et à la suppression de flux RTP et des SSRC qui leur sont associés.

6.1. Ajout de flux RTP

Lorsqu'un point d'extrémité rejoint une session RTP, il peut avoir zéro, un ou plusieurs flux RTP qu'il enverra, ou qu'il est prêt à envoyer. S'il n'a aucun flux RTP qu'il prévoit d'envoyer, il a tout de même besoin d'un SSRC qui sera utilisé pour envoyer le retour RTCP. S'il doit envoyer un ou plusieurs flux RTP, il aura besoin du nombre correspondant de valeurs de SSRC. Les SSRC utilisés par un point d'extrémité sont portés à la connaissance des autres points d'extrémité de la session RTP par l'envoi de paquets RTP et RTCP. Les SSRC peuvent aussi être signalés par des moyens non RTP (par exemple, [RFC5576]). Sauf restriction par la signalisation, un point d'extrémité peut, à tout moment, envoyer un flux RTP supplémentaire, identifié par un nouveau SSRC (cela peut être associé à un événement de signalisation, mais cela sort du cadre de ce mémo). Cela rend le nouveau SSRC visible aux autres points d'extrémité de la session, puisqu'ils partagent l'espace de SSRC unique inhérent à la définition d'une session RTP.

Un point d'extrémité qui n'a jamais envoyé de flux RTP disposera d'un SSRC qu'il utilise pour les rapports RTCP. Si ce point d'extrémité souhaite commencer à envoyer un flux RTP, il est RECOMMANDÉ (RECOMMENDED) qu'il utilise son SSRC existant pour ce flux, car sinon le nombre de participants de la session RTP sera inutilement augmenté, ce qui conduira à un intervalle de rapport RTCP plus long et à des rapports RTCP plus volumineux en raison des rapports croisés. Si le point d'extrémité souhaite commencer à envoyer plus d'un flux RTP, il devra générer un nouveau SSRC pour le deuxième flux RTP et pour tout flux RTP ultérieur.

Un point d'extrémité qui a précédemment cessé d'envoyer un flux RTP, et qui souhaite commencer à envoyer un nouveau flux RTP, ne peut généralement pas réutiliser le SSRC existant et doit souvent générer un nouveau SSRC, car un SSRC ne peut pas changer de type de média (par exemple, audio vers vidéo) ni de cadence d'horloge d'horodatage RTP [RFC7160], et parce que le SSRC peut être associé à une sémantique particulière par l'application (remarque : un flux RTP peut être suspendu puis redémarré en utilisant le même SSRC, à condition que des rapports RTCP soient envoyés pour ce SSRC pendant la suspension ; ces règles ne s'appliquent qu'aux nouveaux flux RTP réutilisant un SSRC existant).

6.2. Suppression de flux RTP

Un SSRC est retiré d'une session RTP de l'une des deux manières suivantes. Lorsqu'un point d'extrémité cesse d'envoyer des paquets RTP et RTCP en utilisant un SSRC, alors ce SSRC finira par expirer comme décrit dans la Section 6.3.5 du [RFC3550]. Sinon, un SSRC peut être explicitement retiré de l'usage en envoyant un paquet RTCP BYE comme décrit dans la Section 6.3.7 du [RFC3550]. Il est RECOMMANDÉ (RECOMMENDED) que les SSRC soient retirés de l'usage en envoyant un paquet RTCP BYE. Notez que le [RFC3550] exige que le RTCP BYE DEVRAIT (SHOULD) être le dernier paquet RTP/RTCP envoyé dans la session RTP pour un SSRC. Si un point d'extrémité doit redémarrer un flux RTP après avoir envoyé un RTCP BYE pour son SSRC, il doit générer une nouvelle valeur de SSRC pour ce flux.

Le caractère définitif de l'envoi d'un RTCP BYE signifie que les points d'extrémité doivent déterminer si la cessation de la transmission d'un flux RTP est temporaire ou permanente. La suspension temporaire de la transmission de médias à l'aide d'un flux RTP (SSRC) particulier doit maintenir ce SSRC comme participant actif, en poursuivant la transmission RTCP pour celui-ci. Ainsi, l'envoi de médias peut être repris immédiatement, en sachant que le contexte est en place. Lors de l'arrêt définitif de la transmission, un participant doit envoyer un RTCP BYE pour permettre aux autres participants d'utiliser les ressources de bande passante RTCP et de nettoyer leurs bases de données d'état.

Un point d'extrémité qui cesse la transmission de tous ses flux RTP mais reste dans la session RTP DOIT (MUST) maintenir au moins un SSRC destiné à être utilisé pour les rapports et le retour RTCP (c'est-à-dire qu'il ne peut pas envoyer un BYE pour tous les SSRC, mais doit conserver au moins un SSRC actif). Comme certains paquets de retour peuvent être liés à un type de média, il peut être nécessaire de maintenir un SSRC par type de média au sein d'une session RTP. Une alternative peut être de créer un nouveau SSRC à utiliser pour les rapports et le retour RTCP. Cependant, afin d'éviter la perception qu'un point d'extrémité quitte complètement une session RTP, un tel nouveau SSRC devrait être établi d'abord -- avant de terminer tous les SSRC existants.