6. Définitions des types de charge utile
- Définitions des types de charge utile
Les tableaux 4 et 5 définissent les valeurs de type de charge utile statiques de ce profil pour le champ PT de l'en-tête de données RTP. De plus, les valeurs de type de charge utile dans la plage 96-127 PEUVENT être définies dynamiquement via un protocole de contrôle de conférence, ce qui dépasse le cadre de ce document. Par exemple, un répertoire de session pourrait spécifier que pour une session donnée, le type de charge utile 96 indique un codage PCMU, une fréquence d' échantillonnage de 8 000 Hz, 2 canaux. Les entrées des tableaux 4 et 5 avec le type de charge utile "dyn" n'ont pas de type de charge utile statique attribué et ne sont utilisées qu'avec un type de charge utile dynamique. Le type de charge utile 2 a été attribué à G721 dans la RFC 1890 et à son successeur équivalent G726-32 dans les versions préliminaires de cette spécification, mais son utilisation est maintenant obsolète et ce type de charge utile statique est marqué réservé en raison d'une utilisation conflictuelle pour les formats de charge utile G726-32 et AAL2-G726-32 (voir section 4.5.4). Le type de charge utile 13 indique le format de charge utile Comfort Noise (CN) spécifié dans la RFC 3389 [9]. Le type de charge utile 19 est marqué "réservé" car certaines versions préliminaires de cette spécification ont attribué ce numéro à une version antérieure du format de charge utile de bruit de confort. La plage de types de charge utile 72-76 est marquée "réservée" afin que les paquets RTCP et RTP puissent être distingués de manière fiable (voir la section "Résumé des constantes de protocole" de la spécification du protocole RTP).
Les types de charge utile actuellement définis dans ce profil sont attribués à exactement l'une des trois catégories ou types de médias : audio uniquement, vidéo uniquement et ceux combinant audio et vidéo. Les types de médias sont marqués dans les tableaux 4 et 5 respectivement comme "A", "V" et "AV". Les types de charge utile de différents types de médias NE DOIVENT PAS être entrelacés ou multiplexés dans une seule session RTP, mais plusieurs sessions RTP PEUVENT être utilisées en parallèle pour envoyer plusieurs types de médias. Une source RTP PEUT changer de types de charge utile au sein du même type de média au cours d'une session. Voir la section "Multiplexage des sessions RTP" de la RFC 3550 pour des explications supplémentaires.
PT nom de type de taux loge canaux
l'encodage média (Hz)
___________________________________________________
0 PCMU A 8 000 1
1 réservé A
2 réservé A
3 GSM A 8 000 1
4 G723 A 8 000 1
5 DVI4 A 8 000 1
6 DVI4 A 16 000 1
7 LPC A 8 000 1
8 PCMA A 8 000 1
9 G722 A 8 000 1
10 L16 A 44 100 2
11 L16 A 44 100 1
12 QCELP A 8 000 1
13 CN A 8 000 1
14 MPA A 90,000 (voir texte)
15 G728 A 8 000 1
16 DVI4 A 11 025 1
17 DVI4 A 22 050 1
18 G729 A 8 000 1
19 réservé A
20 non attribué A
21 non attribué A
22 non attribué A
23 non attribué A
dyn G726-40 A 8 000 1
dyn G726-32 A 8 000 1
dyn G726-24 A 8 000 1
dyn G726-16 A 8 000 1
dyn G729D A 8 000 1
dyn G729E A 8 000 1
dyn GSM-EFR A 8 000 1
dyn L8 A var. var.
dyn RED A (voir texte)
dyn VDVI A var. 1
Tableau 4 : Types de charge utile (PT) pour les encodages audio
PT nom de type de fréquence horloge
l'encodage média (Hz)
_____________________________________________
24 non attribué V
25 CelB V 90 000
26 JPEG V 90 000
27 non attribué V
28 nv V 90 000
29 non attribué V
30 non attribué V
31 H261 V 90 000
32 MPV V 90 000
33 MP2T AV 90 000
34 H263 V 90 000
35-71 non attribué ?
72-76 réservé N/A N/A
77-95 non attribué ?
96-127 dynamique ?
dyn H263-1998 V 90 000
Tableau 5 : Types de charge utile (PT) pour les encodages vidéo
et combinés
Les participants à la session conviennent, par des mécanismes dépassant le cadre de cette spécification, de l'ensemble des types de charge utile autorisés dans une session donnée. Cet ensemble PEUT, par exemple, être défini par les capacités des applications utilisées, négocié par un protocole de contrôle de conférence ou établi par accord entre les participants humains.
Les applications audio fonctionnant sous ce profil DOIVENT, au minimum, être capables d'envoyer et/ou de recevoir des types de charge utile 0 (PCMU) et 5 (DVI4). Cela permet une interopérabilité sans négociation de format et garantit une négociation réussie avec un protocole de contrôle de conférence.