Les Paramètres RTP – Payload Type (PT)

Le but de RTP et de fournir un moyen uniforme de transmettre sur IP des données soumises à des contraintes de temps réel (audio, vidéo, etc.).

RTP permet :

  • d’identifier le type de l’information transportée,
  • d’ajouter des marqueurs temporels permettant d’indiquer l’instant d’émission du paquet. L’application destinataire peut alors synchroniser les flux et mesurer les délais et la gigue.
  • d’inclure des numéros de séquence à l’information transportée afin de détecter
    l’occurrence de paquets perdus et de délivrer les paquets en séquence à l’application
    destinataire.

De plus, RTP peut être véhiculé par des paquets multicast afin d’acheminer des conversations vers des destinataires multiples.

Mais, RTP n’a pas été conçu pour effectuer des réservations de ressources ou contrôler la qualité de service et ne garantit pas la livraison du paquet à l’arrivée.

Vous trouverez en bas de page un rapide récapitulatif sur les en-tête RTP, les types de payload.

Types de charge utile RTP (PT) pour les encodages audio et vidéo standard

Ce tableau vous permet de rechercher des informations sur les algorithmes de codage décodage audio/vidéo dit CODEC. Vous trouverez en bas de page un rapide récapitulatif sur les algorithmes de codage et l’encapsulation.

  • PT (Payload Type number)
  • Nom du codec 
  • Type de codec (audio ou vidéo) 
  • Taux d’échantillonnage
  • Canal (pour audio)
  • Référence RFC 
Payload type (PT)Nom du codecTypeNo. of channelsClock rate (Hz)Frame size (ms)Default packet size (ms)DescriptionReferences
0PCMUaudio18000any20ITU-T G.711 PCM μ-Law audio 64 kbit/sRFC 3551
1reserved (previously FS-1016 CELP)audio18000reserved, previously FS-1016 CELP audio 4.8 kbit/sRFC 3551, previously RFC 1890
2reserved (previously G721 or G726-32)audio18000reserved, previously ITU-T G.721 ADPCM audio 32 kbit/s or ITU-T G.726 audio 32 kbit/sRFC 3551, previously RFC 1890
3GSMaudio180002020European GSM Full Rate audio 13 kbit/s (GSM 06.10)RFC 3551
4G723audio180003030ITU-T G.723.1 audioRFC 3551
5DVI4audio18000any20IMA ADPCM audio 32 kbit/sRFC 3551
6DVI4audio116000any20IMA ADPCM audio 64 kbit/sRFC 3551
7LPCaudio18000any20Experimental Linear Predictive Coding audio 5.6 kbit/sRFC 3551
8PCMAaudio18000any20ITU-T G.711 PCM A-Law audio 64 kbit/sRFC 3551
9G722audio18000[note 2]any20ITU-T G.722 audio 64 kbit/sRFC 3551 - Page 14
10L16audio244100any20Linear PCM 16-bit Stereo audio 1411.2 kbit/s,[2][3][4] uncompressedRFC 3551, Page 27
11L16audio144100any20Linear PCM 16-bit audio 705.6 kbit/s, uncompressedRFC 3551, Page 27
12QCELPaudio180002020Qualcomm Code Excited Linear PredictionRFC 2658, RFC 3551
13CNaudio18000Comfort noise. Payload type used with audio codecs that do not support comfort noise as part of the codec itself such as G.711, G.722.1, G.722, G.726, G.727, G.728, GSM 06.10, Siren, and RTAudio.RFC 3389
14MPAaudio1, 2900008–72MPEG-1 or MPEG-2 audio onlyRFC 3551, RFC 2250
15G728audio180002.520ITU-T G.728 audio 16 kbit/sRFC 3551
16DVI4audio111025any20IMA ADPCM audio 44.1 kbit/sRFC 3551
17DVI4audio122050any20IMA ADPCM audio 88.2 kbit/sRFC 3551
18G729audio180001020ITU-T G.729 and G.729a audio 8 kbit/s; Annex B is implied unless the annexb=no parameter is usedRFC 3551, Page 20, RFC 3555, Page 15
19reserved (previously CN)audioreserved, previously comfort noiseRFC 3551
25CELBvideo90000Sun CellB video[5]RFC 2029
26JPEGvideo90000JPEG videoRFC 2435
28nvvideo90000Xerox PARC's Network Video (nv)[6]RFC 3551, Page 32
31H261video90000ITU-T H.261 videoRFC 4587
32MPVvideo90000MPEG-1 and MPEG-2 videoRFC 2250
33MP2Taudio/video90000MPEG-2 transport streamRFC 2250
34H263video90000H.263 video, first version (1996)RFC 3551, RFC 2190
72–76reservedreserved because RTCP packet types 200–204 would otherwise be indistinguishable from RTP payload types 72–76 with the marker bit setRFC 3550, RFC 3551
dynamicH263-1998video90000H.263 video, second version (1998)RFC 3551, RFC 4629, RFC 2190
dynamicH263-2000video90000H.263 video, third version (2000)RFC 4629
dynamic (or profile)H264 AVCvideo90000H.264 video (MPEG-4 Part 10)RFC 6184, previously RFC 3984
dynamic (or profile)H264 SVCvideo90000H.264 videoRFC 6190
dynamic (or profile)H265video90000H.265 video (HEVC)RFC 7798
dynamic (or profile)theoravideo90000Theora videodraft-barbato-avt-rtp-theora
dynamiciLBCaudio1800020, 3020, 30Internet low Bitrate Codec 13.33 or 15.2 kbit/sRFC 3952
dynamicPCMA-WBaudio1160005ITU-T G.711.1 A-lawRFC 5391
dynamicPCMU-WBaudio1160005ITU-T G.711.1 μ-lawRFC 5391
dynamicG718audio32000 (placeholder)20ITU-T G.718draft-ietf-payload-rtp-g718
dynamicG719audio(various)4800020ITU-T G.719RFC 5404
dynamicG7221audio16000, 3200020ITU-T G.722.1 and G.722.1 Annex CRFC 5577
dynamicG726-16audio18000any20ITU-T G.726 audio 16 kbit/sRFC 3551
dynamicG726-24audio18000any20ITU-T G.726 audio 24 kbit/sRFC 3551
dynamicG726-32audio18000any20ITU-T G.726 audio 32 kbit/sRFC 3551
dynamicG726-40audio18000any20ITU-T G.726 audio 40 kbit/sRFC 3551
dynamicG729Daudio180001020ITU-T G.729 Annex DRFC 3551
dynamicG729Eaudio180001020ITU-T G.729 Annex ERFC 3551
dynamicG7291audio1600020ITU-T G.729.1RFC 4749
dynamicGSM-EFRaudio180002020ITU-T GSM-EFR (GSM 06.60)RFC 3551
dynamicGSM-HR-08audio1800020ITU-T GSM-HR (GSM 06.20)RFC 5993
dynamic (or profile)AMRaudio(various)800020Adaptive Multi-Rate audioRFC 4867
dynamic (or profile)AMR-WBaudio(various)1600020Adaptive Multi-Rate Wideband audio (ITU-T G.722.2)RFC 4867
dynamic (or profile)AMR-WB+audio1, 2 or omit7200013.3–40Extended Adaptive Multi Rate – WideBand audioRFC 4352
dynamic (or profile)vorbisaudio(various)(various)Vorbis audioRFC 5215
dynamic (or profile)opusaudio1, 248000[note 3]2.5–6020Opus audioRFC 7587
dynamic (or profile)speexaudio18000, 16000, 3200020Speex audioRFC 5574
dynamicmpa-robustaudio1, 29000024–72Loss-Tolerant MP3 audioRFC 5219 (previously RFC 3119)
dynamic (or profile)MP4A-LATMaudio90000 or othersMPEG-4 AudioRFC 6416 (previously RFC 3016)
dynamic (or profile)MP4V-ESvideo90000 or othersMPEG-4 VisualRFC 6416 (previously RFC 3016)
dynamic (or profile)mpeg4-genericaudio/video90000 or otherMPEG-4 Elementary StreamsRFC 3640
dynamicVP8video90000VP8 videoRFC 7741
dynamicVP9video90000VP9 videodraft-ietf-payload-vp9
dynamicL8audio(various)(various)any20Linear PCM 8-bit audio with 128 offsetRFC 3551 Section 4.5.10 and Table 5
dynamicDAT12audio(various)(various)any20 (by analogy with L16)IEC 61119 12-bit nonlinear audioRFC 3190 Section 3
dynamicL16audio(various)(various)any20Linear PCM 16-bit audioRFC 3551 Section 4.5.11, RFC 2586
dynamicL20audio(various)(various)any20 (by analogy with L16)Linear PCM 20-bit audioRFC 3190 Section 4
dynamicL24audio(various)(various)any20 (by analogy with L16)Linear PCM 24-bit audioRFC 3190 Section 4
dynamicrawvideo90000Uncompressed VideoRFC 4175
dynamicac3audio(various)32000, 44100, 48000Dolby AC-3 audioRFC 4184
dynamiceac3audio(various)32000, 44100, 48000Enhanced AC-3 audioRFC 4598
dynamict140text1000Text over IPRFC 4103
dynamicEVRCaudio8000EVRC audioRFC 4788
EVRC0
EVRC1
dynamicEVRCBaudio8000EVRC-B audioRFC 4788
EVRCB0
EVRCB1
dynamicEVRCWBaudio16000EVRC-WB audioRFC 5188
EVRCWB0
EVRCWB1
dynamicjpeg2000video90000JPEG 2000 videoRFC 5371
dynamicUEMCLIPaudio8000, 16000UEMCLIP audioRFC 5686
dynamicATRAC3audio44100ATRAC3 audioRFC 5584
dynamicATRAC-Xaudio44100, 48000ATRAC3+ audioRFC 5584
dynamicATRAC-ADVANCED-LOSSLESSaudio(various)ATRAC Advanced Lossless audioRFC 5584
dynamicDVvideo90000DV videoRFC 6469 (previously RFC 3189)
dynamicBT656videoITU-R BT.656 videoRFC 3555
dynamicBMPEGvideoBundled MPEG-2 videoRFC 2343
dynamicSMPTE292MvideoSMPTE 292M videoRFC 3497
dynamicREDaudioRedundant Audio DataRFC 2198
dynamicVDVIaudioVariable-rate DVI4 audioRFC 3551
dynamicMP1SvideoMPEG-1 Systems Streams videoRFC 2250
dynamicMP2PvideoMPEG-2 Program Streams videoRFC 2250
dynamictoneaudio8000 (default)toneRFC 4733
dynamictelephone-eventaudio8000 (default)DTMF toneRFC 4733
dynamicaptxaudio2 – 6(equal to sampling rate)4000 ÷ sample rate4[note 4]aptX audioRFC 7310

Types de supports au format de charge utile RTP

En plus des formats de charge utile RTP (encodages) répertoriés dans le tableau Types de charge utile RTP ci dessus , il existe des formats de charge utile supplémentaires auxquels aucun type de charge utile RTP statique n’est affecté, mais qui utilisent à la place une attribution de numéro de type de charge utile dynamique . Chaque format de charge utile est nommé par un sous-type de support enregistré , comme indiqué dans le tableau suivant. Comme de nouveaux formats de charge utile sont spécifiés, leurs sous-types de supports enregistrés doivent être ajoutés à ce tableau. De plus, pour les formats de charge utile répertoriés dans le tableau Types de charge utile RTP ci-dessus, le “nom de codage” est également enregistré en tant que sous-type de support sous le type de support “audio” ou “vidéo”. La fréquence d’horloge et le nombre de canaux indiqués ici sont les valeurs normales pour ces charges utiles formats qui ont une valeur normale. Les noms de type et de sous-type ne respectent pas la casse comme défini dans la RFC4288.

Type de médiaSous-TypeClock Rate (Hz)Channels (audio)Reference - RFC
application1d-interleaved-parityfec[RFC6015]
applicationh2244800[RFC4573]
applicationparityfec[RFC3009]
applicationraptorfec[RFC6682]
applicationrtx[RFC4588]
applicationsmpte336m[RFC6597]
applicationulpfec[RFC5109]
audio1d-interleaved-parityfec[RFC6015]
audio32kadpcm8000[RFC3802][RFC2421]
audioac3[RFC4184]
audioAMR8000[RFC4867][RFC3267]
audioAMR-WB16000[RFC4867][RFC3267]
audioamr-wb+72000[RFC4352]
audioATRAC-ADVANCED-LOSSLESS[RFC5584]
audioatrac-x[RFC5584]
audioatrac344100[RFC5584]
audioBV168000[RFC4298]
audioBV3216000[RFC4298]
audioclearmode80001[RFC4040]
audioCN[RFC3389]
audioDAT12[RFC3190]
audiodsr-es201108[RFC3557]
audiodsr-es2020508000[RFC4060]
audiodsr-es2022118000[RFC4060]
audiodsr-es2022128000[RFC4060]
audioDV[RFC6469]
audioDVI4[RFC4856]
audioeac3[RFC4598]
audioEVRC80001[RFC4788]
audioEVRC080001[RFC4788]
audioEVRC180001[RFC4788]
audioEVRCB80001[RFC4788]
audioEVRCB080001[RFC4788]
audioEVRCB180001[RFC4788]
audioEVRCWB[RFC5188]
audioEVRCWB0[RFC5188]
audioEVRCWB1[RFC5188]
audiofwdred[RFC6354]
audiog71948000[RFC5404]
audioG722[RFC4856]
audioG7221160001[RFC5577]
audioG723[RFC4856]
audioG726-1680001[RFC3551][RFC4856]
audioG726-2480001[RFC3551][RFC4856]
audioG726-3280001[RFC3551][RFC4856]
audioG726-4080001[RFC3551][RFC4856]
audioG728[RFC4856]
audioG729[RFC4856]
audioG729116000[RFC4749][RFC5459]
audioG729D80001[RFC3551][RFC4856]
audioG729E80001[RFC3551][RFC4856]
audioGSM[RFC4856]
audioGSM-EFR80001[RFC3551][RFC4856]
audioGSM-HR-088000[RFC5993]
audioiLBC8000[RFC3952]
audioip-mr_v2.516000[RFC6262]
audioL8[RFC3551][RFC4856]
audioL16[RFC4856]
audioL20[RFC3190]
audioL24[RFC3190]
audioLPC[RFC4856]
audioMELP80001[RFC8130]
audioMELP60080001[RFC8130]
audioMELP120080001[RFC8130]
audioMELP240080001[RFC8130]
audioMP4A-LATM[RFC3016]
audioMPA90000[RFC3555]
audiompa-robust90000[RFC5219]
audiompeg4-generic[RFC3640][RFC5691][RFC6295]
audioparityfec[RFC5109]
audioPCMA[RFC4856]
audioPCMA-WB16000[RFC5391]
audioPCMU[RFC4856]
audioPCMU-WB16000[RFC5391]
audioQCELP[RFC3555]
audioraptorfec[RFC6682]
audioRED[RFC2198][RFC3555]
audiortp-midi[RFC6295]
audiortx[RFC4588]
audioSMV80001[RFC3558]
audioSMV080001[RFC3558]
audiospeex[RFC5574]
audiot140c[RFC4351]
audiot38[RFC4612]
audiotelephone-event[RFC4733]
audiotone[RFC4733]
audiouemclip[RFC5686]
audioulpfec[RFC5109]
audioVDVI1[RFC3551][RFC4856]
audioVMR-WB16000[RFC4348][RFC4424]
audiovorbis[RFC5215]
audiovorbis-config[RFC5215]
text1d-interleaved-parityfec[RFC6015]
textfwdred[RFC6354]
textparityfec[RFC3009]
textraptorfec[RFC6682]
textred1000[RFC4102]
textrtx[RFC4588]
textt1401000[RFC4103]
textulpfec[RFC5109]
videoBMPEG90000[RFC2343][RFC3555]
video1d-interleaved-parityfec[RFC6015]
video3gpp-tt[RFC4396]
videoBT65690000[RFC2431][RFC3555]
videocelB[RFC3555]
videoDV90000[RFC6469]
videoH261[RFC4587]
videoH26390000[RFC4628]
videoH263-199890000[RFC4629]
videoH263-200090000[RFC4629]
videoH264[RFC6184]
videoH264-RCDO90000[RFC6185]
videoH264-SVC[RFC6190]
videoJPEG[RFC3555]
videoJPEG2000[RFC5371]
videoMP1S90000[RFC2250][RFC3555]
videoMP2P90000[RFC2250][RFC3555]
videoMP2T[RFC3555]
videoMP4V-ES90000[RFC3016]
videompeg4-generic[RFC3640]
videoMPV[RFC3555]
videonv[RFC4856]
videoparityfec[RFC5109]
videopointer90000[RFC2862]
videoraptorfec[RFC6682]
videoraw90000[RFC4175]
videortx[RFC4588]
videoSMPTE292M[RFC3497]
videoulpfec[RFC5109]
videovc190000[RFC4425]
videovc290000[RFC8450]

PETIT RÉCAPITULATIF :

Comme l’audio et la vidéo brut peuvent prendre beaucoup de place, il est nécessaire de les encodées avant qu’ils ne passe dans le réseau par l’intermédiaire des algorithmes de codage dit des codecs. Différents codecs produisent des qualité audio et vidéo différentes, et consomment différents niveaux de bande passante. Certains utilisent plus de processeur que d’autres. Il est donc important d’utiliser le bon codec pour une communication la plus fluide.

Lorsque vous avez besoin d’envoyer des données par l’intermédiaire d’un réseau, les données sont besoin d’être ‘paquetisées’. Le ‘package’ contient des informations qui permettent aux données d’être envoyées vers leur destination et d’être reconstruites correctement. Comme on peut l’imaginer, la ‘paquetisation’ ne se fait pas sans utilisation de la bande passante.

Il existe différentes couches de paquets réseau. Les flux audio et vidéo encodés ont besoin d’être encapsulés dans des paquets RTP , les paquets RTP ont besoin d’être encapsulés à l’intérieur de paquets UDP qui sont eux même encapsulés dans des paquets IP ces derniers sont alors envoyés via un protocole de la couche de liaison, Ethernet.

Exemple d’encapsulation d’un flux audio encodé

Le Type de Payload (PT)

Compte tenu du nombre important de normes de codage de signaux audio ou vidéo il est essentiel d’inclure un mécanisme à RTP afin de permettre au destinataire de connaître le codage utilisé et ainsi pouvoir décoder correctement. RTP réalise cette fonction grâce au numéro de type de contenu (payload type number) dans le header (en-tête) RTP.

Le Format du paquet RTP

L’en-tête d’un paquet RTP (RTP header) est obligatoirement constitué de 12 octets, éventuellement suivi d’une liste d’identificateurs de sources contributives CSRCs dans le cas d’un mixer. Cet en-tête précède le “payload” qui représente les données utiles (Figure 2).

L’en-tête RTP en détails

  • Version (V) (2 bits) : Ce champ indique le numéro de version RTP utilisée. La version
    actuelle est la version 2.
  • Padding (P) (1 bit) : Si positionné à 1, ce champ signifie que le champ des données
    (payload) a une partie de bourrage. Rappelons que la longueur des données doit être un
    multiple de 4 octets, d’où la nécessité d’octets de bourrage, notamment pour le dernier
    paquet. Le dernier octet de cette partie de bourrage indique le nombre d’octets de bourrage
    à ignorer.
  • Extension (X) (1 bit) : Si positionné à 1, ce champ indique que l’en-tête fixe a une partie
    d’en-tête supplémentaire.
  • CSRC Count (CC) (4 bits) : Ce champ contient le nombre d’identifiants CSRC qui suivent
    l’en-tête fixe, c’est à dire le nombre de sources contributives liées à ce paquet.
  • Marker (M) (1 bit) : Il s’agit d’un bit de signalisation. Sa signification dépend des données
    transportées.
  • Payload type (PT) (7 bits) : Ce champ identifie le type de contenu (audio, vidéo, etc.) qui
    représente le type de codage d’information véhiculé dans le paquet. La liste est présentée au
    tableau plus haut.
  • Sequence Number (16 bits) : La valeur de ce champ est incrémentée de 1 à chaque
    paquet RTP envoyé alors que sa valeur initiale est aléatoire. Ce champ permet de détecter
    des paquets RTP perdus.
  • TimeStamp (32 bits) : Un protocole comme RTP utilise des estampilles temporelles pour
    dater les paquets émis. Ces informations sont la base de calculs permettant d’évaluer le
    délai et la gigue introduits par un système de communication. La pertinence de ces
    informations dépend toute entière de la précision et de la synchronisation des horloges
    utilisées dans les machines qui vont appuyer leurs calculs sur ces valeurs.
  • Synchronization Source (SSRC) (32 bits) : Ce champ identifie la source ayant produit le
    paquet. Au début d’une session, chaque participant choisit un numéro de SSRC. On parle ici
    de synchronisation car l’échelle de temps installée par la source dans ses paquets va servir
    de repère aux récepteurs pour restituer l’information correctement.
  • Contributing source (CSRC) : 0 à 15 instances de ce champ peuvent être présentes dans
    l’en-tête du paquet RTP. Le nombre est indiqué par le champ CC. Lorsqu’un flux RTP est le
    résultat d’une agrégation par un mixeur RTP de plusieurs flux RTP, la liste des SSRCs ayant
    apporté leur contribution est rajoutée dans l’en-tête des paquets RTP du flux résultant
    (Figure 3).