RTP : protocole de transport - RFC

RFC 3550 page - 40 - Schulzrinne & autresRTCP est comparé à l'octet correspondant de l'en-tête RTP, cette gamme correspond au bit marqueur mis à 1 (ce qui n'estpas habituel dans les paquets de données) et au bit de poids fort du champ Type de charge utile standard mis à 1 (car le typede charge utile statique est normalement défini dans la moitié de poids faible). Cette gamme a aussi été choisie commeétant numériquement à une certaine distance de 0 et 255 car les schémas tout à zéro et tout à un sont courants dans lesschémas de données.Comme tous les paquets RTCP composés DOIVENT commencer par SR ou RR, ces codes ont été choisis comme une pairepair/impair pour permettre à la vérification de validité RTCP de tester le nombre maximum de bits avec gabarit et valeur.Des types supplémentaires de paquet RTCP peuvent être enregistrés auprès de l'IANA (voir la Section 15).12.2 Types de SDESabréviation nom valeurEND fin de liste SDES 0CNAME nom canonique 1NAME nom d'utilisateur 2EMAIL adresse de messagerie électronique de l'utilisateur 3PHONE numéro de téléphone de l'utilisateur 4LOC localisation géographique de l'utilisateur 5TOOL nom de l'application ou de l'outil 6NOTE remarque sur la source 7PRIV extensions privées 8Des types de SDES supplémentaires peuvent être enregistrés auprès de l'IANA (voir la Section 15).13. Profils RTP et spécifications de format de charge utileUne spécification complète de RTP pour une application particulière exigera un ou plusieurs documents d'accompagnementde deux types décrits ici : profils, et spécification de format de charge utile.RTP peut être utilisé pour diverses applications qui ont des exigences quelque peu différentes. La souplesse pour s'adapter àces exigences est fournie en permettant des choix multiples dans la spécification principale du protocole, puis ensélectionnant les choix appropriés ou en définissant des extensions pour un environnement et classe d'applicationsparticuliers dans un document de profil distinct. Normalement, une application va fonctionner selon un seul profil dans unesession RTP particulière, de sorte qu'il n'y a pas d'indication explicite au sein du protocole RTP lui-même sur le profilutilisé. Un profil pour des applications audio et vidéo se trouve dans le document d'accompagnement RFC 3551. Les profilssont normalement intitulés "Profil RTP pour ...".Le second type de document d'accompagnement est une spécification de format de charge utile, qui définit comment untype particulier de données de charge utile, tel que de la vidéo codée en H.261, devrait être porté dans RTP. Ces documentssont normalement intitulés "Format de charge utile RTP pour codage audio/vidéo XYZ". Les formats de charge utilepeuvent être utiles sous plusieurs profils et peuvent donc être définis indépendamment de tout profil particulier. Lesdocuments de profil sont alors chargés d'allouer une transposition par défaut de ce format en une valeur de type de chargeutile si nécessaire.Dans la présente spécification, les éléments suivants ont été identifiés pour une éventuelle définition au sein d'un profil,mais cette liste n'a rien d'exhaustif :en-tête de données RTP : l'octet qui dans l'en-tête de données RTP contient le bit marqueur et le champ Type de chargeutile PEUT être redéfini par un profil pour convenir à des exigences différentes, par exemple avec plus ou moins de bitsmarqueurs (paragraphe 5.3).types de charge utile : en supposant qu'un champ Type de charge utile soit inclus, le profil va habituellement définir unensemble de formats de charge utile (par exemple, de codages du support) et une transposition statique par défaut de cesformats en valeurs de type de charge utile. Certains de ces formats de charge utile peuvent être définis par référence à desspécifications de format de charge utile distinctes. Pour chaque type de charge utile défini, le profil DOIT spécifier le débitd'horloge d'horodatage RTP à utiliser (paragraphe 5.1).ajout d'en-tête de données RTP : des champs supplémentaires PEUVENT être ajoutés à l'en-tête fixe de données RTP si