Profil RTP pour conférences audio et vidéo avec contrôle minimal

RFC 3551 page - 1 - Schulzrinne & Casner Grupe de travail Réseau H. Schulzrinne, Clumbia University Request fr Cmments : 3551 S. Casner, Packet Design STD 65 RFC rendue bslète : 1890 juillet 2003 Catégrie : Nrme Traductin Claude Brière de L'Isle Prfil RTP pur cnférences audi et vidé avec cntrôle minimal Statut du présent mémire Le présent dcument spécifie un prtcle de nrmalisatin Internet pur la cmmunauté Internet, et appelle à discussin et suggestins en vue de sn améliratin. Prière de s'en rapprter à l éditin en curs des "Internet Official Prtcl Standards" (nrmes fficielles du prtcle Internet) (STD 1) pur cnnaître l état de la nrmalisatin et le statut du présent prtcle. La distributin du présent mémire n est sumise à aucune restrictin. Déclaratin de cpyright Cpyright (C) The Internet Sciety (2003). Tus drits réservés Résumé Le présent dcument décrit un prfil appelé "RTP/AVP" pur l'usage du prtcle de transprt en temps réel (RTP), versin 2, et du prtcle de cntrôle asscié, RTCP, au sein de cnférences audi et vidé multi participants avec cntrôle minimal. Il dnne l'interprétatin cnvenable des champs génériques dans la spécificatin RTP pur les cnférences audi et vidé. En particulier, ce dcument définit un ensemble de transpsitins par défaut de numérs de type de charge utile en cdages. Le présent dcument décrit aussi cmment les dnnées audi et vidé peuvent être prtées au sein de RTP. Il définit un ensemble de cdages standard et leurs nms lrsqu'ils snt utilisés dans RTP. Les descriptins dnnent des pinteurs sur des mises en œuvre de référence et les nrmes détaillées. Le présent dcument est destiné à aider à la mise en œuvre d'applicatins multimédia audi, vidé et autres en temps réel. Le présent mémire rend bslète la RFC 1890. Il est pur la plus grande part rétr cmpatible, sauf pur les fnctins supprimées parce que deux mises en œuvre interpérables n'nt pu être truvées. Les ajuts à la RFC 1890 cdifient les pratiques existantes dans l'utilisatin des frmats de charge utile sus ce prfil et incluent de nuveaux frmats de charge utile définis depuis la publicatin de la RFC 1890. Table des matières 1. Intrductin...2 1.1 Terminlgie...2 2. Frmat de paquet RTP et RTCP et cmprtement du prtcle...2 3. Enregistrement de cdages supplémentaires...3 4. Audi...4 4.1 Règles indépendantes du cdage...4 4.2 Recmmandatins pur le fnctinnement...6 4.3 Lignes directrices pur les cdages audi fndés sur l'échantillnnage...6 4.4 Lignes directrices pur les cdages audi fndés sur la trame...6 4.5 Cdages audi...7 5. Vidé...17 5.1 CelB...17 5.2 JPEG...17 5.3 H261...18 5.4 H263...18 5.5 H263-1998...18 5.6 MPV...18 5.7 MP2T...18 5.8 nv...18 6. Définitins des types de charge utile...18 7. RTP sur TCP et prtcles similaires de flux d'ctets...20 8. Allcatin d'accès...20 9. Changements depuis la RFC 1890...20 10. Cnsidératins pur la sécurité...22

RFC 3551 page - 2 - Schulzrinne & Casner 11. Cnsidératins relatives à l'iana...22 12. Références...22 12.1 Références nrmatives...23 12.2 Références pur infrmatin...23 13. Lcalisatin actuelle des ressurces cncernées...24 14. Remerciements...24 15. Déclaratin de drits de prpriété intellectuelle...25 16. Adresse des auteurs...25 17. Déclaratin cmplète des drits de reprductin...25 1. Intrductin Le présent prfil définit les aspects de RTP qui ne snt pas spécifiés dans la définitin du prtcle RTP versin 2 de la RFC 3550 [1]. Ce prfil est destiné à être utilisé au sein de cnférences audi et vidé avec cntrôle de sessin minimal. En particulier, aucune prise en charge de la négciatin des paramètres u du cntrôle d'adhésin n'est furnie. Le prfil est suppsé utile dans les sessins ù aucune négciatin ni cntrôle d'adhésin ne snt utilisés (par exemple, utilisant des types de charge utile statiques et les indicatins d'adhésin furnies par RTCP), mais ce prfil peut aussi être utile en cnjnctin avec un prtcle de cntrôle de niveau supérieur. L'usage du présent prfil peut être implicite dans l'utilisatin des applicatins apprpriées ; il peut n'y avir pas d'indicatin explicite du numér d'accès, de l'identifiant du prtcle u de chses cmme cela. Des applicatins cmme des répertires de sessin peuvent utiliser le nm spécifié pur ce prfil à la Sectin 11. D'autres prfils peuvent faire des chix différents pur les éléments spécifiés ici. Le présent dcument définit aussi un ensemble de cdages et de frmats de charge utile pur l'audi et la vidé. Ces descriptins de frmat de charge utile ne snt incluses ici que dans un suci pratique car elles snt trp petites pur justifier des dcuments à part. L'utilisatin de ces frmats de charge utile N'EST PAS EXIGÉE pur le présent prfil. Seule la liaisn de certains des frmats de charge utile aux numérs de type de charge utile statique des tableaux 4 et 5 est nrmative. 1.1 Terminlgie Les mts clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce dcument snt à interpréter cmme décrit dans la RFC 2119 [2] et indiquent les niveaux d'exigence pur les mises en œuvre cnfrmes à ce prfil RTP. Le présent dcument définit le terme "type de supprt" cmme divisant les cdages de cntenus audi et vidé en tris classes : audi, vidé et audi/vidé (entrelacé). 2. Frmat de paquet RTP et RTCP et cmprtement du prtcle La sectin "Spécificatins des prfils et frmats de charge utile RTP" de la RFC 3550 énumère un certain nmbre d'éléments qui peuvent être spécifiés u mdifiés dans un prfil. La présente sectin traite de ces éléments. Généralement, ce prfil suit les aspects par défaut et/u recmmandés de la spécificatin RTP. en-tête de dnnées RTP : le frmat standard de l'en-tête fixe de dnnées RTP (un bit marqueur) est utilisé. types de charge utile : les types de charge utile statiques snt définis à la Sectin 6. ajuts d'en-tête de dnnées RTP : aucun champ additinnel fixe n'est ajuté à l'en-tête de dnnées RTP. extensins d'en-tête de dnnées RTP : aucune extensin d'en-tête RTP n'est définie, mais les applicatins qui fnctinnent sus le présent prfil PEUVENT utiliser de telles extensins. Et dnc, les applicatins NE DEVRAIENT PAS suppser que le bit X de l'en-tête RTP est tujurs à zér et elles DEVRAIENT être prêtes à ignrer l'extensin d'en-tête. Si une extensin d'en-tête est définie à l'avenir, cette définitin DOIT spécifier le cntenu des 16 premiers bits d'une façn telle que plusieurs extensins différentes puissent être identifiées.

RFC 3551 page - 3 - Schulzrinne & Casner types de paquet RTCP : aucun type de paquet RTCP supplémentaire n'est défini par la présente spécificatin de prfil. intervalle de rapprts RTCP : Les cnstantes suggérées snt à utiliser pur le calcul de l'intervalle de rapprts RTPC. Les sessins qui fnctinnent sus ce prfil PEUVENT spécifier un paramètre distinct pur la bande passante de trafic RTCP plutôt que d'utiliser la fractin par défaut de la bande passante de sessin. La bande passante du trafic RTCP PEUT être divisée en deux paramètres de sessin distincts pur les participants qui snt des envyeurs actifs de dnnées et pur ceux qui ne le snt pas. Suivant la recmmandatin de la spécificatin RTP [1] que 1/4 de la bande passante RTCP sit dédiée aux envyeurs de dnnées, les valeurs par défaut RECOMMANDÉES pur ces deux paramètres seraient respectivement 1,25 % et 3,75 %. Pur une sessin particulière, la bande passante RTCP pur les nn envyeurs de dnnées PEUT être réglée à zér lrs du fnctinnement sur des liaisns unidirectinnelles u pur des sessins qui n'exigent pas de retur sur la qualité de réceptin. La bande passante RTCP pur les envyeurs de dnnées DEVRAIT rester différente de zér afin que les envyeurs de rapprts puissent encre les envyer pur la synchrnisatin inter supprts et pur identifier la surce par le CNAME. Les myens par lesquels snt spécifiés le, u les deux paramètres de bande passante de sessin RTCP srtent du dmaine d'applicatin du présent mémire. extensin SR/RR : aucune sectin d'extensin n'est définie pur le paquet SR u RR RTCP. utilisatin de SDES : les applicatins PEUVENT utiliser tus les éléments de SDES décrits dans la spécificatin RTP. Alrs que les infrmatins de CNAME DOIVENT être envyées à tus les intervalles de rapprts, d'autres éléments DEVRAIENT seulement être envyés tus les tris intervalles de rapprts, avec NAME envyé sept fis sur huit au sein de ce créneau et les éléments de SDES restants prenant de façn cyclique le huitième créneau, cmme défini au paragraphe 6.2.2 de la spécificatin RTP. En d'autres termes, NAME est envyé dans les paquets RTCP 1, 4, 7, 10, 13, 16, 19, alrs que, disns EMAIL est utilisé dans le paquet RTCP 22. sécurité : les service de sécurité RTP par défaut snt aussi par défaut sus ce prfil. transpsitin de chaîne à clé : aucune transpsitin n'est spécifiée par ce prfil. encmbrement : RTP et ce prfil peuvent être utilisés dans le cntexte d'un service réseau améliré, par exemple, de services intégrés (RFC 1633) [4] u de services différenciés (RFC 2475) [5], u ils peuvent être utilisés avec un service au mieux. Si un service améliré est utilisé, les receveurs RTP DEVRAIENT surveiller la perte de paquets pur s'assurer que le service qui était demandé est réellement furni. S'il ne l'est pas, ils DEVRAIENT alrs suppser qu'ils reçivent un service au mieux et se cnduire en cnséquence. Si le service au mieux est utilisé, les receveurs RTP DEVRAIENT surveiller les pertes de paquet pur s'assurer que le taux de perte de paquet reste dans des limites acceptables. La perte de paquet est cnsidérée cmme acceptable si un flux TCP à travers le même chemin de réseau et rencntrant les mêmes cnditins de réseau réalisait un débit myen, mesuré sur une échelle de temps raisnnable, qui ne serait pas inférieur à ce que le flux RTP réalise. Cette cnditin peut être satisfaite en mettant en œuvre des mécanismes de cntrôle d'encmbrement pur adapter le taux de transmissin (u le nmbre de cuches suscrites pur une sessin de diffusin grupée en cuches), u en s'arrangeant pur qu'un receveur quitte la sessin si le taux de pertes est inacceptablement élevé. La cmparaisn avec TCP ne peut pas être spécifiée exactement, mais elle est prévue cmme une cmparaisn "d'rdre de grandeur" en temps et en débit. Le temps pendant lequel le débit TCP est mesuré est le temps d'aller-retur de la cnnexin. Par nature, cette exigence établit qu'il n'est pas acceptable de déplyer une applicatin (utilisant RTP u tut autre prtcle de transprt) sur l'internet au mieux qui cnsmme arbitrairement la bande passante et n'est pas en cmpétitin lyale avec TCP dans le même rdre de grandeur. prtcle sus-jacent : le prfil spécifie l'utilisatin de RTP sur UDP aussi bien que TCP en envi individuel et en diffusin grupée. (Cela n'empêche pas l'utilisatin de ces définitins quand RTP est prté sur d'autres prtcles de cuche inférieure.) transpsitin de transprt : n utilise la transpsitin standard de RTP et RTCP en adresses de niveau transprt. encapsulatin : le présent prfil laisse aux applicatins la spécificatin de l'encapsulatin de RTP dans les prtcles autres que UDP. 3. Enregistrement de cdages supplémentaires

RFC 3551 page - 4 - Schulzrinne & Casner Le présent prfil fait la liste d'un ensemble de cdages, chacun d'eux cmprtant une cmpressin u représentatin de dnnées de supprt particulière plus un frmat de charge utile pur l'encapsulatin au sein de RTP. Certains de ces frmats de charge utile snt spécifiés ici, alrs que d'autres snt spécifiés dans d'autres RFC. Il est prévu que des cdages supplémentaires au delà de l'ensemble énuméré ici sient créés à l'avenir et spécifiés dans des RFC de frmat de charge utile supplémentaires. Le présent prfil allue aussi à chaque cdage un nm abrégé qui PEUT être utilisé par des prtcles de cntrôle de niveau supérieur, tels que le prtcle de descriptin de sessin (SDP, Sessin Descriptin Prtcl) RFC 2327 [6], pur identifier les cdages chisis pur une sessin RTP particulière. Dans certains cntextes, il peut être utile de se référer à ces cdages sus la frme d'un type de cntenu MIME. Pur le rendre plus facile, la RFC 3555 [7] dnne les enregistrements de tus les nms de cdages énumérés ici cmme des nms de sus-type MIME sus les types MIME "audi" et "vidé" à travers la prcédure d'enregistrement MIME telle que spécifiée dans la RFC 2048 [8]. Tus les cdages supplémentaires spécifiés pur utilisatin avec ce prfil (u d'autres) peuvent aussi se vir alluer des nms enregistrés cmme sus-types MIME auprès de l'autrité d'allcatin des numérs de l'internet (IANA). Ce registre dnne les myens de s'assurer que les nms allués aux cdages supplémentaires restent uniques. La RFC 3555 spécifie les infrmatins qui snt requises pur l'enregistrement des cdages RTP. En plus de l'allcatin de nms aux cdages, ce prfil allue aussi des numérs de type de charge utile statique RTP à certains d'entre eux. Cependant, le numér de type de charge utile est relativement étrit et ne peut s'accmmder d'allcatins pur tus les cdages existants et futurs. Durant les premiers stades du dévelppement de RTP, il était nécessaire d'utiliser des types de charge utile allués de façn statique parce qu'aucun autre mécanisme n'avait été spécifié pur lier le cdage et le type de charge utile. Il était prévu que des myens nn RTP srtant du dmaine d'applicatin du présent mémire (cmme des prtcles de services d'annuaire u d'invitatin) seraient spécifiés pur établir une transpsitin dynamique entre un type de charge utile et un cdage. Maintenant, des mécanismes de définitin de liaisns de type de charge utile dynamiques nt été spécifiés dans le prtcle de descriptin de sessin (SDP) et dans d'autres prtcles tels que la Recmmandatin UIT-T H.323/H.245. Ces mécanismes asscient le nm enregistré du cdage/frmat de charge utile, avec tut paramètre supplémentaire requis, cmme le débit d'hrlge de l'hrdatage RTP et le nmbre de canaux, avec un numér de type de charge utile. Cette assciatin n'est effective que pur la durée de la sessin RTP dans laquelle est faite la liaisn dynamique de type de charge utile. Cette assciatin ne s'applique qu'à la sessin RTP pur laquelle elle est faite, et dnc les numérs peuvent être réutilisés pur des cdages différents dans des sessins différentes de srte que la limitatin de l'espace des numérs est évitée. Le présent prfil réserve les numérs de type de charge utile dans la gamme 96-127 exclusivement à l'allcatin dynamique. Les applicatins DEVRAIENT d'abrd utiliser les valeurs dans cette gamme pur des types de charge utiles dynamiques. Ces applicatins qui nt besin de définir plus de 32 types de charges utiles dynamiques PEUVENT lier des cdes en dessus de 96, auquel cas il est RECOMMANDÉ que les numérs de type de charge utile nn allués sient utilisés d'abrd. Cependant, les types de charge utile allués de façn statique snt des liaisns par défaut et PEUVENT être liés de façn dynamique à de nuveaux cdages si nécessaire. Redéfinir des types de charge utile en dessus de 96 peut causer un fnctinnement incrrect si n tente de se jindre à une a sessin sans btenir les infrmatins de descriptin de sessin qui définissent les types de charge utile dynamiques. Les types de charge utile dynamiques NE DEVRAIENT PAS être utilisés sans un mécanisme bien défini pur indiquer la transpsitin. Les systèmes qui s'attendent à interpérer avec d'autres qui fnctinnent sus ce prfil NE DEVRAIENT PAS faire leurs prpres allcatins de cdages prpriétaires à des types de charge utile fixés particuliers. La présente spécificatin établit cmme plitique de ne pas alluer de types de charge utile statiques supplémentaires au delà de ceux définis dans le présent dcument. Fixer cette plitique évite le prblème d'essayer de créer un ensemble de critères d'acceptatin des allcatins statiques et encurage les mises en œuvre et le dépliement des mécanismes de type de charge utile dynamique. L'ensemble final des allcatins de type de charge utile figure dans les tableaux 4 et 5. 4. Audi 4.1 Règles indépendantes du cdage Cmme la capacité de supprimer les silences est une des principales mtivatins de l'utilisatin des paquets pur la transmissin de la vix, l'en-tête RTP prte à la fis un numér de séquence et un hrdatage pur permettre au receveur de distinguer les paquets perdus et les pérides ù aucune dnnée n'est transmise. La transmissin discntinue (suppressin de

RFC 3551 page - 5 - Schulzrinne & Casner silence) PEUT être utilisée avec tus les frmats de charge utile audi. Les receveurs DOIVENT suppser que les envyeurs peuvent supprimer les silences sauf si c'est interdit par une signalisatin qui est spécifiée ailleurs. (Même si l'émetteur ne supprime pas les silences, le receveur devrait être prêt à traiter des pérides ù aucune dnnée n'est présente car des paquets peuvent être perdus.) Certains frmats de charge utile (vir aux paragraphes 4.5.3 et 4.5.6) définissent une trame de "descripteur d'insertin de silence" u "bruit de cnfrt" pur spécifier des paramètres de bruit artificiel qui peut être généré durant une péride de silence pur apprxime le bruit de fnd à la surce. Pur d'autres frmats de charge utile, un bruit de cnfrt (CN, Cmfrt Nise) générique est spécifié dans la RFC 3389 [9]. Lrsque le frmat de charge utile CN est utilisé avec un autre frmat de charge utile, les valeurs différentes dans le champ Type de charge utile RTP distinguent les paquets de bruit de cnfrt de ceux du frmat de charge utile chisi. Pur les applicatins qui envient sit pas de paquet, sit des paquets ccasinnels de bruit de cnfrt durant les silences, le premier paquet d'un jet de parle, c'est-à-dire, le premier paquet après une péride de silence durant laquelle les paquets n'nt pas été transmis de façn cntiguë, DEVRAIT être distingué en réglant le bit marqueur à un dans l'en-tête de dnnées RTP. Le bit marqueur dans tus les autres paquets est à zér. Le cmmencement d'un jet de parle PEUT être utilisé pur ajuster le délai de reprductin pur refléter des délais réseau changeants. Les applicatins sans suppressin de silence DOIVENT régler le bit marqueur à zér. Le débit d'hrlge RTP utilisé pur générer l'hrdatage RTP est indépendant du nmbre de canaux et du cdage ; il est nrmalement égal au nmbre de pérides d'échantillnnage par secnde. Pur des cdages sur N canaux, chaque péride d'échantillnnage (disns, 1/8 000 de secnde) génère N échantillns. (Cette terminlgie est standard, mais quelque peu trmpeuse, car le nmbre ttal d'échantillns générés par secnde est alrs le taux d'échantillnnage multiplié par le nmbre de canaux.) Si plusieurs canaux audi snt utilisés, les canaux snt numértés de gauche à drite, en cmmençant à un. Dans les paquets RTP audi, les infrmatins prvenant de canaux de numér inférieur précèdent ceux des canaux de numér supérieur. Quand il y a plus de deux canaux, la cnventin suivie par le frmat d'échange audi AIFF-C DEVRAIT être suivie [3], en utilisant la ntatin suivante, sauf cnventin cntraire spécifiée pur un cdage u frmat de charge utile particulier : l r c S F R (left) gauche (right) drite centre (surrund) autur face (rear) derrière canaux descriptin canal 1 2 3 4 5 6 2 stéré l r 3 l r c 4 l c r S 5 l Fr Fc Sl Sr 6 l lc c r rc S Nte : La RFC 1890 définissait deux cnventins pur le rangement de quatre canaux audi. Cmme le rangement est indiqué implicitement par le numér des canaux, c'était ambigu. Dans cette révisin, l'rdre décrit cmme "quadriphnique" a été éliminé pur lever l'ambiguïté. Ce chix se fnde sur l'bservatin que le frmat audi de cnsmmateur quadriphnique n'est pas devenu très ppulaire, alrs que le sn envelppant (surrund) l'est devenu. Les échantillns pur tus les canaux qui appartiennent à un seul instant d'échantillnnage DOIVENT être au sein du même paquet. L'entrelaçage des échantillns prvenant des différents canaux dépend du cdage. Les lignes directrices générales snt dnnées aux paragraphes 4.3 et 4.4. La fréquence d'échantillnnage DEVRAIT être tirée de l'ensemble : 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100 et 48 000 Hz. (Les anciens rdinateurs Apple Macintsh avaient un taux d'échantillnnage natif de 22 254,54 Hz, qui peut être cnverti en 22 050 avec une qualité acceptable en abandnnant 4 échantillns dans une trame de 20 ms.) Cependant, la plupart des cdages audi snt définis pur un ensemble plus restreint de fréquences d'échantillnnage. Les receveurs DEVRAIENT être prêts à accepter de l'audi multi canal, mais PEUVENT chisir de ne juer que sur un seul canal.

RFC 3551 page - 6 - Schulzrinne & Casner 4.2 Recmmandatins pur le fnctinnement Les recmmandatins suivantes snt les paramètres de fnctinnement par défaut. Les applicatins DEVRAIENT être prêtes à traiter d'autres valeurs. Les gammes dnnées snt destinées à furnir des lignes directrices aux auteurs d'applicatins, en permettant à un ensemble d'applicatins cnfrmes à ces lignes directrices d'interpérer sans négciatin supplémentaire. Ces lignes directrices ne snt pas destinées à restreindre les paramètres de fnctinnement pur les applicatins qui peuvent négcier un ensemble de paramètres interpérables, par exemple, à travers un prtcle de cmmande de cnférence. Pur l'audi par paquets, l'intervalle de mise en paquet par défaut DEVRAIT avir une durée de 20 ms u d'une trame, seln ce qui est le plus lng, sauf ntatin cntraire au Tableau 1 (clnne "ms/paquet"). L'intervalle de mise en paquet détermine le délai minimum de but en but ; les paquets plus lngs intrduisent mins de redndance d'en-tête mais de plus frts délais et rendent la perte de paquet mins remarquable. Pur les applicatins nn interactives telles que de lecture u pur les liaisns qui nt des cntraintes sévères de bande passante, un délai de mise en paquet plus élevé PEUT être utilisé. Un receveur DEVRAIT accepter des paquets représentant entre 0 et 200 ms de dnnées audi. (Pur les cdages audi en trames, un receveur DEVRAIT accepter des paquets avec un nmbre de trames égal à 200 ms divisé par la durée de trame, arrndi à l'entier supérieur.) Cette restrictin permet une taille raisnnable de mémire tampn pur le receveur. 4.3 Lignes directrices pur les cdages audi fndés sur l'échantillnnage Dans les cdages fndés sur l'échantillnnage, chaque échantilln audi est représenté par un nmbre fixe de bits. Au sein des dnnées audi cmpressées, les cdes des échantillns individuels peuvent s'étendre sur des frntières d'ctet. Un paquet RTP audi peut cntenir tut nmbre d'échantillns audi, seln les cntraintes que le nmbre de bits par échantilln multiplié par le nmbre d'échantillns par paquet dnne u nn un nmbre entier d'ctets. Les cdages fractinnaires prduisent mins d'un ctet par échantilln. La durée d'un paquet audi est déterminée par le nmbre d'échantillns dans le paquet. Pur les cdages fndés sur l'échantillnnage qui prduisent un u plusieurs ctets par échantilln, les échantillns prvenant de différents canaux échantillnnées au même instant d'échantillnnage DEVRAIENT être mis en paquets dans des ctets cnsécutifs. Par exemple, pur un cdage sur deux canaux, la séquence d'ctets est (canal gauche, premier échantilln), (canal drit, premier échantilln), (canal gauche, secnd échantilln), (canal drit, secnd échantilln),... Pur des cdages multi ctets, les ctets DEVRAIENT être transmis dans l'rdre des ctets du réseau (c'est-à-dire, l'ctet de pids frt en premier). La mise en paquet des cdages fndés sur l'échantilln prduisant mins d'un ctet par échantilln est spécifique du cdage. L'hrdatage RTP reflète l'instant auquel le premier échantilln du paquet été échantillnné, c'est-à-dire, les plus anciennes infrmatins du paquet. 4.4 Lignes directrices pur les cdages audi fndés sur la trame Les cdages fndés sur la trame cdent un blc de lngueur fixe de dnnées audi dans un autre blc de dnnées cmpressées, nrmalement aussi de lngueur fixe. Pur les cdages fndés sur la trame, l'envyeur PEUT chisir de cmbiner plusieurs trames de cette srte en un seul paquet RTP. Le receveur peut dire le nmbre de trames cntenues dans un paquet RTP, si tutes les trames nt la même lngueur, en divisant la lngueur de charge utile RTP par la taille de trame audi qui est définie au titre du cdage. Cela ne fnctinne pas si n transprte des trames de différentes tailles sauf si les tailles de trame snt premières entre elles. Sinn, les trames DOIVENT indiquer leur taille. Pur les cdecs fndés sur la trame, l'rdre des canaux est défini pur tut le blc. C'est-à-dire que pur deux canaux audi, les échantillns de drite et gauche DEVRAIENT être cdés indépendamment, avec la trame cdée pur le canal gauche précédant celle pur le canal drit. Tus les cdecs audi rientés trame DEVRAIENT être capables de cder et décder plusieurs trames cnsécutives au sein d'un seul paquet. Cmme la taille de trame pur le cdec rienté trame est dnnée, il n'est nul besin d'utiliser une désignatin distincte pur le même cdage, mais n utilise des numérs de trame différents pur chaque paquet. Les paquets RTP DEVRONT cntenir un nmbre entier de trames, avec les trames insérées seln l'age au sein d'un paquet, de srte que la plus ancienne trame (à exécuter en premier) survienne immédiatement après l'en-tête de paquet RTP. L'hrdatage RTP reflète l'instant auquel le premier échantilln dans la première trame a été échantillnné, c'est-à-dire, la plus ancienne infrmatin du paquet.

RFC 3551 page - 7 - Schulzrinne & Casner 4.5 Cdages audi nm du cdage échantilln/tram bits/échantilln taux d'échantillnnage ms/tram ms/paquet par défaut e e DVI4 échantilln 4 variable 20 G722 échantilln 8 16 000 20 G723 trame N/A 8 000 30 30 G726-40 échantilln 5 8 000 20 G726-32 échantilln 4 8 000 20 G726-24 échantilln 3 8 000 20 G726-16 échantilln 2 8 000 20 G728 trame N/A 8 000 2.5 20 G729 trame N/A 8 000 10 20 G729D trame N/A 8 000 10 20 G729E trame N/A 8 000 10 20 GSM trame N/A 8 000 20 20 GSM-EFR trame N/A 8 000 20 20 L8 échantilln 8 variable 20 L16 échantilln 16 variable 20 LPC trame N/A 8 000 20 20 MPA trame N/A variable variable PCMA échantilln 8 variable 20 PCMU échantilln 8 variable 20 QCELP trame N/A 8 000 20 20 VDVI échantilln variable variable 20 Tableau 1 : Prpriétés des cdages audi (N/A : nn applicable) Les caractéristiques des cdages audi décrites dans ce dcument snt présentées dans le Tableau 1 ; elles snt énumérées dans l'rdre de leur type de charge utile au Tableau 4. Alrs que la plupart des cdecs audi ne snt spécifiés que pur un taux d'échantillnnage fixe, certains algrithmes fndés sur l'échantilln (indiqués par une entrée de "variable" dans la clnne "taux d'échantillnnage" du Tableau 1) peuvent être utilisés avec différents taux d'échantillnnage, résultant en différents débits binaires cdés. Lrque ils snt utilisés avec un taux d'échantillnnage autre que celui pur lequel un type de charge utile statique est défini, des myens nn RTP srtant du dmaine d'applicatin du présent mémire DOIVENT être utilisés pur définir un type dynamique de charge utile et DOIVENT indiquer le débit d'hrlge d'hrdatage RTP chisi, qui est nrmalement le même que le taux d'échantillnnage pur l'audi. 4.5.1 DVI4 DVI4 utilise un schéma de cdage à mdulatin par impulsins et cdage différentiel adaptatif (ADPCM, adaptive delta pulse cde mdulatin) qui a été spécifié par l'assciatin du multimédia interactif (IMA, Interactive Multimedia Assciatin) cmme "type d'nde ADPCM IMA". Cependant, le cdage défini ici cmme DVI4 diffère sus tris aspects de la spécificatin IMA : L'en-tête RTP DVI4 cntient la valeur prédite plutôt que la valeur du premier échantilln cntenu dans l'en-tête de blc ADPCM de l'ima. Les blcs ADPCM de l'ima cntiennent un nmbre impair d'échantillns, car le premier échantilln d'un blc est cntenu juste dans l'en-tête (nn cmpressé), suivi par un nmbre pair d'échantillns cmpressés. DVI4 a seulement un nmbre pair d'échantillns cmpressés, utilisant le mt "predict" prvenant de l'en-tête pur décder le premier échantilln. Pur DVI4, les échantillns de quatre bits snt mis en paquet avec le premier échantilln des quatre bits de plus frt pids et le secnd échantilln dans les quatre bits de mindre pids. Dans le cdec ADPCM de l'ima, les échantillns snt mis en paquet dans l'rdre inverse. Chaque paquet cntient un seul blc DVI. Le présent prfil ne définit que la versin à 4 bits par échantilln, alrs que IMA spécifie aussi un cdage à 3 bits par échantilln. Le mt "header" (en-tête) a pur chaque canal la structure suivante : int16 predict; /* valeur prédite du premier échantilln prvenant du blc précédent (frmat L16) */ u_int8 index; /* indice actuel dans le tableau stepsize */ u_int8 reserved; /* mis à zér par l'envyeur, ignré par le receveur */

RFC 3551 page - 8 - Schulzrinne & Casner Chaque ctet suivant l'en-tête cntient deux échantillns de 4 bits, et dnc le nmbre d'échantillns par paquet DOIT être pair parce que il n'y a aucun myen d'indiquer que le dernier ctet serait partiellement rempli. La mise en paquet des échantillns pur des canaux multiples fera l'bjet d'études ultérieures. L'algrithme ADPCM de l'ima a été décrit dans le dcument "Pratiques recmmandées par l'ima pur l'améliratin de la cmpatibilité audi numérique dans les systèmes multimédia (versin 3.0)". Cependant, l'assciatin pur le multimédia interactif a cessé de fnctinner en 1997. Les ressurces de cpies archivées de ce dcument et d'un lgiciel de mise en œuvre du cdage RTP DVI4 snt décrites à la Sectin 13. 4.5.2 G722 G722 est spécifié dans la Recmmandatin UIT-T G.722, "Cdage audi à 7 khz sur 64 kbit/s". Le cdeur G.722 prduit un flux d'ctets, dnt chacun DOIT être aligné sur l'ctet dans un paquet RTP. Le premier bit transmis dans l'ctet G.722, qui est le bit de pids frt de l'échantilln de la sus bande la plus élevée, DOIT crrespndre au bit de pids frt de l'ctet dans le paquet RTP. Bien que le taux d'échantillnnage réel de l'audi G.722 sit de 16 000 Hz, le débit d'hrlge RTP pur le frmat de charge utile G722 est de 8 000 Hz parce que cette valeur était alluée par erreur dans la RFC 1890 et dit rester inchangée pur la rétr cmpatibilité. Le débit d'ctet u débit de paire d'échantillns est de 8 000 Hz. 4.5.3 G723 G723 est spécifié dans la Recmmandatin UIT-T G.723.1, "Cdeur de parle à deux débits pur les cmmunicatins multimédia émises à 5,3 et 6,3 kbit/s". Le cdeur G.723.1 à 5,3/6,3 kbit/s a été défini par l'uit-t cmme cdec bligatire pur les applicatins de terminaux de visiphnie GSTN de la Recmmandatin UIT-T H.324. L'algrithme a une spécificatin de virgule flttante dans l'annexe B à G.723.1, un algrithme de cmpressin de silence dans l'annexe A et un schéma de cdage de canal échelnnable pur les applicatins sans fil dans l'annexe C. La présente Recmmandatin spécifie une représentatin cdée qui peut être utilisée pur cmpresser les cmpsants du signal de parle de services multimédia à un très bas débit binaire. L'audi est cdé dans des trames de 30 ms, avec un délai supplémentaire de 7,5 ms dû à la pré analyse. Une trame G723 peut être d'une parmi tris tailles : 24 ctets (trame de 6,3 kbit/s), 20 ctets (trame de 5,3 kbit/s), u 4 ctets. Ces trames de 4 ctets snt appelées trames de descripteur d'insertin de silence (SID, Silence Insertin Descriptr) et snt utilisées pur spécifier les paramètres du bruit de fnd. Il n'y a pas de restrictin sur la façn dnt les trames à 4, 20, et 24 ctets snt entremêlées. Les deux bits de mindre pids du premier ctet de la trame déterminent la taille de la trame et le type du cdec : bits cntenu ctets/trame 00 parle à haut débit (6,3 kbit/s) 24 01 parle à bas débit (5,3 kbit/s) 20 10 trame SID 4 11 réservé Il est pssible de cmmuter entre les deux débits à tute frntière de trame de 30 ms. Les deux débits (5,3 kbit/s et 6,3 kbit/s) snt une partie bligatire du cdeur et du décdeur. Les receveurs DOIVENT accepter les deux débits de dnnées et DOIVENT accepter les trames SID à mins que des restrictins à ces capacités aient été signalées. L'enregistrement MIME pur G723 dans la RFC 3555 [7] spécifie les paramètres qui PEUVENT être utilisés avec MIME u SDP pur restreindre à un seul débit de dnnées u pur interdire l'utilisatin des trames SID. Ce cdeur a été ptimisé pur représenter la parle avec une qualité presque parfaite aux débits ci-dessus en limitant cependant la cmplexité. Le paquetage du flux binaire cdé en ctets et l'rdre de transmissin des ctets snt spécifiés dans la Recmmandatin UIT-T G.723.1 et snt les mêmes que ceux prduits par la mise en œuvre de référence du cde C de G.723. Pur le débit de dnnées de 6,3 kbit/s, ce paquetage est illustré cmme suit, avec les bits d'en-tête (HDR) qui snt tujurs "0 0" cmme le mntre la Figure 1 pur indiquer le fnctinnement à 6,3 kbit/s, et le bit Z est tujurs mis à zér. Le diagramme mntre le paquetage binaire dans "l'rdre des ctets du réseau", aussi appelé rdre grs-butien. Les bits de chaque mt de 32 bits snt numértés de 0 à 31, avec le bit de pids frt à gauche et numérté 0. Les ctets de chaque mt snt transmis avec l'ctet de pids frt en premier. Les bits de chaque champ de dnnées snt numértés dans l'rdre de représentatin du flux binaire du cdage (bit de mindre pids en premier). Les barres verticales indiquent les frntières entre les fragments de champ.

RFC 3551 page - 9 - Schulzrinne & Casner 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 LPC HDR LPC LPC ACL0 LPC 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 2 2 1 1 1 1 1 1 0 0 0 0 0 0 2 2 5 4 3 2 1 0 3 2 1 0 9 8 7 6 1 0 9 8 7 6 5 4 5 4 3 2 1 0 3 2 ACL2 ACL A GAIN0 ACL ACL GAIN0 GAIN1 1 C 3 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 3 2 1 0 1 0 6 3 2 1 0 1 0 6 5 1 0 9 8 7 6 5 4 7 6 5 4 3 2 1 0 GAIN2 GAIN1 GAIN2 GAIN3 GRID GAIN3 0 0 0 0 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 3 2 1 0 1 0 9 8 1 0 9 8 7 6 5 4 7 6 5 4 3 2 1 0 3 2 1 0 1 0 9 8 MSBPOS Z POS MSBPOS POS0 POS POS0 0 1 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 6 5 4 3 2 1 0 1 0 2 1 0 9 8 7 9 8 7 6 5 4 3 2 1 0 5 4 3 2 1 0 POS1 POS2 POS1 POS2 POS3 POS2 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 9 8 7 6 5 4 3 2 3 2 1 0 3 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 5 4 3 2 POS3 PSIG0 POS PSIG2 PSIG1 PSIG3 PSIG2 3 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 5 4 3 2 1 0 3 2 2 1 0 4 3 2 1 0 4 3 2 1 0 5 4 3 Figure 1 : Paquetage binaire de G.723 (6,3 kbit/s) Pur le débit de dnnées à 5,3 kbit/s, les bits d'en-tête (HDR) snt tujurs "0 1", cmme le mntre la Figure 2, pur indiquer le fnctinnement à 5,3 kbit/s. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 LPC HDR LPC LPC ACL0 LPC 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 2 2 1 1 1 1 1 1 0 0 0 0 0 0 2 2 5 4 3 2 1 0 3 2 1 0 9 8 7 6 1 0 9 8 7 6 5 4 5 4 3 2 1 0 3 2 ACL2 ACL A GAIN0 ACL ACL GAIN0 GAIN1 1 C 3 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 3 2 1 0 1 0 6 3 2 1 0 1 0 6 5 1 0 9 8 7 6 5 4 7 6 5 4 3 2 1 0 GAIN2 GAIN1 GAIN2 GAIN3 GRID GAIN3 0 0 0 0 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 3 2 1 0 1 0 9 8 1 0 9 8 7 6 5 4 7 6 5 4 3 2 1 0 4 3 2 1 1 0 9 8 POS0 POS1 POS0 POS1 POS2 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 6 5 4 3 2 1 0 3 2 1 0 1 0 9 8 1 0 9 8 7 6 5 4 7 6 5 4 3 2 1 0 POS3 POS2 POS3 PSIG1 PSIG0 PSIG3 PSIG2

RFC 3551 page - 10 - Schulzrinne & Casner 0 0 0 0 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 2 1 0 1 0 9 8 1 0 9 8 7 6 5 4 3 2 1 0 3 2 1 0 3 2 1 0 3 2 1 0 Figure 2 : Paquetage binaire de G.723 (5,3 kbit/s) Le paquetage des trames SID de G.723.1, qui snt indiquées par les bits d'en-tête (HDR) qui nt le schéma "1 0", est décrit à la Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 LPC HDR LPC LPC GAIN LPC 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 2 2 1 1 1 1 1 1 0 0 0 0 0 0 2 2 5 4 3 2 1 0 3 2 1 0 9 8 7 6 1 0 9 8 7 6 5 4 5 4 3 2 1 0 3 2 Figure 3 : Paquetage binaire de G.723 en mde SID 4.5.4 G726-40, G726-32, G726-24 et G726-16 La Recmmandatin UIT-T G.726 décrit, entre autres, l'algrithme recmmandé pur la cnversin d'un seul canal MIC li A u li µ à 64 kbit/s cdé à 8 000 échantillns/s en et de canal à 40, 32, 24, u 16 kbit/s. La cnversin est appliquée au flux MIC en utilisant une technique de transcdage MICDA, mdulatin par impulsins et cdage différentiel adaptatif (ADPCM, Adaptive Differential Pulse Cde Mdulatin). La représentatin MICDA cnsiste en une série de cdets avec une crrespndance biunivque aux échantillns du flux MIC. Les débits de dnnées G726 de 40, 32, 24 et 16 kbit/s nt des cdets de respectivement 5, 4, 3 et 2 bits. Les cdages à 16 et 24 kbit/s ne furnissent pas la qualité de parle parfaite. Ils snt cnçus pur utilisatin sur des EMCN, équipements de multiplicatin de circuit numérique (DCME, Digital Circuit Multiplicatin Equipment) surchargés. La Recmmandatin UIT-T G.726 recmmande que les cdages à 16 et 24 kbit/s sient alternés avec des cdages à plus hauts débits afin de furnir une taille d'échantilln myenne entre 3,5 et 3,7 bits par échantilln. Les cdages de G.726 snt ntés ici G726-40, G726-32, G726-24 et G726-16. Avant 1990, G721 décrivait le cdage MICDA à 32 kbit/s et G723 décrivait les cdages à 40, 32 et 16 kbit/s. Et dnc, G726-32 désigne le même algrithme que G721 dans la RFC 1890. Un flux de cdets G726 ne cntient aucune infrmatin sur le cdage utilisé, et dnc, les transitins entre types de cdage G726 ne snt pas permis au sein d'une séquence de cdets empaquetés. Les applicatins DOIVENT déterminer le type de cdage des cdets empaquetés à partir de l'identifiant de charge utile RTP. Aucune infrmatin d'en-tête spécifique de la charge utile ne DEVRA être incluse au titre des dnnées audi. Un flux de cdets G726 DOIT être empaqueté en ctets cmme suit : le premier cdet est placé dans le premier ctet de telle srte que le bit de mindre pids du cdet s'aligne sur le bit de mindre pids de l'ctet, que le secnd cdet sit alrs empaqueté de telle srte que le bit de mindre pids cïncide avec le bit de mindre pids inccupé dans l'ctet. Lrsque un cdet cmplet ne peut être placé dans un ctet, les bits qui chevauchent la frntière de l'ctet snt placés dans les bits de mindre pids du prchain ctet. L'empaquetage DOIT se terminer sur un ctet final cmplètement empaqueté. Le nmbre de cdets empaquetés va dnc être un multiple de 8, 2, 8 et 4 pur, respectivement, G726-40, G726-32, G726-24 et G726-16. Un exemple de schéma d'empaquetage pur des cdets G726-32 est dnné ci-dessus, ù le bit 7 est le bit de mindre pids du premier ctet, et le bit A3 est le bit de mindre pids du premier cdet : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- B B B B A A A A D D D D C C C C... 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Un exemple de schéma d'empaquetage pur des cdets G726-24 est dnné ci-dessus, avec encre le bit 7 cmme bit de mindre pids du premier ctet, et le bit A2 cmme bit de mindre pids du premier cdet :

RFC 3551 page - 11 - Schulzrinne & Casner 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- C C B B B A A A F E E E D D D C H H H G G G F F... 1 2 0 1 2 0 1 2 2 0 1 2 0 1 2 0 0 1 2 0 1 2 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Nter que la directin "petite butienne" dans laquelle les échantillns snt empaquetés en ctets dans les frmats de charge utile G726-16, -24, -32 et -40 spécifiés ici est chérente avec la Recmmandatin UIT-T X.420, mais est à l'inverse de ce que spécifie l'annexe E de la Recmmandatin UIT-T I.366.2 pur le transprt AAL2 en ATM. Un secnd ensemble de frmats de charge utile RTP crrespndant à la mise en paquet de I.366.2 Annexe E et identifié par les sus-types MIME AAL2-G726-16, -24, -32 et -40 sera spécifié dans un autre dcument. 4.5.5 G728 G728 est spécifié dans la Recmmandatin UIT-T G.728, "Cdage de la parle à 16 kbit/s utilisant la prédictin linéaire à faible délai avec excitatin par cde". Un cdeur G.278 traduit cinq échantillns audi cnsécutifs en un indice de cdets de 10 bits, résultant en un débit binaire de 16 kbit/s pur l'audi échantillnné à 8 000 échantillns par secnde. Le grupe de cinq échantillns cnsécutifs est appelé un vecteur. Quatre vecteurs cnsécutifs, marqués V1 à V4 (ù V1 est à exécuter en premier par le receveur) cnstruisent une trame G.728. Les quatre vecteurs de 40 bits snt empaquetés dans cinq ctets, marqués B1 à B5. B1 DEVRA être placé en premier dans le paquet RTP. En se référant à la figure ci-dessus, le principe pur l'rdre des bits est la "cnservatin de la pndératin binaire". Les bits prvenant d'un vecteur plus ancien snt de plus frt pids que les bits prvenant des vecteurs plus récents. Le MSB de la trame va au MSB de B1 et le LSB de la trame va au LSB de B5. 1 2 3 3 0 0 0 0 9 ++++++++++++++++++++++++++++++++++++++++ <---V1---><---V2---><---V3---><---V4---> vecteurs <--B1--><--B2--><--B3--><--B4--><--B5--> ctets <------------- trame 1 ----------------> En particulier, B1 cntient les huit bits de plus frts pids de V1, le MSB de V1 étant le MSB de B1. B2 cntient les deux bits de mindre pids de V1, celui de plus frt pids des deux dans sn MSB, et les six bits de plus frt pids de V2. B1 DEVRA être placé en premier dans le paquet RTP et B5 en dernier. 4.5.6 G729 G729 est spécifié dans la Recmmandatin UIT-T G.729, "Cdage de la parle à 8 kbit/s en prédictin linéaire à excitatin par séquences cdées à structure algébrique cnjuguée (CS-ACELP, cnjugate structure-algebraic cde excited linear predictin)". Une versin à cmplexité réduite de l'algrithme G.729 est spécifié à l'annexe A de la Recmmandatin UIT- T G.729. Les algrithmes de cdage de la parle dans le crps de G.729 et dans l'annexe A de G.729 snt pleinement interpérables entre eux, de srte qu'il n'est pas besin de distinguer entre eux. Une mise en œuvre qui signale u accepte l'utilisatin du frmat de charge utile G729 peut mettre en œuvre G.729 u G.729A sauf interdit par de la signalisatin supplémentaires spécifiée ailleurs se rapprtant spécifiquement au cdage plutôt qu'au frmat de charge utile. Les cdecs G.729 et G.729 Annexe A nt été ptimisés pur représenter la parle avec une grande qualité, mais G.729 Annexe A trque un peu de qualité vcale pur une réductin d'envirn 50 % de la cmplexité [10]. Vir au paragraphe suivant (4.5.7) les autres débits de dnnées ajutés dans les annexes ultérieures de G.729. Pur tus les débits de dnnées, la fréquence d'échantillnnage (et le débit d'hrlge d'hrdatage RTP) est de 8 000 Hz. Un algrithme de détecteur d'activité vcale (VAD) et de générateur de bruit de cnfrt (CNG) dans l'annexe B de G.729 est RECOMMANDÉ pur les applicatins de vix et dnnées numériques simultanées et peut être utilisé cnjintement avec G.729 u G.729 Annexe A. Une trame G.729 u G.729 Annexe A cntient 10 ctets, alrs que la trame de bruit de cnfrt de G.729 Annexe B ccupe 2 ctets. Les receveurs DOIVENT accepter les trames de bruit de cnfrt si l'interdictin de leur utilisatin n'a pas été signalée. L'enregistrement MIME pur G729 dans la RFC 3555 [7] spécifie un paramètre qui PEUT être utilisé avec MIME u SDP pur interdire l'usage de trames de bruit de cnfrt. Un paquet RTP G729 peut cnsister en zér, une u plusieurs trames G.729 u G.729 Annexe A, suivi par zér u une trame G.729 Annexe B. La présence d'une trame de bruit de cnfrt peut se déduire de la lngueur de la charge utile RTP.

RFC 3551 page - 12 - Schulzrinne & Casner L'intervalle de mise en paquet par défaut est de 20 ms (deux trames), mais dans certaines situatins il peut être suhaitable d'envyer des paquets à 10 ms. Un exemple serait une transitin de la parle au bruit de cnfrt dans le premier paquet à 10 ms. Pur certaines applicatins, un intervalle de mise en paquet plus lng peut être nécessaire pur réduire le débit de paquets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 L L1 L2 L3 P1 P C1 0 0 0 1 2 3 4 5 6 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 5 6 7 0 1 2 3 4 C1 S1 GA1 GB1 P2 C2 1 1 1 5 6 7 8 9 0 1 2 0 1 2 3 0 1 2 0 1 2 3 0 1 2 3 4 0 1 2 3 4 5 6 7 C2 S2 GA2 GB2 1 1 1 8 9 0 1 2 0 1 2 3 0 1 2 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 : Paquetage binaire de G.729 et G.729A Les paramètres transmis d'une trame G.729/G.729A à 10 ms, cnsistant en 80 bits, snt définis dans la Recmmandatin G.729, Tableau 8/G.729. La transpsitin de ces paramètres est dnnée ci-dessus à la Figure 4. Le diagramme mntre le paquetage binaire dans "l'rdre des ctets du réseau", aussi appelé rdre grs-butien. Les bits de chaque mt de 32 bits snt numértés de 0 à 31, le bit de pids frt à gauche et numérté 0. Les ctets de chaque mt snt transmis le plus frt pids en premier. Les bits de chaque champ de dnnées snt numértés dans l'rdre ù ils snt prduits par la mise en œuvre de référence de cde C de G.729. Le paquetage de la trame de bruit de cnfrt de G.729 Annexe B est indiqué ci-dessus à la Figure 5. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L LSF1 LSF2 GAIN R S E F S 0 0 1 2 3 4 0 1 2 3 0 1 2 3 4 V RESV = Réservé (à zér) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 : Paquetage binaire de G.729 Annexe B 4.5.7 G729D et G729E Les Annexes D et E à la Recmmandatin UIT-T G.729 dnnent des débits de dnnées supplémentaires. Cmme le débit des dnnées n'est pas signalé dans le flux binaire, les différents débits de dnnées reçivent des nm de cdage RTP distincts qui snt transpsés en numérs de type de charge utile distincts. G729D indique un mde de cdage à 6,4 kbit/s (G.729 Annexe D, pur une réductin mmentanée de la capacité du canal), tandis que G729E indique un mde à 11,8 kbit/s (G.729 Annexe E, pur des perfrmances amélirées avec une large gamme de signaux d'entrée à bas débit, par exemple, de la musique et du bruit de fnd). L'Annexe E a deux mdes de fnctinnement, adaptif différé et adaptif anticipé, qui snt signalés par les deux premiers bits de chaque trame (les deux bits de plus frt pids du premier ctet). L'algrithme de détecteur d'activité vcale (VAD) et de générateur de bruit de cnfrt (CNG) spécifié dans l'annexe B de G.729 peut être utilisé avec les trames de l'annexe D et de l'annexe E en plus des trames de G.729 et G.729 Annexe A. Les détails de l'algrithme pur le fnctinnement des Annexes D et E avec la CNG de l'annexe B snt spécifiés dans les Annexes F et G de G.729. Nter que les Annexes F et G n'intrduisent aucun nuveau cdage. Les receveurs DOIVENT accepter les trames de bruit de cnfrt si l'interdictin de leur usage n'a pas été signalée. L'enregistrement MIME pur G729D et G729E dans la RFC 3555 [7] spécifie un paramètre qui PEUT être utilisé avec MIME u SDP pur interdire l'usage des trames de bruit de cnfrt. Pur G729D, un paquet RTP peut cmprter zér, une u plusieurs trames G.729 Annexe D, suivies par zér u une trame G.729 Annexe B. De même, pur G729E, un paquet RTP peut cmprter zér, une u plusieurs trames G.729 Annexe E,

RFC 3551 page - 13 - Schulzrinne & Casner suivies par zér u une trame G.729 Annexe B. La présence d'une trame de bruit de cnfrt peut être déduite de la lngueur de la charge utile RTP. Un seul paquet RTP dit cntenir des trames d'un seul débit de dnnées, facultativement suivies par une trame de bruit de cnfrt. Le débit de dnnées peut être changé d'un paquet à l'autre en changeant le numér de type de charge utile. Les Annexes D, E et H de G.729 décrivent ce que divent être les algrithmes de cdage et de décdage pur s'accmmder d'un changement du débit des dnnées. Pur G729D, les bits d'une trame G.729 Annexe D snt frmatées cmme indiqué ci-dessus à la Figure 6 (cf. Tableau D.1/G.729). La lngueur de la trame est de 64 bits. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 L L1 L2 L3 P1 C1 0 0 1 2 3 4 5 6 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 5 6 7 0 1 2 3 4 5 C1 S1 GA1 GB1 P2 C2 S2 GA2 GB2 6 7 8 0 1 0 1 2 0 1 2 0 1 2 3 0 1 2 3 4 5 6 7 8 0 1 0 1 2 0 1 2 Figure 6 : Paquetage binaire de G.729 Annexe D Le débit binaire net pur l'algrithme G.729 Annexe E est de 11,8 kbit/s et un ttal de 118 bits est utilisé. Deux bits snt ajutés cmme bits "à ne pas prendre en cmpte" pur cmpléter un nmbre entier d'ctets pur la trame. Pur G729E, les bits d'une trame de dnnées snt frmatés cmme indiqué dans les deux diagrammes suivants (cf. Tableau E.1/G.729). Les champs pur le mde adaptatif anticipé de G729E snt empaquetés cmme indiqué à la Figure 7. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 0 L L1 L2 L3 P1 P C0_1 0 0 0 1 2 3 4 5 6 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 5 6 7 0 1 2 C1_1 C2_1 C3_1 C4_1 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 GA1 GB1 P2 C0_2 C1_2 C2_2 0 1 2 0 1 2 3 0 1 2 3 4 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 C3_2 C4_2 GA2 GB2 DC 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 0 1 2 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 : Paquetage binaire de G.729 Annexe E (mde d'adaptatin vers l'avant) Les champs pur le mde adaptatif différé de G729E snt empaquetés cmme indiqué à la Figure. 8.

RFC 3551 page - 14 - Schulzrinne & Casner 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1 1 P1 P C0_1 C1_1 0 1 1 1 0 1 2 3 4 5 6 7 0 0 1 2 3 4 5 6 7 8 9 0 1 2 0 1 2 3 4 5 6 7 C2_1 C3_1 C4_1 GA1 GB1 P2 8 9 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 0 1 2 3 0 1 C0_2 C1_2 C2_2 1 1 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 C3_2 C4_2 GA2 GB2 DC 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 0 1 2 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.5.8 GSM Figure 8 : Paquetage binaire de G.729 Annexe E (mde d'adaptatin vers l'arrière) GSM (Grupe Spécial Mbiles) désigne la nrme eurpéenne GSM 06.10 pur le cdage de la parle à plein débit, ETS 300 961, qui se fnde sur le cdage à excitatin par impulsin régulière avec prédictin à lng terme (RPE/LTP, residual pulse excitatin/lng term predictin) au débit de 13 kbit/s [11, 12, 13]. Le texte de la nrme peut être btenu à : ETSI (Institut eurpéen des nrmes de télécmmunicatins) ETSI Secretariat: B.P.152 06561 Valbnne CedexFrance téléphne : +33 92 94 42 00 fax : +33 93 65 47 16 (Versin française dispnible à l'afnor) Les blcs de 160 échantillns audi snt cmpressés en 33 ctets, pur un débit de dnnées efficace de 13 200 bit/s. 4.5.8.1 Prblèmes généraux du paquetage La nrme GSM (ETS 300 961) spécifie le flux binaire prduit par le cdec, mais ne spécifie pas cmment ces bits devraient être mis en paquets pu la transmissin. La mise en paquet spécifiée ici a ultérieurement été adptée dans la spécificatin technique ETSI TS 101 318. Certains lgiciels de cdec GSM utilisent un paquetage différent de celui spécifié ici. Champ Nm bits Champ Nm bits Champ Nm bits Champ Nm bits 1 LARc[0] 6 20 xmc[7] 3 39 xmc[22] 3 58 xmc[37] 3 2 LARc[1] 6 21 xmc[8] 3 40 xmc[23] 3 59 xmc[38] 3 3 LARc[2] 5 22 xmc[9] 3 41 xmc[24] 3 60 Nc[3] 7 4 LARc[3] 5 23 xmc[10] 3 42 xmc[25] 3 61 bc[3] 2 5 LARc[4] 4 24 xmc[11] 3 43 Nc[2] 7 62 Mc[3] 2 6 LARc[5] 4 25 xmc[12] 3 44 bc[2] 2 63 xmaxc[3] 6 7 LARc[6] 3 26 Nc[1] 7 45 Mc[2] 2 64 xmc[39] 3 8 LARc[7] 3 27 bc[1] 2 46 xmaxc[2] 6 65 xmc[40] 3 9 Nc[0] 7 28 Mc[1] 2 47 xmc[26] 3 66 xmc[41] 3 10 bc[0] 2 29 xmaxc[1] 6 48 xmc[27] 3 67 xmc[42] 3 11 Mc[0] 2 30 xmc[13] 3 49 xmc[28] 3 68 xmc[43] 3 12 xmaxc[0] 6 31 xmc[14] 3 50 xmc[29] 3 69 xmc[44] 3 13 xmc[0] 3 32 xmc[15] 3 51 xmc[30] 3 70 xmc[45] 3 14 xmc[1] 3 33 xmc[16] 3 52 xmc[31] 3 71 xmc[46] 3 15 xmc[2] 3 34 xmc[17] 3 53 xmc[32] 3 72 xmc[47] 3 16 xmc[3] 3 35 xmc[18] 3 54 xmc[33] 3 73 xmc[48] 3 17 xmc[4] 3 36 xmc[19] 3 55 xmc[34] 3 74 xmc[49] 3 18 xmc[5] 3 37 xmc[20] 3 56 xmc[35] 3 75 xmc[50] 3 19 xmc[6] 3 38 xmc[21] 3 57 xmc[36] 3 76 xmc[51] 3 Tableau 2 : Ordre des variables du GSM

RFC 3551 page - 15 - Schulzrinne & Casner Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3 1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5 2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2 3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1 4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2 5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0 6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04 7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0 8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2 9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1 10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0 11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2 12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0 13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14 14 xmax15 xmc13.0 xmc13.1 xmc13.2 xmc14.0 xmc14.1 xmc14.2 xmc15.0 15 xmc15.1 xmc15.2 xmc16.0 xmc16.1 xmc16.2 xmc17.0 xmc17.1 xmc17.2 16 xmc18.0 xmc18.1 xmc18.2 xmc19.0 xmc19.1 xmc19.2 xmc20.0 xmc20.1 17 xmc20.2 xmc21.0 xmc21.1 xmc21.2 xmc22.0 xmc22.1 xmc22.2 xmc23.0 18 xmc23.1 xmc23.2 xmc24.0 xmc24.1 xmc24.2 xmc25.0 xmc25.1 xmc25.2 19 Nc2.0 Nc2.1 Nc2.2 Nc2.3 Nc2.4 Nc2.5 Nc2.6 bc2.0 20 bc2.1 Mc2.0 Mc2.1 xmaxc20 xmaxc21 xmaxc22 xmaxc23 xmaxc24 21 xmaxc25 xmc26.0 xmc26.1 xmc26.2 xmc27.0 xmc27.1 xmc27.2 xmc28.0 22 xmc28.1 xmc28.2 xmc29.0 xmc29.1 xmc29.2 xmc30.0 xmc30.1 xmc30.2 23 xmc31.0 xmc31.1 xmc31.2 xmc32.0 xmc32.1 xmc32.2 xmc33.0 xmc33.1 24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0 25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2 26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0 27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34 28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0 29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2 30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1 31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0 32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2 Tableau 3 : Frmat de charge utile GSM Dans le paquetage GSM utilisé par RTP, les bits DEVRONT être mis en paquet en cmmençant par le bit de pids frt. Tus les 160 échantillns, la trame GSM est cdée dans une mémire tampn de 33 ctets (264 bits). Chacune de ces mémires tampn cmmence par une signature de 4 bits (0xD), suivie par le cdage MSB des champs de la trame. Le premier ctet cntient dnc 1101 dans les 4 bits de plus frt pids (0 à 3) et les 4 bits de plus frt pids de F1 (0 à 3) dans les 4 bits de mindre pids (4 à 7). Le secnd ctet cntient les 2 bits de mindre pids de F1 dans les bits 0 et 1, et F2 dans les bits 2 à 7, et ainsi de suite. L'rdre des champs dans la trame est décrit au Tableau 2. 4.5.8.2 Nms et numérs de variable GSM Dans le cdage RTP, nus avns le schéma binaire décrit au Tableau 3, ù F.i signifie le i ème bit du champ F, le bit 0 est le bit de plus frt pids, et les bits de chaque ctet snt numértés de 0 à 7 du plus frt au mindre pids. 4.5.9 GSM-EFR GSM-EFR désigne le cdage vcal à plein débit améliré GSM 06.60, spécifié dans l'ets 300 726 qui est dispnible auprès d'etsi à l'adresse dnnée au paragraphe 4.5.8. Ce cdec a une lngueur de trame de 244 bits. Pur la transmissin en RTP, chaque trame du cdec est empaquetée dans une mémire tampn de 31 ctet (248 bit) cmmençant par une signature de 4 bits 0xC de la même façn que celle spécifiée ici pur le cdec riginal GSM 06.10. L'empaquetage est spécifié dans la spécificatin technique ETSI TS 101 318. 4.5.10 L8 L8 désigne les échantillns de dnnées audi linéaires, qui utilisent 8 bits de précisin avec un décalage de 128, c'est-à-dire que le signal le plus négatif est cdé cmme zér.

RFC 3551 page - 16 - Schulzrinne & Casner 4.5.11 L16 L16 désigne les échantillns de dnnées audi nn cmpressés, en utilisant une représentatin de 16 bits signée avec 65 535 étapes également divisées entre niveau de signal minimum et maximum, allant de -32 768 à 32 767. La valeur est représentée en ntatin de cmplément à deux et transmise dans l'rdre des ctets du réseau (ctet de pids frt en premier). L'enregistrement MIME pur L16 dans la RFC 3555 [7] spécifie les paramètres qui PEUVENT être utilisés avec MIME u SDP pur indiquer que la pré amplificatin analgique a été appliquée au signal avant sa quantificatin u pur indiquer qu'un flux audi multi canaux suit une cnventin de rangement des canaux différente de celle qui est spécifiée au paragraphe 4.1. 4.5.12 LPC LPC désigne un cdage prédictif linéaire expérimental prpsé par Rn Frederick, qui se fnde sur une mise en œuvre écrite par Rn Zuckerman envyée au grupe Usenet cmp.dsp le 26 juin 1992. Le cdec génère 14 ctets pur chaque trame. La taille de trame est réglée à 20 ms, résultant en un débit binaire de 5 600 bit/s. 4.5.13 MPA MPA désigne de l'audi MPEG-1 u MPEG-2 encapsulé cmme flux élémentaires. Le cdage est défini dans les nrmes ISO/CEI 11172-3 et 13818-3. L'encapsulatin est spécifiée dans la RFC 2250 [14]. Le cdage peut avir un des tris niveaux de cmplexité suivants, appelés Cuche I, II et III. La cuche chisie ainsi que le taux d'échantillnnage et le nmbre de canaux snt indiqués dans la charge utile. Le débit d'hrlge de l'hrdatage RTP est tujurs de 90 000, indépendamment du taux d'échantillnnage. L'audi MPEG-1 prend en charge des taux d'échantillnnage de 32, 44,1, et 48 khz (ISO/CEI 11172-3, sectin 1.1 "Dmaine d'applicatin"). MPEG-2 prend en charge des taux d'échantillnnage de 16, 22,05 et 24 khz. Le nmbre d'échantillns par trame est fixe, mais la taille des trames va varier seln le taux d'échantillnnage et le débit binaire. L'enregistrement MIME pur MPA dans la RFC 3555 [7] spécifie des paramètres qui PEUVENT être utilisés avec MIME u SDP pur interdire le chix d'une cuche, du cmpte de canaux, du taux d'échantillnnage, et du débit binaire. 4.5.14 MICA et MICU Le MICA et le MICU snt spécifiés dans la Recmmandatin UIT-T G.711. Les dnnées audi snt cdées avec huit bits par échantilln, après échelnnement lgarithmique. Le MICU désigne l'échelnnement seln la li µ, le MICA l'échelnnement seln la li A. Une descriptin détaillée est dnnée par Jayant et Nll [15]. Chaque ctet G.711 DEVRA être aligné sur l'ctet dans un paquet RTP. Le bit de signe de chaque ctet G.711 DEVRA crrespndre au bit de plus frt pids de l'ctet dans le paquet RTP (c'est-à-dire, en suppsant que les échantillns G.711 snt traités cmme des ctets sur la machine hôte, le bit de signe DEVRA être le bit de plus frt pids de l'ctet cmme défini par le frmat de la machine hôte). Les mdes 56 kbit/s et 48 kbit/s de G.711 ne snt pas applicables à RTP, car le MICA et le MICU DOIVENT tujurs être transmis cmme des échantillns à 8 bits. Vir au paragraphe 4.1 au sujet de la suppressin de silence. 4.5.15 QCELP La nrme IS-733, "TR45 : Optin de service vcal à haut débit pur systèmes de cmmunicatins large bande à étalement de spectre", de l'assciatin des industries électrniques (EIA) et de l'assciatin des industries de télécmmunicatins (TIA) définit l'algrithme de cmpressin audi QCELP pur une utilisatin dans les applicatins AMRC sans fil. Le cdec QCELP cmpresse chaque 20 millisecndes d'entrées de parle à 8 000 Hz, échantillnnée sur 16 bits dans une des quatre différentes tailles de trame de srtie : taux 1 (266 bits), taux 1/2 (124 bits), taux 1/4 (54 bits) u taux 1/8 (20 bits). Pur les schémas de parle nrmaux, il en résulte une srtie myenne de 6,8 kbit/s pur le mde nrmal et de 4,7 kbit/s pur le mde à taux réduit. La mise en paquet du cdec audi QCELP est décrite dans [16]. 4.5.16 RED Le frmat de charge utile audi redndant "RED" est spécifié par la RFC 2198 [17]. Il définit le myen par lequel plusieurs cpies redndantes d'un paquet audi peuvent être transmises dans un seul flux RTP. Chaque paquet d'un tel flux cntient, en plus des dnnées audi pur cet intervalle de mise en paquet, une cpie (plus lurdement cmpressée) des dnnées d'un intervalle de mise en paquet précédent. Cela permet une apprximatin de récupératin des dnnées prvenant des paquets

RFC 3551 page - 17 - Schulzrinne & Casner perdus lrs du décdage du paquet suivant, dnnant une qualité snre amélirée cmparée à la substitutin au silence des paquets perdus. 4.5.17 VDVI VDVI est une versin à débit variable de DVI4, qui dnne des débits binaires de parle entre 10 et 25 kbit/s. Elle est spécifiée seulement pur le fnctinnement sur un seul canal. Les échantillns snt mis en paquets dans les ctets en cmmençant par le bit de pids frt. Le dernier ctet est empaqueté avec des bits 1 si le dernier échantilln ne remplit pas le dernier ctet. Ce burrage est distinct de celui des cdets valides. Le receveur dit détecter le burrage parce qu'il n'y a pas de cmpte explicite des échantillns dans le paquet. Elle utilise le cdage suivant : Cdet DVI4 Schéma binaire VDVI 0 00 1 010 2 1100 3 11100 4 111100 5 1111100 6 11111100 7 11111110 8 10 9 011 10 1101 11 11101 12 111101 13 1111101 14 11111101 15 11111111 5. Vidé Les paragraphes qui suivent décrivent les cdages vidé qui snt définis dans le présent mémire et dnnent les nms abrégés utilisés pur leur identificatin. Ces cdages vidé et leurs types de charge utile snt énumérés au Tableau 5. Tus ces cdages vidé utilisent une fréquence d'hrdatage RTP de 90 000 Hz, la même que la fréquence d'hrdatage de présentatin MPEG. Cette fréquence dnne des incréments d'entiers exacts d'hrdatage pur les débits de trames nrmaux de 24 Hz (HDTV) 25 Hz (PAL) 29,97 Hz (NTSC) et 30 Hz (HDTV) et des débits de champ de 50, 59,94 et 60 Hz. Bien que 90 khz sit le débit RECOMMANDÉ pur les futurs cdages vidé utilisés au sein de ce prfil, d'autres débits PEUVENT être utilisés. Cependant, il n'est pas suffisant d'utiliser le débit de trame vidé (nrmalement entre 15 et 30 Hz) parce que cela ne furnit pas une réslutin adéquate pur les exigences nrmales de synchrnisatin lrs du calcul de l'hrdatage RTP crrespndant à l'hrdatage NTP dans un paquet SR de RTCP. La réslutin d'hrdatage DOIT aussi être suffisante pur l'estimatin de gigue cntenue dans les rapprts de receveur. Pur la plupart de ces cdages vidé, l'hrdatage RTP cde l'instant d'échantillnnage de l'image vidé cntenue dans le paquet de dnnées RTP. Si une image vidé ccupe plus d'un paquet, l'hrdatage est le même sur tus ces paquets. Les paquets prvenant de différentes images vidé snt distinguées par leurs hrdatages différents. La plupart de ces cdages vidé spécifient aussi que le bit marqueur de l'en-tête RTP DEVRAIT être mis à un dans le dernier paquet d'une trame vidé, et autrement mis à zér. Et dnc, il n'est pas nécessaire d'attendre un paquet suivant avec un hrdatage différent pur détecter qu'une nuvelle trame devrait être affichée. 5.1 CelB Le cdage CELL-B est un cdage breveté prpsé par Sun Micrsystems. Le frmat de flux d'ctets est décrit dans la RFC 2029 [18].

RFC 3551 page - 18 - Schulzrinne & Casner 5.2 JPEG Le cdage JËG est spécifié par les nrmes ISO 10918-1 et 10918-2. Le frmat de charge utile RTP est spécifié dans la RFC 2435 [19]. 5.3 H261 Le cdage est spécifié dans la Recmmandatin UIT-T H.261, "Vidé cdec pur services audivisuels à p x 64 kbit/s". La mise en paquet et les prpriétés spécifiques de RTP snt décrites dans la RFC 2032 [20]. 5.4 H263 Le cdage H263 est spécifié dans la versin 1996 de la Recmmandatin UIT-T H.263, "Cdage vidé pur cmmunicatin à faible débit binaire". La mise en paquet et les prpriétés spécifiques de RTP snt décrites dans la RFC 2190 [21]. Le frmat de charge utile H263-1998 est RECOMMANDÉ sur ce prfil avec les nuvelles mises en œuvre. 5.5 H263-1998 Ce cdage est spécifié dans la versin 1998 de la Recmmandatin UIT-T H.263, "Cdage Vidé pur cmmunicatin à faible débit binaire". La mise en paquet et les prpriétés spécifiques de RTP snt décrites dans la RFC 2429 [22]. Parce que la versin 1998 de H.263 est un surensemble de la syntaxe de 1996, ce frmat de charge utile peut aussi être utilisé avec la versin de 1996 de H.263, et sn utilisatin est RECOMMANDÉE pur les nuvelles mises en œuvre. Ce frmat de charge utile ne remplace pas la RFC 2190, qui cntinue d'être utilisée par les mises en œuvre existantes, et peut être requise pur la rétr cmpatibilité dans les nuvelles mises en œuvre. Les mises en œuvre qui utilisent les nuvelles caractéristiques de la versin 1998 de H.263 DOIVENT utiliser le frmat de charge utile décrit dans la RFC 2429. 5.6 MPV MPV désigne l'utilisatin des flux élémentaires de cdage vidé MPEG-1 et MPEG-2 cmme spécifié dans les nrmes ISO/CEI 11172 et 13818-2, respectivement. Le frmat de charge utile RTP est spécifié dans la RFC 2250 [14], Sectin 3. L'enregistrement MIME pur MPV dans la RFC 3555 [7] spécifie un paramètre qui PEUT être utilisé avec MIME u SDP pur interdire la sélectin du type vidé MPEG. 5.7 MP2T MP2T désigne l'utilisatin de flux de transprt MPEG-2, pur l'audi et/u la vidé. Le frmat de charge utile RTP est décrit dans la RFC 2250 [14], Sectin 2. 5.8 nv Ce cdage est mis en œuvre dans le prgramme `nv', versin 4, dévelppé chez Xerx PARC par Rn Frederick. Des infrmatins cmplémentaires peuvent être btenues de l'auteur : Rn Frederick Blue Cat Systems Inc. 650 Almanr Avenue Sunnyvale, CA 94085 USA mél : rnf@bluecat.cm 6. Définitins des types de charge utile Les Tableaux 4 et 5 définissent les valeurs de type de charge utile statique de ce prfil pur le champ PT de l'en-tête de dnnées RTP. De plus, les valeurs de type de charge utile dans la gamme 96 à 127 PEUVENT être définies de façn dynamique grâce à un prtcle de cntrôle de cnférence, qui srt du dmaine d'applicatin du présent dcument. Par exemple, un répertire de sessin purrait spécifier que pur une sessin dnnée, le type de charge utile 96 indique le cdage MICU, un taux d'échantillnnage de 8 000 Hz, 2 canaux. Les entrées dans les Tableaux 4 et 5 qui nt le type de

RFC 3551 page - 19 - Schulzrinne & Casner charge utile "dyn" n'nt pas de type de charge utile statique allué et ne snt utilisées qu'avec un type de charge utile dynamique. Le type de charge utile 2 avait été allué à G721 dans la RFC 1890 et à sn successeur équivalent G726-32 dans les versins préparatires de la présente spécificatin, mais sn utilisatin est maintenant décnseillée et ce type de charge utile statique est marqué cmme réservé à cause du cnflit sur l'utilisatin des frmats de charge utile G726-32 et AAL2-G726-32 (vir au paragraphe 4.5.4). Le type de charge utile 13 indique le frmat de charge utile de bruit de cnfrt (CN) spécifié dans la RFC 3389 [9]. Le type de charge utile 19 est marqué "réservé" parce que certaines versins préparatires de la présente spécificatin alluaient ce numér à une versin antérieure de ce frmat de charge utile de bruit de cnfrt. La gamme de type de charge utile 72 à 76 est marquée "réservé" afin que les paquets RTCP et RTP puissent être distingués de façn fiable (vir la Sectin "Résumé des cnstantes du prtcle" de la spécificatin du prtcle RTP). Les types de charge utile actuellement définis dans ce prfil snt allués à une seule des tris catégries u types de supprt : audi seul, vidé seule, et celles qui cmbinent audi et vidé. Les types de supprts snt respectivement marqués dans les Tableaux 4 et 5 cmme "A", "V" et "AV". Les types de charge utile des différent types de supprts NE DEVRONT PAS être entrelacés u multiplexés au sein d'une même sessin RTP, mais plusieurs sessins RTP PEUVENT être utilisées en parallèle pur envyer plusieurs types de supprts. Une surce RTP PEUT changer les types de charge utile au sein du même type de supprt durant une sessin. Vir la sectin "Multiplexage des sessins RTP" de la RFC 3550 pur des explicatins supplémentaires. PT nm du cdage type de supprt débit d'hrlge (Hz) canaux 0 MICU 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 MICA 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 (vir le 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 nn allué A 21 nn allué A 22 nn allué A 23 nn allué 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 variable variable dyn RED A (vir le texte) dyn VDVI A variable 1 Tableau 4 : Types de charge utile (PT) pur les cdages audi PT nm du cdage type de supprt débit d'hrlge (Hz) 24 nn allué V 25 CelB V 90 000 26 JPEG V 90 000 27 nn allué V 28 nv V 90 000

RFC 3551 page - 20 - Schulzrinne & Casner 29 nn allué V 30 nn allué V 31 H261 V 90 000 32 MPV V 90 000 33 MP2T AV 90 000 34 H263 V 90 000 35-71 nn allué? 72-76 réservé N/A N/A 77-95 nn allué? 96-127 dynamique? dyn H263-1998 V 90 000 Tableau 5 : Types de charge utile (PT) pur les cdages vidé et cmbinés Les participants à une sessin se mettent d'accrd, par des mécanismes qui srtent du dmaine d'applicatin de la présente spécificatin, sur l'ensemble de types de charge utile permis dans une sessin dnnée. Cet ensemble PEUT, par exemple, être défini par les capacités des applicatins utilisées, négciées par un prtcle de cntrôle de cnférence u établies par accrd entre les persnnes qui participent. Les applicatins audi qui fnctinnent sus le présent prfil DEVRAIENT, au minimum, être capables d'envyer et/u recevir les types de charge utile 0 (MICU) et 5 (DVI4). Cela permet l'interpérabilité sans négciatin de frmat et assure une négciatin réussie avec un prtcle de cntrôle de cnférence. 7. RTP sur TCP et prtcles similaires de flux d'ctets Dans des circnstances particulières, il peut être nécessaire de prter RTP dans des prtcles qui ffrent des flux d'ctets abstraits, cmme TCP, éventuellement multiplexés avec d'autres dnnée. L'applicatin DOIT définir sa prpre méthde de délimitatin des paquets RTP et RTCP (RTSP [23] furnit un exemple d'une spécificatin d'encapsulatin). 8. Allcatin d'accès Cmme spécifié dans la définitin du prtcle RTP, les dnnées RTP DEVRAIENT être prtées sur un numér d'accès UDP pair et les paquets RTCP crrespndants DEVRAIENT être prtés sur le numér d'accès supérieur (impair) suivant. Les applicatins qui fnctinnent sus le présent prfil PEUVENT utiliser une telle paire d'accès UDP. Par exemple, la paire d'accès PEUT être alluée de façn aléatire par un prgramme de gestin de sessin. Une seule paire fixe de numérs d'accès ne peut pas être exigée parce que plusieurs applicatins utilisant ce prfil vnt vraisemblablement fnctinner sur le même hôte, et il y a des systèmes d'explitatin qui ne permettent pas que plusieurs prcessus utilisent le même accès UDP avec des adresses de diffusin grupée différentes. Cependant, les numérs d'accès 5004 et 5005 nt été enregistrés pur être utilisés avec ce prfil pur les applicatins qui chisissent de les utiliser cmme paire par défaut. Les applicatins qui fnctinnent sus plusieurs prfils PEUVENT utiliser cette paire d'accès cmme indicatin pur chisir ce prfil si elle ne snt pas sumises à la cntrainte du paragraphe précédent. Les applicatins n'nt pas besin d'avir une paire par défaut et PEUT exiger que la paire d'accès sit explicitement spécifiée. Les numérs d'accès particuliers nt été chisis dans la gamme au dessus de 5000 pur s'accmmder de la pratique de l'allcatin des numérs d'accès dans certaines versins du système d'explitatin Unix ù le numérs d'accès en dessus de 1024 ne peuvent être utilisés que par des prcessus privilégiés et les numérs d'accès entre 1024 et 5000 snt autmatiquement allués par le système d'explitatin. 9. Changements depuis la RFC 1890 La présente RFC révise la RFC 1890. Elle est essentiellement rétr cmpatible avec la RFC 1890 sauf pur les fnctins retirées parce que n n'a pas truvé deux mises en œuvre interpérables. Les ajuts à la RFC 1890 cdifient les pratiques existantes dans l'utilisatin des frmats de charge utile sus ce prfil. Cmme ce prfil peut être utilisé sans aucun des frmats de charge utile énumérés ici, l'ajut de nuveaux frmats de charge utile dans cette révisin n'affecte pas la rétr cmpatibilité. Les mdificatins snt récapitulées ci-dessus, réparties en changements fnctinnels et nn fnctinnels.

RFC 3551 page - 21 - Schulzrinne & Casner Changements fnctinnels : La Sectin 11, "Cnsidératins relatives à l'iana" a été ajutée pur spécifier l'enregistrement du nm de ce prfil. Elle fait aussi référence à une nuvelle Sectin 3 "Enregistrement de cdages supplémentaires" qui établit pur plitique qu'aucun enregistrement supplémentaires de types de charge utile statique ne sera fait pur ce prfil au delà de ceux ajutés par cette révisin et inclus dans les Tableaux 4 et 5. Des nms de cdages supplémentaires peuvent à la place être enregistrés cmme sus-types MIME pur se lier à des types de charge utile dynamiques. Des références nn nrmatives nt été ajutées à la RFC 3555 [7] ù les sus-types MIME pur tus les frmats de charge utile énumérés snt enregistrés, certains avec des paramètres facultatifs pur l'utilisatin des frmats de charge utile. Les types de charge utile 4, 16, 17 et 34 nt été ajutés pur incrprer les enregistrements de l'iana faits depuis la publicatin de la RFC 1890, ainsi que les descriptins de frmats de charge utile crrespndants pur G723 et H263. Suite à la discussin du grupe de travail, les types de charge utile statiques 12 et 18 nt été ajutés ainsi que les descriptins de frmat de charge utile crrespndantes pur QCELP et G729. Le type de charge utile statique 13 a été allué au frmat de charge utile Bruit de cnfrt (CN, Cmfrt Nise) défini dans la RFC 3389. Le type de charge utile 19 a été marqué réservé parce qu'il a été temprairement allué à une précédente versin de bruit de cnfrt présente dans des versins antérieures de ce dcument. Le frmat de charge utile pur G721 a été renmmé G726-32 suivant le changement de numértatin par l'uit-t, et la descriptin du frmat de charge utile pur G726 a été étendue pur inclure les débits de dnnées -16, -24 et -40. En raisn d'une cnfusin cncernant les versins préparatires de ce dcument, certaines mises en œuvre de ce frmat de charge utile G726 empaquetaient les échantillns en ctets en cmmençant par le bit de pids frt au lieu du bit de mindre pids spécifié ici. Pur résudre partiellement cette incmpatibilité, de nuveaux frmats de charge utile nmmés AAL2-G726-16, -24, -32 et -40 sernt spécifiés dans un dcument distinct (vir la nte du paragraphe 4.5.4) et l'utilisatin du type de charge utile statique 2 est décnseillé cmme expliqué à la Sectin 6. Les frmats de charge utile G729D et G729E nt été ajutés suite à l'ajut par l'uit-t des Annexes D et E à la Recmmandatin G.729. Des listes nt été ajutées pur les frmats de charge utile GSM-EFR, RED, et H263-1998 publiés dans d'autres dcuments pstérieurs à la RFC 1890. Ces frmats de charge utile additinnels ne snt référencés que par des numérs de type de charge utile dynamique. Les descriptins des frmats de charge utile pur G722, G728, GSM, VDVI nt été dévelppées. Le frmat de charge utile pur l'audi 1016 a été retiré et sn allcatin de type de charge utile statique 1 a été marqué "réservé" parce que deux mises en œuvre interpérables n'nt pas été truvées. Les exigences pur le cntrôle de l'encmbrement nt été ajutées à la Sectin 2. Le présent prfil suit la suggestin de la spécificatin RTP révisée de spécifier séparément la bande passante RTCP et la bande passante de sessin ainsi que pur les envyeurs actifs et les receveurs passifs. La transpsitin de la chaîne de phrase de passe d'usager en clé de chiffrement a été supprimée de la Sectin 2 parce que deux mises en œuvre interpérables n'nt pas été truvées. La cnventin de rangement des échantillns de "quadriphnie" pur l'audi sur quatre canaux a été retirée pur éliminer une ambiguïté ntée au paragraphe 4.1. Changements nn fnctinnels : Au paragraphe 4.1, il est maintenant déclaré explicitement que la suppressin de silence est permise pur tus les frmats de charge utile audi. (Cela avait tujurs été le cas et décule d'un aspect fndamental de la cnceptin de RTP et des mtivatins du paquet audi, mais n'était pas déclaré explicitement auparavant.) L'utilisatin du bruit de cnfrt est aussi expliqué. Au paragraphe 4.1, le niveau d'exigence pur régler le bit marqueur sur le premier paquet après le silence en audi a été changé de "est" en "DEVRAIT être", et précisé que le bit marqueur n'est établi que lrsque les paquets snt intentinnellement nn envyés. De même, du texte a été ajuté pur spécifier que le bit marqueur DEVRAIT être établi à un sur le dernier paquet d'une trame vidé, et que les trames vidé snt distinguées par leurs hrdatages. Les RFC de référence nt été ajutées pur les frmats de charge utile publiés après la RFC 1890.

RFC 3551 page - 22 - Schulzrinne & Casner Les sectins de cnsidératins pur la sécurité et de drits de reprductin nt été ajutées. Cnfrmément à ce que dit Peter Hddie de Apple, seuls les Macintsh d'avant 1994 utilisaient le débit de 22254,54 et pas le 11127,27 rate, de srte que ce dernier a été abandnné de la discussin sur les fréquences d'échantillnnage suggérées. Le Tableau 1 a été crrigé pur déplacer certaines valeurs de la clnne "ms/paquet" à la clnne "ms/paquet par défaut" à laquelle elles appartiennent. Cmme la "Interactive Multimedia Assciatin" a cessé de fnctinner, un ressurce de remplacement a été furnie pur référencer les dcuments IMA. Une nte a été ajutée sur G722 pur préciser une discrdance entre le taux réel d'échantillnnage et le débit d'hrlge de l'hrdatage RTP. De petites précisins textuelles nt été faites à divers endrits, certaines en répnse à des questins de lecteurs. En particulier : - Une définitin de "type de supprt" est dnnée en 1.1 pur expliquer plus clairement le multiplexage de sessins RTP à la Sectin 6 par rapprt au multiplexage de plusieurs supprts. - L'explicatin de la façn de déterminer dans un paquet le nmbre de trames audi à partir de la lngueur a été dévelppée. - La descriptin de l'allcatin de bande passante aux éléments de SDES est dnnée. - Une nte a été ajutée à la cnventin spécifiée au paragraphe 4.1 sur l'rdre des canaux qui peut être utrepassé par la spécificatin d'un cdage u frmat de charge utile particulier. - Les termes DOIT, DEVRAIT, PEUT, etc. snt utilisés cmme défini dans la RFC 2119. Un secnd auteur du dcument a été ajuté. 10. Cnsidératins pur la sécurité Les mises en œuvre qui utilisent le prfil défini dans cette spécificatin snt sujettes aux cnsidératins sur la sécurité expsées dans la spécificatin RTP [1]. Le présent prfil ne spécifie aucun service de sécurité différent. La principale fnctin de ce prfil est de faire la liste d'un ensemble de cdages de cmpressin de dnnées pur les supprts audi et vidé. La cnfidentialité des flux de supprts est réalisée par le chiffrement. Cmme la cmpressin des dnnées utilisée avec les frmats de charge utile décrits dans ce prfil est appliquée de but en but, le chiffrement peut être effectué après la cmpressin de srte qu'il n'y a pas de cnflit entre les deux pératins. Une menace ptentielle de déni de service existe pur les cdages de dnnées qui utilisent les techniques de cmpressin qui nt une charge de calcul nn unifrme à l'extrémité de réceptin. L'attaquant peut injecter dans le flux des datagrammes pathgènes cmplexes à décder qui causent la surcharge du receveur. Cmme avec tut prtcle fndé sur IP, dans certaines circnstances un receveur peut être surchargé simplement par la réceptin de paquets trp nmbreux, désirés u indésirables. L'authentificatin de cuche réseau PEUT être utilisée pur éliminer des paquets prvenant de surces nn désirées, mais le cût de traitement de l'authentificatin elle-même peut être trp élevé. Dans un envirnnement de diffusin grupée, l'élagage de surce est mis en œuvre dans IGMPv3 (RFC 3376) [24] et dans les prtcles d'acheminement de diffusin grupée pur permettre à un receveur de chisir quelles surces snt autrisées à le jindre. 11. Cnsidératins relatives à l'iana La spécificatin RTP établit un registre des nms de prfils à utiliser par les prtcles de cntrôle de niveau supérieur, tels que le prtcle de descriptin de sessin (SDP), RFC 2327 [6], pur se référer aux méthdes de transprt. Ce prfil enregistre le nm "RTP/AVP". La Sectin 3 établit la plitique seln laquelle aucun enregistrement supplémentaire de type de charge utile RTP statique ne sera fait pur ce prfil en plus de ceux ajutés dans la révisin de ce dcument et inclus dans les tableaux 4 et 5. L'IANA peut faire référence à cette sectin pur refuser d'accepter tute demande d'enregistrement supplémentaire. Dans les

RFC 3551 page - 23 - Schulzrinne & Casner tableaux 4 et 5, nter que les types 1 et 2 nt été marqués cmme réservés et que l'ensemble de types de charge utile "dyn" inclus a été mis à jur. Ces changements snt expliqués aux Sectins 6 et 9. 12. Références (Les liens hypertextes dans le titre snt sur la traductin française éventuelle.) 12.1 Références nrmatives [1] H. Schulzrinne, S. Casner, R. Frederick et V. Jacbsn, "RTP : un prtcle de transprt pur les applicatins en temps réel", STD 64, RFC 3550, juillet 2003. [2] S. Bradner, "Mts clés à utiliser dans les RFC pur indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997. [3] Apple Cmputer, "Audi Interchange File Frmat AIFF-C", aût 1991. (aussi à ftp://ftp.sgi.cm/sgi/aiffc.9.26.91.ps.z). 12.2 Références pur infrmatin [4] R. Braden, D. Clark et S. Shenker, "Intégratin de services dans l'architecture de l'internet : Généralités", RFC 1633, juin 1994. (Infrmatin) [5] S. Blake, D. Black, M. Carlsn, E. Davies, Z. Wang et W. Weiss, "Architecture pur services différenciés", RFC 2475, décembre 1998. (Infrmatin, mise à jur par RFC 3260) [6] M. Handley et V. Jacbsn, "SDP : Prtcle de descriptin de sessin", RFC 2327, avril 1998. (Rendue bslète par la RFC 4566) [7] S. Casner et P. Hschka, "Enregistrement de type MIME pur les types de charge utile RTP", RFC 3555, juillet 2003. (Rendue bslète par les RFC 4855/4856) [8] N. Freed, J. Klensin et J. Pstel, "Extensins multi-bjets de la messagerie Internet (MIME) Partie 4 : Prcédures d'enregistrement", BCP 13, RFC 2048, nvembre 1996. (Rendue bslète par RFC 4288/4289) [9] R. Zpf, "Charge utile du prtcle de transprt en temps réel (RTP) pur le bruit de cnfrt", RFC 3389, septembre 2002. (Prpsitin de nrme) [10] Deleam, D. and J.-P. Petit, "Real-time implementatins f the recent ITU-T lw bit rate speech cders n the TI TMS320C54X DSP: results, methdlgy, and applicatins", dans Prc. f Internatinal Cnference n Signal Prcessing, Technlgy, and Applicatins (ICSPAT), (Bstn, Massachusetts), pp. 1656--1660, ctbre 1996. [11] M. Muly et M.-B. Pautet, "Le système GSM pur les cmmunicatins entre les mbiles", Lassay-les-Chateaux, France, Eurpe Media Duplicatin, 1993. [12] Degener, J., "Digital Speech Cmpressin", Dr. Dbb's Jurnal, décembre 1994. [13] Redl, S., Weber, M. and M. Oliphant, "An Intrductin t GSM", Bstn: Artech Huse, 1995. [14] D. Hffman, G. Fernand, V. Gyal et M. Civanlar, "Frmat de charge utile RTP pur la vidé MPEG1/MPEG2", RFC 2250, janvier 1998. (Prpsitin de nrme) [15] Jayant, N. and P. Nll, "Digital Cding f Wavefrms--Principles and Applicatins t Speech and Vide", Englewd Cliffs, New Jersey: Prentice-Hall, 1984. [16] K. McKay, "Frmat de charge utile RTP pur les flux audi PureVice(tm)", RFC 2658, aût 1999. (Prp. de nrme) [17] C. Perkins, I. Kuvelas, O. Hdsn, V. Hardman, M. Handley, J. Blt, A. Vega-Garcia et S. Fsse-Parisis, "Charge utile RTP pur dnnées audi redndantes", RFC 2198, septembre 1997. (Prpsitin de nrme) [18] M. Speer et D. Hffman, "Frmat de charge utile RTP pur les cdages vidé CellB de Sun", RFC 2029, ctbre 1996. (Prpsitin de nrme)

RFC 3551 page - 24 - Schulzrinne & Casner [19] L. Berc, W. Fenner, R. Frederick, S. McCanne et P. Stewart, "Frmat de charge utile RTP pur la vidé cmpressée en JPEG", RFC 2435, ctbre 1998. (Prpsitin de nrme) [20] T. Turletti et C. Huitema, "Frmat de charge utile RTP pur les flux vidé H.261", RFC 2032, ctbre 1996. (Rendue bslète par la RFC 4587) [21] C. Zhu, "Frmat de charge utile RTP pur les flux vidé H.263", RFC 2190, septembre 1997. (Histrique) [22] C. Brmann, L. Cline, G. Deisher, T. Gards, C. Macicc, D. Newell, J. Ott, G. Sullivan, S. Wenger et C. Zhu, "Frmat de charge utile RTP pur la versin 1998 de la Rec. UIT-T H.263 Vidé (H.263+)", RFC 2429, ctbre 1998. (Rendue bslète par la RFC 4629) [23] H. Schulzrinne, A. Ra et R. Lanphier, "Prtcle de flux directs en temps réel (RTSP)", RFC 2326, avril 1998. (Prpsitin de nrme) [24] B. Cain, S. Deering, I. Kuvelas, B. Fenner et A. Thyagarajan, "Prtcle Internet de gestin de grupe, versin 3", RFC 3376, ctbre 2002. (Mise à jur par la RFC 4004) 13. Lcalisatin actuelle des ressurces cncernées Nte : Plusieurs sectins ci dessus se réfèrent à la Biblithèque d'utils lgiciels de l'uit-t (STL, Sftware Tl Library). Celle-ci est dispnible auprès du Service des ventes de l'uit, Place des Natins, CH-1211 Genève 20, Suisse (vir aussi http://www.itu.int). Le STL de l'uit-t est cuvert par un brevet défini dans la Recmmandatin UIT-T G.191, "Outils lgiciels pur la nrmalisatin des cdages de parle et audi". DVI4 Un cpie d'archive du dcument "IMA Recmmended Practices fr Enhancing Digital Audi Cmpatibility in Multimedia Systems (versin 3.0)", qui décrit l'algrithme ADPCM de l'ima, est dispnible à : http://www.cs.clumbia.edu/~hgs/audi/dvi/ Une mise en œuvre est dispnible auprès de Jack Jansen à ftp://ftp.cwi.nl/lcal/pub/audi/adpcm.shar G722 Une mise en œuvre de l'algrithme de G.722 est dispnible au titre de la STL de l'uit-t, décrite ci-dessus. G723 La mise en œuvre de référence du cde C qui définit l'algrithme de G.723.1 et ses Annexes A, B, et C snt dispnibles dans la Recmmandatin G.723.1 auprès du service des ventes de l'uit, à l'adresse ci-dessus. L'algrithme et le cde C snt tus deux cuverts par un brevet spécifique. Le Secrétariat de l'uit dit être cntacté pur btenir les infrmatins. G726 G726 est spécifié dans la Recmmandatin UIT-T G.726, "Mdulatin par impulsins cdées différentielles adaptatives à 40, 32, 24, et 16 kbit/s (ADPCM)". Une mise en œuvre de l'algrithme de G.726 est dispnible au titre de la STL de l'uit- T, décrite plus haut. G729 La mise en œuvre de référence du cde C qui définit l'algrithme de G.729 et ses Annexes A à I snt dispnibles au titre de la Recmmandatin G.729 auprès du service des ventes de l'uit, cité ci-dessus. L'Annexe I cntient le cde surce C intégré pur tus les mdes de fnctinnement de G.729. L'algrithme G.729 et le cde C asscié snt cuverts par un brevet spécifique. Les infrmatins de cntact pur btenir la licence snt dispnibles auprès du Secrétariat de l'uit. GSM Une mise en œuvre de référence a été rédigée par Carsten Brmann et Jutta Degener (alrs à TU Berlin, Allemagne). EIle est dispnible à http://www.dmn.tzi.rg/sftware/gsm/ Bien que l'algrithme RPE-LTP ne sit pas une nrme de l'uit-t, il y a une mise en œuvre de cde C de l'algrithme RPE- LTP dispnible au titre de la STL de l'uit-t. C'est une adaptatin de la versin de l'univerité Télélcm de Berlin. LPC Une mise en œuvre est dispnible à ftp://parcftp.xerx.cm/pub/net-research/lpc.tar.z

RFC 3551 page - 25 - Schulzrinne & Casner MICU, MICA Une mise en œuvre de ces algrithmes est dispnible au titre de la STL de lut-t, décrite plus haut. 14. Remerciements Les cmmentaires et la relecture attentive de Sima Camps, Richard Cx et des participants au grupe de travail AVT nt drit à ntre pleine gratitude. La descriptin du GSM a été adaptée de l'accrd pur la mise en œuvre de l'interpérabilité des services du Frum IMTC pur la vix sur IP (janvier 1997). Fred Burg et Terry Lyns nt aidé pur la descriptin de G.729. 15. Déclaratin de drits de prpriété intellectuelle L IETF ne prend pas psitin sur la validité et la prtée de tut drit de prpriété intellectuelle u autres drits qui purraient être revendiqués au titre de la mise en œuvre u l utilisatin de la technlgie décrite dans le présent dcument u sur la mesure dans laquelle tute licence sur de tels drits purrait être u n être pas dispnible ; pas plus qu elle ne prétend avir accmpli aucun effrt pur identifier de tels drits. Les infrmatins sur les prcédures de l IETF au sujet des drits dans les dcuments en curs de nrmalisatin et se rapprtant aux nrmes figurent dans le BCP 11. Des cpies des dépôts d IPR faits au secrétariat de l IETF et tutes assurances de dispnibilité de licences, u le résultat de tentatives faites pur btenir une licence u permissin générale d utilisatin de tels drits de prpriété par ceux qui mettent en œuvre u utilisent la présente spécificatin peuvent être btenues sur le répertire en ligne des IPR de l IETF à http://www.ietf.rg/ipr. L IETF invite tute partie intéressée à prter sn attentin sur tus cpyrights, brevet u applicatins de brevets, u autres drits de prpriété qui purraient recuvrir la technlgie qui purrait être nécessaire pur mettre en œuvre la présente nrme. Prière d adresser les infrmatins au directeur exécutif de l IETF. 16. Adresse des auteurs Henning Schulzrinne Stephen L. Casner Department f Cmputer Science Packet Design Clumbia University 3400 Hillview Avenue, Building 3 1214 Amsterdam Avenue Pal Alt, CA 94304 New Yrk, NY 10027 United States United States mél : schulzrinne@cs.clumbia.edu mél : casner@acm.rg 17. Déclaratin cmplète des drits de reprductin Cpyright (C) The Internet Sciety (2003). Tus drits réservés Le présent dcument et ses traductins peuvent être cpiés et furnis aux tiers, et les travaux dérivés qui les cmmentent u les expliquent u aident à leur mise en œuvre peuvent être préparés, cpiés, publiés et distribués, en tut u partie, sans restrictin d aucune srte, purvu que la déclaratin de cpyright ci-dessus et le présent paragraphe sient inclus dans tutes ces cpies et travaux dérivés. Cependant, le présent dcument lui-même ne peut être mdifié d aucune façn, en particulier en retirant la ntice de cpyright u les références à la Internet Sciety u aux autres rganisatins Internet, excepté autant qu il est nécessaire pur les besins du dévelppement des nrmes Internet, auquel cas les prcédures de cpyright définies dans les prcédures des nrmes Internet divent être suivies, u pur les besins de la traductin dans d autres langues que l anglais. Les permissins limitées accrdées ci-dessus snt perpétuelles et ne sernt pas révquées par la Internet Sciety u successeurs u ayant drits. Le présent dcument et les infrmatins y cntenues snt furnies sur une base "EN L ÉTAT" et le cntributeur, l rganisatin qu il u elle représente u qui le/la finance (s il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent tutes garanties, exprimées u implicites, y cmpris mais nn limitées à tute garantie que l utilisatin des infrmatins ci-enclses ne vilent aucun drit u aucune garantie implicite de cmmercialisatin u d aptitude à un bjet particulier. Remerciement Le financement de la fnctin d éditin des RFC est actuellement furni par l Internet Sciety.