RTP : protocole de transport - RFC

RFC 3550 page - 8 - Schulzrinne & autresparagraphe 5.3).type de charge utile (PT) : 7 bitsCe champ identifie le format de la charge utile RTP et détermine son interprétation par l'application. Un profil PEUTspécifier une transposition statique par défaut des codes de type de charge utile en formats de charge utile. Des types decodes de charge utile PEUVENT être définis de façon dynamique par des moyens non RTP (voir la Section 3). Unensemble de transpositions par défaut pour l'audio et la vidéo est spécifié dans la RFC 3551 [1]. Une source RTP PEUTchanger le type de charge utile durant une session, mais ce champ NE DEVRAIT PAS être utilisé pour multiplexer des fluxde supports distincts (voir au paragraphe 5.2).Un receveur DOIT ignorer les paquets avec des types de charge utile qu'il ne comprend pas.type de charge utile : 16 bitsLe type de charge utile s'incrémente de un pour chaque paquet de données RTP envoyé, et peut être utilisé par le receveurpour détecter la perte de paquet et pour restaurer la séquence de paquets. La valeur initiale du type de charge utileDEVRAIT être aléatoire (imprévisible) pour rendre plus difficiles les attaques de libellé en clair connu contre lechiffrement, même si la source elle-même ne chiffre pas selon la méthode spécifiée au paragraphe 9.1, parce que lespaquets peuvent s'écouler à travers un traducteur qui le fait. Les techniques de choix de nombres imprévisibles sontexposées dans [17].horodatage : 32 bitsL'horodatage reflète le moment d'échantillonnage du premier octet dans le paquet de données RTP. Le momentd'échantillonnage DOIT être déduit d'une horloge qui incrémente le temps de façon monotone et linéaire pour permettre lescalculs de synchronisation et de gigue (voir au paragraphe 6.4.1). La résolution de l'horloge DOIT être suffisante pour laprécision de synchronisation désirée et pour mesurer la gigue d'arrivée des paquets (un tic par trame vidéo n'estnormalement pas suffisant). La fréquence d'horloge dépend du format des données portées comme charge utile et elle estspécifiée de façon statique dans le profil ou la spécification de format de charge utile qui définit le format, ou PEUT êtrespécifiée de façon dynamique pour les formats de charge utile définis par des moyens non RTP. Si les paquets RTP sontgénérés de façon périodique, on doit utiliser le moment d'échantillonnage nominal tel que déterminé à partir de l'horloged'échantillonnage et non par lecture de l'horloge système. Par exemple, pour de l'audio à débit fixe, l'horloge d'horodatageva vraisemblablement s'incrémenter de un pour chaque période d'échantillonnage. Si une application audio lit des blocscouvrant 160 périodes d'échantillonnage à partir de l'appareil d'entrée, l'horodatage serait augmenté de 160 pour chaquebloc de cette sorte, sans considération du fait que le bloc est transmis dans un paquet ou abandonné parce que silencieux.La valeur initiale de l'horodatage DEVRAIT être aléatoire, comme pour le type de charge utile. Plusieurs paquets RTPconsécutifs auront des horodatages égaux si ils sont (logiquement) générés en une seule fois, par exemple, appartenant à lamême trame vidéo. Les paquets RTP consécutifs PEUVENT contenir des horodatages qui ne sont pas à croissancemonotone, si les données ne sont pas transmises dans l'ordre dans lequel elles ont été échantillonnées, comme dans le casde trames vidéo MPEG interpolées. (Les types de charge utile des paquets tels que transmis seront toujours monotones.)Les horodatages RTP provenant de différents flux de support peuvent avancer à des vitesses différentes et ont généralementdes décalages indépendants et aléatoires. Donc, bien que ces horodatages soient suffisants pour reconstruire la successiondans le temps d'un seul flux, la comparaison directe des horodatages RTP des différents supports n'est pas efficace pour lasynchronisation. Au lieu de cela, pour chaque support, l'horodatage RTP est rapporté au moment d'échantillonnage enl'appariant à un horodatage provenant de l'horloge de référence (horloge murale) qui représente l'heure à laquelle lesdonnées correspondant à l'horodatage RTP ont été échantillonnées. L'horloge de référence est partagée par tous les supportsà synchroniser. Les paires d'horodatage ne sont pas transmises dans chaque paquet de données, mais à un débit inférieurdans les paquets SR de RTCP, comme décrit au paragraphe 6.4.Le moment d'échantillonnage est choisi comme point de référence pour l'horodatage RTP parce qu'il est connu du pointd'extrémité de transmission et a une définition commune pour tous les supports, indépendamment des délais de codage ouautres traitements. L'objectif est de permettre une présentation synchronisée de tous les supports échantillonnés au mêmemoment.Les applications qui transmettent les données mémorisées plutôt que les données échantillonnées en temps réel utilisentnormalement une présentation virtuelle du temps dérivée de l'heure de l'horloge murale pour déterminer quand la prochainetrame ou autre unité de chaque support des données mémorisées devrait être présentée. Dans ce cas, l'horodatage RTPreflètera le moment de présentation pour chaque unité. C'est-à-dire, l'horodatage RTP pour chaque unité sera relaté à l'heurede l'horloge murale à laquelle l'unité devient actuelle sur le plan temporel de présentation virtuelle. La présentation réellesurvient un petit peu après, comme déterminé par le receveur.Un exemple qui décrit la narration audio en direct de vidéo préenregistrée illustre la signification du choix du momentd'échantillonnage comme point de référence. Dans ce scénario, la vidéo serait présentée localement pour que le narrateur lavoit et serait simultanément transmise en utilisant RTP. Le "moment d'échantillonnage" d'une trame vidéo transmise en