Aller au contenu principal

13. RTP Profiles and Payload Format Specifications (Profils RTP et spécifications de format de charge utile)

Une spécification complète de RTP pour une application particulière nécessitera un ou plusieurs documents compagnons des deux types décrits ici : des profils, et des spécifications de format de charge utile.

RTP peut être utilisé pour une variété d'applications avec des exigences quelque peu différentes. La flexibilité pour s'adapter à ces exigences est fournie en permettant de multiples choix dans la spécification principale du protocole, puis en sélectionnant les choix appropriés ou en définissant des extensions pour un environnement particulier et une classe d'applications dans un document de profil séparé. Typiquement, une application fonctionnera sous un seul profil dans une session RTP particulière, donc il n'y a aucune indication explicite au sein du protocole RTP lui-même quant au profil utilisé. Un profil pour les applications audio et vidéo se trouve dans le document compagnon RFC 3551. Les profils sont typiquement intitulés « RTP Profile for ... ».

Le second type de document compagnon est une spécification de format de charge utile, qui définit comment un type particulier de données de charge utile, tel qu'une vidéo encodée H.261, doit être transporté dans RTP. Ces documents sont typiquement intitulés « RTP Payload Format for XYZ Audio/Video Encoding ». Les formats de charge utile peuvent être utiles sous de multiples profils et peuvent par conséquent être définis indépendamment de tout profil particulier. Les documents de profil sont alors responsables de l'assignation d'une correspondance par défaut de ce format à une valeur de type de charge utile si nécessaire.

Dans cette spécification, les éléments suivants ont été identifiés pour une définition possible au sein d'un profil, mais cette liste n'est pas exhaustive :

  • En-tête de données RTP : L'octet dans l'en-tête de données RTP qui contient le bit de marqueur et le champ de type de charge utile PEUT être redéfini par un profil pour satisfaire à différentes exigences, par exemple avec plus ou moins de bits de marqueur (section 5.3, p. 18).

  • Types de charge utile : En supposant qu'un champ de type de charge utile est inclus, le profil définira habituellement un ensemble de formats de charge utile (par exemple, encodages média) et une correspondance statique par défaut de ces formats à des valeurs de type de charge utile. Certains des formats de charge utile peuvent être définis par référence à des spécifications de format de charge utile séparées. Pour chaque type de charge utile défini, le profil DOIT spécifier la fréquence d'horloge d'horodatage RTP à utiliser (section 5.1, p. 14).

  • Ajouts à l'en-tête de données RTP : Des champs additionnels PEUVENT être ajoutés à l'en-tête de données RTP fixe si une fonctionnalité supplémentaire est requise au travers de la classe d'applications du profil indépendamment du type de charge utile (section 5.3, p. 18).

  • Extensions d'en-tête de données RTP : Le contenu des 16 premiers bits de la structure d'extension d'en-tête de données RTP DOIT être défini si l'usage de ce mécanisme est autorisé sous le profil pour des extensions spécifiques à l'implémentation (section 5.3.1, p. 18).

  • Types de paquets RTCP : De nouveaux types de paquets RTCP spécifiques à une classe d'application PEUVENT être définis et enregistrés auprès de l'IANA.

  • Intervalle de rapport RTCP : Un profil DEVRAIT spécifier que les valeurs suggérées à la section 6.2 pour les constantes employées dans le calcul de l'intervalle de rapport RTCP seront utilisées. Ce sont la fraction RTCP de la bande passante de session, l'intervalle de rapport minimum, et la répartition de la bande passante entre émetteurs et récepteurs. Un profil PEUT spécifier des valeurs alternatives si elles se sont révélées fonctionner de manière passant à l'échelle.

  • Extension SR/RR : Une section d'extension PEUT être définie pour les paquets RTCP SR et RR s'il y a une information supplémentaire qui devrait être rapportée régulièrement au sujet de l'émetteur ou des récepteurs (section 6.4.3, p. 42 et 43).

  • Usage de SDES : Le profil PEUT spécifier les priorités relatives pour les éléments RTCP SDES à transmettre ou à exclure entièrement (section 6.3.9) ; une syntaxe ou sémantique alternative pour l'élément CNAME (section 6.5.1) ; le format de l'élément LOC (section 6.5.5) ; les sémantiques et l'usage de l'élément NOTE (section 6.5.7) ; ou de nouveaux types d'élément SDES à enregistrer auprès de l'IANA.

  • Sécurité : Un profil PEUT spécifier quels services de sécurité et algorithmes devraient être offerts par les applications, et PEUT fournir des conseils quant à leur usage approprié (section 9, p. 65).

  • Correspondance chaîne-clé : Un profil PEUT spécifier comment un mot de passe ou une phrase secrète fourni par l'utilisateur est mis en correspondance avec une clé de chiffrement.

  • Encombrement : Un profil DEVRAIT spécifier le comportement de contrôle d'encombrement approprié pour ce profil.

  • Protocole sous-jacent : L'usage d'un protocole réseau ou de transport de couche inférieure particulier pour transporter les paquets RTP PEUT être requis.

  • Correspondance de transport : Une correspondance de RTP et RTCP à des adresses de niveau transport, par exemple des ports UDP, autre que la correspondance standard définie à la section 11, p. 68, peut être spécifiée.

  • Encapsulement : Un encapsulement des paquets RTP peut être défini pour permettre le transport de plusieurs paquets de données RTP dans un seul paquet de couche inférieure ou pour fournir une trame au-dessus de protocoles sous-jacents qui ne le font pas déjà (section 11, p. 69).

Il n'est pas attendu qu'un nouveau profil soit requis pour chaque application. Au sein d'une classe d'application, il serait préférable d'étendre un profil existant plutôt que d'en créer un nouveau afin de faciliter l'interopérabilité parmi les applications puisque chacune fonctionnera typiquement sous un seul profil. De simples extensions telles que la définition de valeurs de type de charge utile additionnelles ou de types de paquets RTCP peuvent être accomplies en les enregistrant auprès de l'IANA et en publiant leurs descriptions dans un addendum au profil ou dans une spécification de format de charge utile.