5. Multiplexage de RTP et RTCP sur un port unique

Les procédures de multiplexage de RTP et RTCP sur un port unique dépendent du fait que la session est une session monodiffusion ou une session multidiffusion. Pour les sessions multidiffusion, les procédures dépendent également du fait qu'il s'agisse d'une multidiffusion Any Source (ASM) ou d'une multidiffusion spécifique à la source (SSM).

5.1. Sessions monodiffusion

Il est acceptable de multiplexer les paquets RTP et RTCP sur un port UDP unique pour faciliter la traversée du NAT pour les sessions monodiffusion, à condition que les types de charge utile RTP utilisés dans la session soient choisis conformément aux règles de la section 4, et à condition que le multiplexage soit signalé à l'avance. Les sections suivantes décrivent comment de telles sessions multiplexées peuvent être signalées à l'aide du protocole d'initiation de session (SIP) avec le modèle d'offre/réponse.

5.1.1. Signalisation SDP

Lorsque le protocole de description de session (SDP) [8] est utilisé pour négocier des sessions RTP selon le modèle d'offre/réponse [9], l'attribut "a=rtcp-mux" (voir la section 8) indique le désir de multiplexer RTP et RTCP sur un seul port. L'offre SDP initiale DOIT inclure cet attribut au niveau média pour demander le multiplexage de RTP et RTCP sur un seul port. Par exemple :

v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux

Cette offre désigne une session de voix sur IP monodiffusion utilisant le profil RTP/AVP avec un codage iLBC. Le répondant est invité à envoyer RTP et RTCP au port 49170 sur l'adresse IPv6 2001:DB8::211:24ff:fea3:7a2e.

Si le répondant souhaite multiplexer RTP et RTCP sur un seul port, il DOIT inclure un attribut "a=rtcp-mux" au niveau média dans la réponse. Les types de charge utile RTP utilisés dans la réponse DOIVENT être conformes aux règles de la section 4.

Si la réponse ne contient pas d'attribut "a=rtcp-mux", l'offrant ne DOIT PAS multiplexer les paquets RTP et RTCP sur un seul port. Au lieu de cela, il doit envoyer et recevoir le RTCP sur un port alloué selon les règles habituelles de sélection de port (soit la paire de ports, soit un port signalé si l'attribut "a=rtcp:" [10] est également inclus). Cela se produira lors de la communication avec un pair qui ne comprend pas l'attribut "a=rtcp-mux".

Lorsque le SDP est utilisé de manière déclarative, la présence d'un attribut "a=rtcp-mux" signale que l'expéditeur multiplexera RTP et RTCP sur le même port. Le récepteur DOIT être prêt à recevoir des paquets RTCP sur le port RTP, et toute réservation de ressources doit être faite en incluant la bande passante RTCP.

5.1.2. Interactions avec le forking SIP

Lors de l'utilisation de SIP avec un proxy de forking, il est possible qu'une requête INVITE entraîne plusieurs réponses 200 (OK). Si le multiplexage RTP et RTCP est proposé dans cet INVITE, il est important de savoir que certains répondants peuvent prendre en charge le multiplexage RTP et RTCP, d'autres non. Cela obligera l'offrant à écouter le RTCP à la fois sur le port RTP et sur le port RTCP habituel, et à envoyer le RTCP sur les deux ports, à moins que les branches de l'appel qui prennent en charge le multiplexage ne soient renégociées pour utiliser des ports RTP et RTCP séparés.

5.1.3. Interactions avec ICE

Il est courant d'utiliser la méthodologie Interactive Connectivity Establishment (ICE) [19] pour établir des sessions RTP en présence de dispositifs de traduction d'adresse réseau (NAT) ou d'autres boîtiers intermédiaires. Si RTP et RTCP sont envoyés sur des ports séparés, le flux média RTP comprend deux composants dans ICE (un pour RTP et un pour RTCP), avec des tests de connectivité effectués pour chaque composant. Si RTP et RTCP doivent être multiplexés sur le même port, certains de ces tests de connectivité peuvent être évités, ce qui réduit la surcharge d'ICE.

S'il est souhaité d'utiliser à la fois ICE et RTP et RTCP multiplexés, l'offre initiale DOIT contenir un attribut "a=rtcp-mux" pour indiquer que le multiplexage RTP et RTCP est souhaité et DOIT contenir des lignes "a=candidate:" pour RTP et RTCP ainsi qu'une ligne "a=rtcp:" indiquant un port de repli pour le RTCP dans le cas où le répondant ne prendrait pas en charge le multiplexage RTP et RTCP. Cela DOIT être fait pour chaque média où le multiplexage RTP et RTCP est souhaité.

Si le répondant souhaite multiplexer RTP et RTCP sur un seul port, il DOIT générer une réponse contenant un attribut "a=rtcp-mux" et une seule ligne "a=candidate:" correspondant au port RTP (c'est-à-dire qu'il n'y a pas de candidat pour le RTCP) pour chaque média où il est souhaité d'utiliser le multiplexage RTP et RTCP. Le répondant effectue ensuite les tests de connectivité pour ce média comme si l'offre n'avait contenu qu'un seul candidat pour RTP. Si le répondant ne souhaite pas multiplexer RTP et RTCP sur un seul port, il ne DOIT PAS inclure l'attribut "a=rtcp-mux" dans sa réponse et DOIT effectuer des tests de connectivité pour tous les candidats proposés de la manière habituelle.

À la réception de la réponse, l'offrant recherche la présence de la ligne "a=rtcp-mux" pour chaque média où le multiplexage a été proposé. Si elle est présente, les tests de connectivité se poursuivent comme si un seul candidat (pour RTP) avait été proposé, et le multiplexage est utilisé une fois la session établie. Si la ligne "a=rtcp-mux" n'est pas présente, la session se poursuit avec des tests de connectivité utilisant à la fois les candidats RTP et RTCP, ce qui conduit finalement à l'établissement d'une session avec RTP et RTCP sur des ports séparés (comme signalé par l'attribut "a=rtcp:").

5.1.4. Interactions avec la compression d'en-tête

Le multiplexage des paquets RTP et RTCP sur un seul port peut avoir un impact négatif sur les schémas de compression d'en-tête, par exemple, Compressed RTP (CRTP) [20] et RObust Header Compression (ROHC) [21] [22]. La compression d'en-tête exploite les schémas de changement dans les en-têtes RTP des paquets consécutifs pour envoyer une indication que le paquet a changé de la manière attendue, plutôt que d'envoyer l'en-tête complet à chaque fois. Cela peut entraîner d'importantes économies de bande passante si les flux ont un comportement uniforme.

La présence de paquets RTCP multiplexés avec des paquets de données RTP peut perturber les schémas de changement entre les en-têtes et a le potentiel de réduire considérablement l'efficacité de la compression d'en-tête. L'étendue de cette perturbation dépend de l'algorithme de compression d'en-tête utilisé et de la manière dont les flux sont classés. Un classificateur bien conçu devrait être capable de séparer RTP et RTCP multiplexés sur le même port dans des contextes de compression différents, en utilisant le champ de type de charge utile, de sorte que l'effet sur le taux de compression soit faible. Un classificateur qui attribue des contextes de compression uniquement en fonction des adresses IP et des ports UDP n'aura pas de bonnes performances. Il est prévu que les implémentations de compression d'en-tête devront être mises à jour pour prendre en charge efficacement le RTP et le RTCP multiplexés sur le même port.

Cet effet du multiplexage de RTP et RTCP sur la compression d'en-tête peut être particulièrement important dans les environnements, tels que certains systèmes de téléphonie sans fil, qui comptent sur l'efficacité de la compression d'en-tête pour adapter les médias à un canal de capacité limitée. Les implications du multiplexage RTP et RTCP doivent être soigneusement examinées avant toute utilisation dans de tels environnements.

5.2. Sessions multidiffusion Any Source

Le problème de la traversée du NAT est moins grave pour les sessions RTP en multidiffusion Any Source (ASM) que pour les sessions RTP en monodiffusion, et l'avantage d'utiliser des ports séparés pour RTP et RTCP est plus grand en raison de la capacité à prendre en charge des moniteurs tiers uniquement RTCP. En conséquence, les paquets RTP et RTCP ne DEVRAIENT PAS être multiplexés sur un seul port lors de l'utilisation de sessions RTP ASM et DEVRAIENT plutôt utiliser des ports et des groupes de multidiffusion séparés.

5.3. Sessions multidiffusion spécifiques à la source

Les sessions RTP fonctionnant sur la multidiffusion spécifique à la source (SSM) envoient les paquets RTCP de la source aux récepteurs via le canal de multidiffusion, mais utilisent un mécanisme de retour monodiffusion séparé [6] pour envoyer le RTCP des récepteurs à la source, la source soit renvoyant les paquets RTCP au groupe, soit envoyant des rapports de synthèse agrégés.

En suivant la terminologie de [6], nous identifions trois flux RTP/RTCP dans une session SSM :

1. Flux RTP et RTCP entre l'expéditeur média et la source de distribution. Dans de nombreux scénarios, l'expéditeur média et la source de distribution sont colocalisés, le multiplexage n'est donc pas un problème. Si l'expéditeur média et la source de distribution sont connectés par une connexion monodiffusion, les règles de la section 5.1 du présent mémorandum s'appliquent à cette connexion. Si l'expéditeur média et la source de distribution sont connectés par une connexion multidiffusion Any Source, les règles de la section 5.2 s'appliquent à cette connexion. Si l'expéditeur média et la source de distribution sont connectés par une connexion multidiffusion spécifique à la source, les paquets RTP et RTCP PEUVENT être multiplexés sur un port unique, à condition que cela soit signalé (en utilisant "a=rtcp-mux" si vous utilisez le SDP).

2. RTP et RTCP envoyés de la source de distribution aux récepteurs. La source de distribution PEUT multiplexer RTP et RTCP sur un port unique pour faciliter les problèmes de traversée du NAT sur le chemin SSM direct, bien que cela puisse gêner les dispositifs de surveillance tiers si la session utilise le modèle de retour simple. Lors de l'utilisation du SDP, le multiplexage DEVRAIT être signalé à l'aide de l'attribut "a=rtcp-mux".

3. RTCP envoyé des récepteurs à la source de distribution. Il s'agit d'un chemin uniquement RTCP, le multiplexage n'est donc pas un problème.

Le multiplexage des paquets RTP et RTCP sur un port unique dans une session SSM présente un risque d'interactions avec la compression d'en-tête décrite dans la section 5.1.4.