Groupe de travail Réseau

R. Kreuter, Siemens AG

Request for Comments : 4040

avril 2005

Catégorie : Sur la voie de la normalisation

Traduction Claude Brière de L'Isle



Format de charge utile RTP pour appel transparent à 64 kbit/s



Statut de ce mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de copyright

Copyright (C) The Internet Society (2005).


Résumé

Le présent document décrit comment transporter de façon transparente des données d'un canal à 64 kbit/s dans des paquets RTP, en utilisant un pseudo codec appelé "Clearmode". Il sert aussi d'enregistrement pour le type MIME qui s'y rapporte, appelé "audio/clearmode".


"Clearmode" est une caractéristique de base des passerelles de supports VoIP.


Table des Matières

1. Introduction

2. Conventions utilisées dans ce document

3. Traitement de flux de données à 64 kbit/s et paramètres d'en-tête RTP

4. Considérations relatives à l'IANA

5. Transposition en paramètres du protocole de description de session (SDP)

6. Considérations sur la sécurité

7. Références

7.1 Références normatives

7.2 Références pour information

8. Remerciements

Adresse de l'auteur

Déclaration complète de droits de reproduction


1. Introduction


Les passerelles de supports de voix sur IP (VoIP, Voice over IP) ont besoin de transporter tous les flux de données possibles générés par des terminaux analogiques ou des terminaux de réseau numériques à intégration de services (RNIS) via un réseau IP. Dans le présent document une passerelle de supports VoIP est un appareil qui convertit un flux de données (numériques ou analogiques) linéaire en un flux de données numériques mises en paquets ou vice versa. Se reporter à la [RFC2719] pour une introduction à l'architecture de base d'un réseau fondé sur une passerelle de supports.


Généralement une passerelle de supports VoIP fait un certain traitement sur les données qu'elle convertit à côté de la mise en paquets ou de la sortie du mode paquet ; c'est-à-dire l'annulation d'écho ou la détection du multifréquence bitonalité (DTMF, dual tone multifrequency) et en particulier un codage/décodage. Mais il y a une classe de flux de données qui ne s'appuie pas sur, ni ne permet, le traitement des données au sein de la passerelle de supports VoIP excepté pour la mise en paquet ou la sortie du mode paquet. Les terminaux de données RNIS vont produire des flux de données qui ne sont pas compatibles avec un codage non linéaire comme celui utilisé pour la voix.


Pour de telles applications, il est nécessaire d'avoir un relais transparent de flux de données à 64 kbit/s dans des paquets du protocole de transport en temps réel (RTP, real-time transport protocol) [RFC3550]. Ce mode est souvent appelé "données de canal clair" ou "64 kbit/s sans restriction". Aucun codeur/décodeur n'est nécessaire dans ce cas, mais un type de charge utile RTP unique est nécessaire et un type MIME en rapport doit être enregistré pour les besoins de la signalisation.


Clearmode ne se restreint pas aux exemples décrits ci-dessus. Il peut être utilisé par toute application, et n'a pas besoin d'un codage/décodage spécial pour les transferts via une connexion RTP.


Le présent document de format de charge utile décrit un pseudo codec appelé "Clearmode", pour les flux de données à 64 kbit/s en mode échantillons avec 8 bits par échantillon. Il est conforme à la [RFC2736], qui donne des lignes directrices pour la spécification de nouveaux formats de charge utile RTP.


Des exemples de l'utilisation actuelle de Clearmode sont le transfert de "voix RNIS à 7 kHz" et de "données RNIS" dans des passerelles de supports VoIP.


Le présent document sert aussi d'enregistrement de type MIME conformément à la [RFC2045] et la [RFC2048], qui définissent les procédures d'enregistrement de nouveaux types MIME au sein de l'arborescence de l'IETF.


2. Conventions utilisées dans ce document


Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].


3. Traitement de flux de données à 64 kbit/s et paramètres d'en-tête RTP


Clearmode n'utilise aucun codage ni décodage. Il fournit juste la mise en paquets.


Clearmode suppose que les données à traiter sont en mode échantillon avec un octet (8 bits) par échantillon. Il n'y a pas de restriction sur le nombre d'échantillons par paquet autre que la limite de 64 koctets imposée par le protocole IP. Le nombre d'échantillons DEVRAIT être inférieur à l'unité maximum de transmission (MTU, maximum transmission unit) du chemin moins la longueur d'en-tête de paquet combinée. Si l'environnement est prévu avec des tunnels ou une encapsulation de sécurité au titre de son fonctionnement, le nombre d'échantillons DEVRAIT être réduit pour permettre l'espace d'en-tête supplémentaire.


La mise en paquets/dépaquetisation de la charge utile pour Clearmode est similaire au traitement de la modulation par impulsion et codage(PCMU ou PCMA, Pulse Code Modulation ) décrit dans la [RFC3551]. Chaque octet Clearmode DEVRA être aligné sur l'octet dans un paquet RTP. Le bit de signe de chaque octet DEVRA correspondre au bit de poids fort de l'octet dans le paquet RTP.


Un débit d'échantillon de 8000 Hz DOIT être utilisé. Cela correspond à un débit de transmission de 64 kbit/s par canal.


L'horodatage DEVRA être réglé comme décrit dans la [RFC3550].


Le bit marqueur est toujours à zéro. La suppression du silence n'est pas applicable aux flux de données Clearmode.


Le type de charge utile est alloué de façon dynamique et n'est pas présenté dans ce document.


Les champs d'en-tête RTP non mentionnés ici DEVRONT être utilisés comme spécifié dans la [RFC3550] et tout profil applicable.


Le présent document spécifie l'utilisation de RTP sur UDP ainsi que TCP en envoi individuel et en diffusion groupée. (Cela n'empêche pas l'utilisation de cette définition quand RTP est porté sur d'autres protocoles de couche inférieure.)


4. Considérations relatives à l'IANA


Le présent document enregistre le sous type MIME suivant : audio/clearmode.

Pour : ietf-types@iana.org

Sujet : Enregistrement du type de support MIME audio/clearmode

Nom du type de support MIME : audio

Nom du sous type MIME : clearmode

Paramètres exigés : aucun

Paramètres facultatifs : ptime, maxptime. "ptime" donne la longueur du temps en millisecondes représenté par le support dans un paquet, comme décrit dans la [RFC2327]. "maxptime" représenté la quantité maximum de supports, qui peut être encapsulée dans chaque paquet, exprimée comme temps en millisecondes, comme décrit dans la [RFC3267].


Considérations de codage : ce type n'est défini que pour le transfert via RTP [RFC3550].


Considérations de sécurité : Voir la Section 6 de la RFC 4040


Considérations d'interopérabilité : aucune


Spécification publiée : RFC 4040


Applications qui utilisent ce type de supports : Passerelles de supports de voix sur IP, transférant des "données RNIS à 64 kbit/s", "voix RNIS à 7 kHz", ou autres flux de données à 64 kbit/s via une connexion RTP


Note : le choix du type MIME de niveau supérieur "audio" a été fait parce que les utilisations dominantes de ce pseudo codec sont attendues de la téléphonie et des passerelles en relation avec la voix. Le type "audio" permet l'utilisation du partage d'accès dans la ligne SDP "m=" avec des codecs tels que audio/g711 [RFC2327], [RFC3264], à titre d'exemple. Ce partage est une application importante et ne serait pas possible autrement.


Information supplémentaires : aucune


Usage prévu : COMMUN


Auteur/Contrôleur des changements : groupe de travail IETF Transport audio/vidéo délégué de l'IESG.


5. Transposition en paramètres du protocole de description de session (SDP)


Les paramètres sont transposés en SDP [RFC2327] de façon standard.

o Le type MIME (audio) devient en SDP "m=" comme nom de support.

o Le sous type MIME (clearmode) devient en SDP "a=rtpmap" comme nom de codage.

o Les paramètres facultatifs "ptime" et "maxptime" deviennent en SDP les attributs, respectivement "a=ptime" et "a=maxptime".


Un exemple de transposition serait le suivant :


audio/clearmode; ptime=10

m=audio 12345 RTP/AVP 97

a=rtpmap:97 CLEARMODE/8000

a=ptime:10


Noter que les noms de format (codage) de charge utile définis dans le profil RTP sont couramment donnés en majuscules. Les sous types MIME sont généralement données en minuscules. Ces noms sont insensibles à la casse dans les deux cas.


6. Considérations sur la sécurité


Les mises en œuvre qui utilisent le format de charge utile défini dans la présente spécification sont sujettes aux considérations sur la sécurité exposées dans la [RFC3550]. Le format de charge utile décrit dans le présent document ne spécifie aucun service de sécurité différent. La principale fonction de ce format de charge utile est d'ajouter un transport transparent pour un flux de données à 64 kbit/s.


La confidentialité des flux de supports est réalisée par le chiffrement, par exemple en appliquant le profil de RTP sécurisé de la [RFC3711].


Comme avec tout protocole fondé sur IP, dans certaines circonstances un receveur peut être surchargé par la simple réception de trop de paquets, désirés ou non. L'authentification de couche réseau PEUT être utilisée pour éliminer des paquets provenant de sources non désirées, mais le coût de traitement de l'authentification elle même peut être trop élevé. La surcharge peut aussi se produire si l'envoyeur choisit d'utiliser une plus petite période de mise en paquets que ce que le receveur peut traiter. Le paramètre "ptime" peut être utilisé pour négocier une mise en paquets appropriée durant l'établissement de la session.


En général RTP n'est pas un protocole de transfert approprié pour les flux d'octets fiables. TCP est meilleur dans ce cas. À côté de cela, la perte de paquet due à l'encombrement est autant un problème pour le clearmode que pour les autres formats de charge utile. Voir à la Section 2 de la [RFC3551] l'exposé sur ces questions.


7. Références

7.1 Références normatives


[RFC2045] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)


[RFC2048] N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-4289)


[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)


[RFC2327] M. Handley et V. Jacobson, "SDP : Protocole de description de session", avril 1998. (Obsolète; voir RFC4566)


[RFC2736] M. Handley, C. Perkins, "Lignes directrices pour les rédacteurs de spécifications de format de charge utile RTP", décembre  1999. (BCP0036, MàJ par RFC8088)


[RFC3264] J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002.


[RFC3267] J. Sjoberg et autres, "Format de charge utile et format de mémorisation de fichier pour les codecs audio AMR et AMR-WB dans RTP", juin 2002. (Obsolète, voir RFC4867) (P.S.)


[RFC3550] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108)


[RFC3551] H. Schulzrinne et S. Casner, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", STD 65, juillet 2003.


7.2 Références pour information


[RFC2719] L. Ong et autres, "Cadre architectural pour le transport de la signalisation", octobre 1999. (Information)


[RFC3711] M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004. (P.S.)


8. Remerciements


L'éditeur tient à remercier de son aide le groupe de travail AVT de l'IETF, et en particulier Colin Perkins et Magnus Westerlund de leurs intensives relectures et commentaires.


Adresse de l'auteur


Ruediger Kreuter

Siemens AG

81730 Munich, Germany


mél : ruediger.kreuter@siemens.com


Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2005).


Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.


Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.


Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.