Aller au contenu principal

5. RTP Data Transfer Protocol (Protocole de transfert de données RTP)

5.1 RTP Fixed Header Fields (Champs d'en-tête RTP fixe)​

L'en-tête RTP a le format suivant :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Les douze premiers octets sont présents dans chaque paquet RTP, tandis que la liste des identificateurs CSRC n'est présente que lorsqu'elle est insérée par un mélangeur. Les champs ont la signification suivante :

  • version (V) : 2 bits. Ce champ identifie la version de RTP. La version définie par cette spécification est deux (2). (La valeur 1 est utilisée par la première version brouillon de RTP et la valeur 0 est utilisée par le protocole initialement implémenté dans l'outil audio « vat ».)

  • remplissage (P, padding) : 1 bit. Si le bit de remplissage est placé, le paquet contient un ou plusieurs octets de remplissage supplémentaires à la fin qui ne font pas partie de la charge utile. Le dernier octet du remplissage contient un compte du nombre d'octets de remplissage à ignorer, lui-même inclus. Le remplissage peut être nécessaire pour certains algorithmes de chiffrement à tailles de bloc fixes ou pour transporter plusieurs paquets RTP dans une unité de données de protocole de couche inférieure.

  • extension (X) : 1 bit. Si le bit d'extension est placé, l'en-tête fixe DOIT être suivi d'exactement une extension d'en-tête, dont le format est défini à la section 5.3.1.

  • compte CSRC (CC) : 4 bits. Le compte CSRC contient le nombre d'identificateurs CSRC qui suivent l'en-tête fixe.

  • marqueur (M, marker) : 1 bit. L'interprétation du marqueur est définie par un profil. Il est destiné à permettre de marquer des événements significatifs tels que les frontières de trame dans le flux de paquets. Un profil PEUT définir des bits de marqueur supplémentaires ou spécifier qu'il n'y a pas de bit de marqueur en changeant le nombre de bits dans le champ de type de charge utile (voir la section 5.3).

  • type de charge utile (PT, payload type) : 7 bits. Ce champ identifie le format de la charge utile RTP et détermine son interprétation par l'application. Un profil PEUT spécifier une correspondance statique par défaut des codes de type de charge utile aux formats de charge utile. Des codes de type de charge utile supplémentaires PEUVENT être définis dynamiquement par des moyens non-RTP (voir la section 3). Un ensemble de correspondances par défaut pour l'audio et la vidéo est spécifié dans le document compagnon RFC 3551 [1]. Une source RTP PEUT changer le type de charge utile au cours d'une session, mais ce champ NE DEVRAIT PAS être utilisé pour multiplexer des flux média séparés (voir la section 5.2).

    Un récepteur DOIT ignorer les paquets dont il ne comprend pas le type de charge utile.

  • numéro de séquence (sequence number) : 16 bits. Le numéro de séquence s'incrémente de un pour chaque paquet de données RTP envoyé, et peut être utilisé par le récepteur pour détecter la perte de paquets et restaurer la séquence des paquets. La valeur initiale du numéro de séquence DEVRAIT être aléatoire (imprévisible) pour rendre plus difficiles les attaques à texte clair connu sur le chiffrement, même si la source elle-même ne chiffre pas selon la méthode de la section 9.1, car les paquets peuvent transiter par un traducteur qui le fait. Des techniques pour choisir des nombres imprévisibles sont discutées dans [17].

  • horodatage (timestamp) : 32 bits. L'horodatage reflète l'instant d'échantillonnage du premier octet dans le paquet de données RTP. L'instant d'échantillonnage DOIT être dérivé d'une horloge qui s'incrémente de façon monotone et linéaire dans le temps pour permettre les calculs de synchronisation et de gigue (jitter, voir la section 6.4.1). La résolution de l'horloge DOIT être suffisante pour la précision de synchronisation désirée et pour mesurer la gigue d'arrivée des paquets (un tic par trame vidéo est typiquement insuffisant). La fréquence de l'horloge dépend du format des données transportées comme charge utile et est spécifiée statiquement dans le profil ou la spécification de format de charge utile qui définit le format, ou PEUT être spécifiée dynamiquement pour les formats de charge utile définis par des moyens non-RTP. Si les paquets RTP sont générés périodiquement, l'instant d'échantillonnage nominal tel que déterminé à partir de l'horloge d'échantillonnage doit être utilisé, et non une lecture de l'horloge système. Par exemple, pour un audio à débit fixe, l'horloge d'horodatage s'incrémenterait vraisemblablement de un pour chaque période d'échantillonnage. Si une application audio lit des blocs couvrant 160 périodes d'échantillonnage depuis le périphérique d'entrée, l'horodatage serait augmenté de 160 pour chaque tel bloc, que le bloc soit transmis dans un paquet ou abandonné comme silencieux.

    La valeur initiale de l'horodatage DEVRAIT être aléatoire, comme pour le numéro de séquence. Plusieurs paquets RTP consécutifs auront des horodatages égaux s'ils sont (logiquement) générés en même temps, par exemple s'ils appartiennent à la même trame vidéo. Des paquets RTP consécutifs PEUVENT contenir des horodatages non monotones si les données ne sont pas transmises dans l'ordre où elles ont été échantillonnées, comme dans le cas des trames vidéo interpolées MPEG. (Les numéros de séquence des paquets tels que transmis seront toujours monotones.)

    Les horodatages RTP de différents flux média peuvent avancer à des débits différents et ont généralement des décalages aléatoires indépendants. Par conséquent, bien que ces horodatages soient suffisants pour reconstruire la temporisation d'un seul flux, comparer directement les horodatages RTP de médias différents n'est pas efficace pour la synchronisation. À la place, pour chaque média l'horodatage RTP est relié à l'instant d'échantillonnage en le pairant avec un horodatage d'une horloge de référence (horloge murale, wallclock) qui représente le moment où les données correspondant à l'horodatage RTP ont été échantillonnées. L'horloge de référence est partagée par tous les médias à synchroniser. Les paires d'horodatages ne sont pas transmises dans chaque paquet de données, mais à un débit plus faible dans les paquets RTCP SR comme décrit à la section 6.4.

    L'instant d'échantillonnage est choisi comme point de référence pour l'horodatage RTP parce qu'il est connu du point de terminaison émetteur et qu'il a une définition commune pour tous les médias, indépendamment des délais d'encodage ou d'autres traitements. Le but est de permettre une présentation synchronisée de tous les médias échantillonnés au même moment.

    Les applications transmettant des données stockées plutôt que des données échantillonnées en temps réel utilisent typiquement une chronologie de présentation virtuelle dérivée du temps horloge pour déterminer quand la trame suivante ou une autre unité de chaque média dans les données stockées doit être présentée. Dans ce cas, l'horodatage RTP refléterait le temps de présentation pour chaque unité. C'est-à-dire que l'horodatage RTP pour chaque unité serait relié au temps horloge auquel l'unité devient courante sur la chronologie de présentation virtuelle. La présentation réelle survient un certain temps plus tard tel que déterminé par le récepteur.

    Un exemple décrivant la narration audio en direct d'une vidéo préenregistrée illustre l'importance de choisir l'instant d'échantillonnage comme point de référence. Dans ce scénario, la vidéo serait présentée localement pour que le narrateur la visionne et serait simultanément transmise en utilisant RTP. L'« instant d'échantillonnage » d'une trame vidéo transmise en RTP serait établi en référençant son horodatage au temps horloge où cette trame vidéo a été présentée au narrateur. L'instant d'échantillonnage pour les paquets audio RTP contenant la parole du narrateur serait établi en référençant le même temps horloge où l'audio a été échantillonné. L'audio et la vidéo peuvent même être transmis par des hôtes différents si les horloges de référence des deux hôtes sont synchronisées par un moyen quelconque tel que NTP. Un récepteur peut alors synchroniser la présentation des paquets audio et vidéo en reliant leurs horodatages RTP à l'aide des paires d'horodatages dans les paquets RTCP SR.

  • SSRC : 32 bits. Le champ SSRC identifie la source de synchronisation. Cet identificateur DEVRAIT être choisi aléatoirement, dans l'intention qu'aucune des sources de synchronisation au sein de la même session RTP n'ait le même identificateur SSRC. Un exemple d'algorithme pour générer un identificateur aléatoire est présenté à l'appendice A.6. Bien que la probabilité que plusieurs sources choisissent le même identificateur soit faible, toutes les implémentations RTP doivent être prêtes à détecter et résoudre les collisions. La section 8 décrit la probabilité de collision ainsi qu'un mécanisme pour résoudre les collisions et détecter les boucles de transfert au niveau RTP basées sur l'unicité de l'identificateur SSRC. Si une source change son adresse de transport source, elle doit également choisir un nouvel identificateur SSRC pour éviter d'être interprétée comme une source en boucle (voir la section 8.2).

  • liste CSRC : 0 à 15 éléments, 32 bits chacun. La liste CSRC identifie les sources contributrices pour la charge utile contenue dans ce paquet. Le nombre d'identificateurs est donné par le champ CC. S'il y a plus de 15 sources contributrices, seules 15 peuvent être identifiées. Les identificateurs CSRC sont insérés par les mélangeurs (voir la section 7.1), en utilisant les identificateurs SSRC des sources contributrices. Par exemple, pour les paquets audio, les identificateurs SSRC de toutes les sources qui ont été mélangées ensemble pour créer un paquet sont listés, permettant une indication correcte du locuteur au récepteur.

5.2 Multiplexing RTP Sessions (Multiplexage des sessions RTP)​

Pour un traitement de protocole efficace, le nombre de points de multiplexage devrait être minimisé, comme décrit dans le principe de conception du traitement de couche intégré [10]. Dans RTP, le multiplexage est fourni par l'adresse de transport de destination (adresse réseau et numéro de port) qui est différente pour chaque session RTP. Par exemple, dans une téléconférence composée de médias audio et vidéo encodés séparément, chaque média DEVRAIT être transporté dans une session RTP séparée avec sa propre adresse de transport de destination.

Les flux audio et vidéo séparés NE DEVRAIENT PAS être transportés dans une seule session RTP et démultiplexés sur la base du type de charge utile ou des champs SSRC. Entrelacer des paquets avec différents types de média RTP mais utilisant le même SSRC introduirait plusieurs problèmes :

  1. Si, disons, deux flux audio partageaient la même session RTP et la même valeur SSRC, et que l'un changeait d'encodage et acquérait ainsi un type de charge utile RTP différent, il n'y aurait aucun moyen général d'identifier quel flux avait changé d'encodage.

  2. Un SSRC est défini pour identifier un seul espace de temporisation et de numéros de séquence. Entrelacer plusieurs types de charge utile nécessiterait des espaces de temporisation différents si les fréquences d'horloge média diffèrent, et nécessiterait des espaces de numéros de séquence différents pour dire quel type de charge utile a subi une perte de paquets.

  3. Les rapports RTCP émetteur et récepteur (voir la section 6.4) ne peuvent décrire qu'un seul espace de temporisation et de numéros de séquence par SSRC et ne transportent pas de champ de type de charge utile.

  4. Un mélangeur RTP ne serait pas capable de combiner des flux entrelacés de médias incompatibles en un seul flux.

  5. Transporter plusieurs médias dans une seule session RTP empêche : l'utilisation de chemins réseau ou d'allocations de ressources réseau différents si approprié ; la réception d'un sous-ensemble des médias si désiré, par exemple seulement l'audio si la vidéo dépasserait la bande passante disponible ; et des implémentations de récepteur qui utilisent des processus séparés pour les différents médias, alors que l'utilisation de sessions RTP séparées permet des implémentations à processus unique ou multiple.

Utiliser un SSRC différent pour chaque média mais les envoyer dans la même session RTP éviterait les trois premiers problèmes mais pas les deux derniers.

D'un autre côté, multiplexer plusieurs sources liées du même média dans une session RTP en utilisant différentes valeurs SSRC est la norme pour les sessions multicast. Les problèmes listés ci-dessus ne s'appliquent pas : un mélangeur RTP peut combiner plusieurs sources audio, par exemple, et le même traitement est applicable pour toutes. Il peut également être approprié de multiplexer des flux du même média en utilisant différentes valeurs SSRC dans d'autres scénarios où les deux derniers problèmes ne s'appliquent pas.

5.3 Profile-Specific Modifications to the RTP Header (Modifications spécifiques au profil de l'en-tête RTP)​

On pense que l'en-tête de paquet de données RTP existant est complet pour l'ensemble des fonctions requises en commun à travers toutes les classes d'applications que RTP pourrait prendre en charge. Toutefois, conformément au principe de conception ALF, l'en-tête PEUT être adapté par des modifications ou des ajouts définis dans une spécification de profil tout en permettant à des outils de surveillance et d'enregistrement indépendants du profil de fonctionner.

  • Le bit de marqueur et le champ de type de charge utile portent des informations spécifiques au profil, mais ils sont alloués dans l'en-tête fixe car de nombreuses applications sont censées en avoir besoin et devraient autrement ajouter un autre mot de 32 bits juste pour les contenir. L'octet contenant ces champs PEUT être redéfini par un profil pour répondre à différentes exigences, par exemple avec plus ou moins de bits de marqueur. S'il y a des bits de marqueur, l'un DEVRAIT être situé dans le bit le plus significatif de l'octet car des moniteurs indépendants du profil peuvent être capables d'observer une corrélation entre les motifs de perte de paquets et le bit de marqueur.

  • Des informations supplémentaires requises pour un format de charge utile particulier, tel qu'un encodage vidéo, DEVRAIENT être transportées dans la section de charge utile du paquet. Cela peut être dans un en-tête toujours présent au début de la section de charge utile, ou peut être indiqué par une valeur réservée dans le motif de données.

  • Si une classe particulière d'applications a besoin d'une fonctionnalité supplémentaire indépendante du format de charge utile, le profil sous lequel ces applications opèrent DEVRAIT définir des champs fixes supplémentaires à placer immédiatement après le champ SSRC de l'en-tête fixe existant. Ces applications seront capables d'accéder rapidement et directement aux champs supplémentaires tandis que des moniteurs ou enregistreurs indépendants du profil peuvent toujours traiter les paquets RTP en n'interprétant que les douze premiers octets.

S'il s'avère qu'une fonctionnalité supplémentaire est nécessaire en commun à travers tous les profils, alors une nouvelle version de RTP devrait être définie pour apporter une modification permanente à l'en-tête fixe.

5.3.1 RTP Header Extension (Extension d'en-tête RTP)​

Un mécanisme d'extension est fourni pour permettre à des implémentations individuelles d'expérimenter avec de nouvelles fonctions indépendantes du format de charge utile qui nécessitent des informations supplémentaires à transporter dans l'en-tête du paquet de données RTP. Ce mécanisme est conçu de sorte que l'extension d'en-tête peut être ignorée par d'autres implémentations interopérables qui n'ont pas été étendues.

Notez que cette extension d'en-tête est destinée à un usage limité uniquement. La plupart des utilisations potentielles de ce mécanisme seraient mieux faites d'une autre manière, en utilisant les méthodes décrites dans la section précédente. Par exemple, une extension spécifique au profil de l'en-tête fixe est moins coûteuse à traiter car elle n'est pas conditionnelle ni à un emplacement variable. Des informations supplémentaires requises pour un format de charge utile particulier NE DEVRAIENT PAS utiliser cette extension d'en-tête, mais DEVRAIENT être transportées dans la section de charge utile du paquet.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      defined by profile       |           length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        header extension                       |
|                             ....                              |

Si le bit X dans l'en-tête RTP vaut un, une extension d'en-tête de longueur variable DOIT être ajoutée à l'en-tête RTP, à la suite de la liste CSRC si elle est présente. L'extension d'en-tête contient un champ de longueur de 16 bits qui compte le nombre de mots de 32 bits dans l'extension, en excluant l'en-tête d'extension de quatre octets (ainsi zéro est une longueur valide). Une seule extension peut être ajoutée à l'en-tête de données RTP. Pour permettre à plusieurs implémentations interopérables d'expérimenter chacune indépendamment avec différentes extensions d'en-tête, ou de permettre à une implémentation particulière d'expérimenter avec plus d'un type d'extension d'en-tête, les 16 premiers bits de l'extension d'en-tête sont laissés ouverts pour des identificateurs ou paramètres de distinction. Le format de ces 16 bits est à définir par la spécification de profil sous laquelle les implémentations opèrent. Cette spécification RTP ne définit elle-même aucune extension d'en-tête.