1、 Union internationale des tlcommunicationsUIT-T H.460.17SECTEUR DE LA NORMALISATION DES TLCOMMUNICATIONS DE LUIT (09/2005) SRIE H: SYSTMES AUDIOVISUELS ET MULTIMDIAS Infrastructure des services audiovisuels Services complmentaires en multimdia Utilisation de la connexion de signalisation dappel H.22
2、5.0 pour le transport de messages RAS H.323 Recommandation UIT-T H.460.17 RECOMMANDATIONS UIT-T DE LA SRIE H SYSTMES AUDIOVISUELS ET MULTIMDIAS CARACTRISTIQUES DES SYSTMES VISIOPHONIQUES H.100H.199 INFRASTRUCTURE DES SERVICES AUDIOVISUELS Gnralits H.200H.219 Multiplexage et synchronisation en transm
3、ission H.220H.229 Aspects systme H.230H.239 Procdures de communication H.240H.259 Codage des images vido animes H.260H.279 Aspects lis aux systmes H.280H.299 Systmes et quipements terminaux pour les services audiovisuels H.300H.349 Architecture des services dannuaire pour les services audiovisuels e
4、t multimdias H.350H.359 Architecture de la qualit de service pour les services audiovisuels et multimdias H.360H.369 Services complmentaires en multimdia H.450H.499 PROCDURES DE MOBILIT ET DE COLLABORATION Aperu gnral de la mobilit et de la collaboration, dfinitions, protocoles et procdures H.500H.5
5、09 Mobilit pour les systmes et services multimdias de la srie H H.510H.519 Applications et services de collaboration multimdia mobile H.520H.529 Scurit pour les systmes et services multimdias mobiles H.530H.539 Scurit pour les applications et services de collaboration multimdia mobile H.540H.549 Pro
6、cdures dinterfonctionnement de la mobilit H.550H.559 Procdures dinterfonctionnement de collaboration multimdia mobile H.560H.569 SERVICES LARGE BANDE ET MULTIMDIAS TRI-SERVICES Services multimdias large bande sur VDSL H.610H.619 Pour plus de dtails, voir la Liste des Recommandations de lUIT-T. Rec.
7、UIT-T H.460.17 (09/2005) i Recommandation UIT-T H.460.17 Utilisation de la connexion de signalisation dappel H.225.0 pour le transport de messages RAS H.323 Rsum La version actuelle de la Rec. UIT-T H.323 fait intervenir deux mcanismes de transport compltement indpendants, lun pour la signalisation
8、RAS et lautre pour la signalisation dappel H.225.0. Pour diverses raisons, lun deux permet la traverse pare-feu/traducteurs dadresse de rseau (FW/NAT); il serait avantageux de pouvoir utiliser le mme mcanisme de transport pour les deux protocoles de signalisation. La prsente Recommandation dfinit le
9、 mcanisme dencapsulation de messages RAS dans des messages H.225.0 ainsi que la mthode permettant de dcouvrir la capacit dune entit H.323 homologue prendre en charge la fonctionnalit dfinie dans la prsente Recommandation. Source La Recommandation UIT-T H.460.17 a t approuve le 13 septembre 2005 par
10、la Commission dtudes 16 (2005-2008) de lUIT-T selon la procdure dfinie dans la Recommandation UIT-T A.8. ii Rec. UIT-T H.460.17 (09/2005) AVANT-PROPOS LUIT (Union internationale des tlcommunications) est une institution spcialise des Nations Unies dans le domaine des tlcommunications. LUIT-T (Secteu
11、r de la normalisation des tlcommunications) est un organe permanent de lUIT. Il est charg de ltude des questions techniques, dexploitation et de tarification, et met ce sujet des Recommandations en vue de la normalisation des tlcommunications lchelle mondiale. LAssemble mondiale de normalisation des
12、 tlcommunications (AMNT), qui se runit tous les quatre ans, dtermine les thmes dtude traiter par les Commissions dtudes de lUIT-T, lesquelles laborent en retour des Recommandations sur ces thmes. Lapprobation des Recommandations par les Membres de lUIT-T seffectue selon la procdure dfinie dans la Rs
13、olution 1 de lAMNT. Dans certains secteurs des technologies de linformation qui correspondent la sphre de comptence de lUIT-T, les normes ncessaires se prparent en collaboration avec lISO et la CEI. NOTE Dans la prsente Recommandation, lexpression “Administration“ est utilise pour dsigner de faon ab
14、rge aussi bien une administration de tlcommunications quune exploitation reconnue. Le respect de cette Recommandation se fait titre volontaire. Cependant, il se peut que la Recommandation contienne certaines dispositions obligatoires (pour assurer, par exemple, linteroprabilit et lapplicabilit) et c
15、onsidre que la Recommandation est respecte lorsque toutes ces dispositions sont observes. Le futur dobligation et les autres moyens dexpression de lobligation comme le verbe “devoir“ ainsi que leurs formes ngatives servent noncer des prescriptions. Lutilisation de ces formes ne signifie pas quil est
16、 obligatoire de respecter la Recommandation. DROITS DE PROPRIT INTELLECTUELLE LUIT attire lattention sur la possibilit que lapplication ou la mise en uvre de la prsente Recommandation puisse donner lieu lutilisation dun droit de proprit intellectuelle. LUIT ne prend pas position en ce qui concerne l
17、existence, la validit ou lapplicabilit des droits de proprit intellectuelle, quils soient revendiqus par un Membre de lUIT ou par une tierce partie trangre la procdure dlaboration des Recommandations. A la date dapprobation de la prsente Recommandation, lUIT navait pas t avise de lexistence dune pro
18、prit intellectuelle protge par des brevets acqurir pour mettre en uvre la prsente Recommandation. Toutefois, comme il ne sagit peut-tre pas de renseignements les plus rcents, il est vivement recommand aux responsables de la mise en uvre de consulter la base de donnes des brevets du TSB. UIT 2006 Tou
19、s droits rservs. Aucune partie de cette publication ne peut tre reproduite, par quelque procd que ce soit, sans laccord crit pralable de lUIT. Rec. UIT-T H.460.17 (09/2005) iii TABLE DES MATIRES Page 1 Domaine dapplication 1 2 Rfrences normatives 1 3 Termes et dfinitions 2 4 Abrviations 2 5 Descript
20、ion de la fonctionnalit 2 6 Dcouverte de la prise en charge par lentit distante du transport de messages RAS sur connexion H.225.0 . 2 7 Transport de messages RAS sur connexion H.225.0 3 7.1 Utilisation de la signalisation H.225.0 . 3 7.2 Utilisation des donnes gnriques 4 7.3 Dfinition de la fonctio
21、nnalit de transport de messages RAS sur connexion H.225.0 4 7.4 Paramtres de transport de messages RAS sur connexion H.225.0 . 4 8 Considrations lies la scurit 4 Rec. UIT-T H.460.17 (09/2005) 1 Recommandation UIT-T H.460.17 Utilisation de la connexion de signalisation dappel H.225.0 pour le transpor
22、t de messages RAS H.323 1 Domaine dapplication La prsente Recommandation dfinit le mcanisme dencapsulation de messages RAS dans des messages H.225.0 ainsi que la mthode permettant de dcouvrir la capacit dune entit H.323 homologue prendre en charge la fonctionnalit dfinie dans la prsente Recommandati
23、on. 2 Rfrences normatives La prsente Recommandation se rfre certaines dispositions des Recommandations UIT-T et textes suivants qui, de ce fait, en sont partie intgrante. Les versions indiques taient en vigueur au moment de la publication de la prsente Recommandation. Toute Recommandation ou tout te
24、xte tant sujet rvision, les utilisateurs de la prsente Recommandation sont invits se reporter, si possible, aux versions les plus rcentes des rfrences normatives suivantes. La liste des Recommandations de lUIT-T en vigueur est rgulirement publie. La rfrence un document figurant dans la prsente Recom
25、mandation ne donne pas ce document, en tant que tel, le statut dune Recommandation. 1 Recommandation UIT-T H.323 (2003), Systmes de communication multimdia en mode paquet. 2 Recommandation UIT-T H.225.0 (2003), Protocoles de signalisation dappel et paqutisation des flux monomdias pour les systmes de
26、 communication multimdias en mode paquet. 3 Recommandation UIT-T H.460.1 (2002), Directives pour lutilisation du cadre gnrique extensible. 4 Recommandation UIT-T H.235.0 (2005), Cadre de scurit H.323: cadre de scurit pour les systmes multimdias de la srie H (terminaux H.323 et autres terminaux de ty
27、pe H.245). 5 Recommandation UIT-T H.235.1 (2005), Cadre de scurit H.323: profil de scurit de base. 6 Recommandation UIT-T H.235.2 (2005), Cadre de scurit H.323: profil de scurit avec signature. 7 Recommandation UIT-T H.235.3 (2005), Cadre de scurit H.323: profil de scurit hybride. 8 Recommandation U
28、IT-T H.235.4 (2005), Cadre de scurit H.323: scurit des appels routage direct et des appels routage slectif. 9 Recommandation UIT-T H.235.5 (2005), Cadre de scurit H.323: cadre de lauthentification scurise pendant lchange de message RAS au moyen de secrets partags faibles. 10 Recommandation UIT-T H.2
29、35.6 (2005), Cadre de scurit H.323: profil pour le chiffrement vocal avec gestion de cls native dans les systmes H.235/H.245. 11 Recommandation UIT-T H.235.7 (2005), Cadre de scurit H.323: utilisation du protocole de gestion de cls MIKEY avec le protocole de transport en temps rel scuris (SRTP) dans
30、 les systmes H.235. 2 Rec. UIT-T H.460.17 (09/2005) 12 IETF RFC 2246 (1999), The TLS Protocol Version 1.0. 3 Termes et dfinitions La prsente Recommandation dfinit le terme suivant: 3.1 transfert de messages RAS sur connexion H.225.0: mcanisme permettant de transporter des messages RAS sur une connex
31、ion de signalisation dappel H.225.0. 4 Abrviations La prsente Recommandation utilise les abrviations suivantes:. EP point extrmit (endpoint) GK portier (gatekeeper) RAS enregistrement, admission et statut (registration, admission and status) RCF confirmation denregistrement (registration confirm) RR
32、Q demande denregistrement (registration request) SCTP protocole de transmission de commande de flux (stream control transmission protocol) TCP protocole de commande de transport (transport control protocol) TLS scurit de la couche Transport (transport level security) TSAP point daccs au service de t
33、ransport (transport service access point) 5 Description de la fonctionnalit La prsente Recommandation dfinit deux mcanismes: dcouverte de la prise en charge par lentit distante du transport de messages RAS sur connexion H.225.0; transport de messages RAS sur connexion de signalisation dappel H.225.0
34、. 6 Dcouverte de la prise en charge par lentit distante du transport de messages RAS sur connexion H.225.0 Les messages RAS sont transmis entre un point dextrmit et un portier ou entre deux portiers. Dans les deux cas, le premier message RAS transmis entre deux entits H.323 particulires est envoy ve
35、rs le portier. La prise en charge du transport de messages RAS sur connexion H.225.0 par un portier particulier peut tre connue a priori (configure) ou doit tre dcouverte. Les mcanismes de fonctionnalits H.460 ne peuvent pas tre utiliss dans le cas prsent car la dcouverte devrait tre ralise avant le
36、nvoi du premier message entre les entits H.323. Le mcanisme de dcouverte du portier dcrit dans lAnnexe O/H.323 devrait tre utilis pour dcouvrir la prise en charge du transport de messages RAS sur connexion H.225.0. Le service utiliser pour la dcouverte doit tre le service h323rs ou le service h323ls
37、. Pour la dcouverte du type de transport H.225.0, on appliquera les rgles suivantes: Dans le cas dune signalisation H.225.0 selon le protocole TCP, le transport sera de type tcp. Dans le cas dune signalisation H.225.0 selon le protocole de lAnnexe E/H.323, le transport sera de type h323mux. Dans le
38、cas dune signalisation H.225.0 selon le protocole SCTP, le transport sera de type sctp. Rec. UIT-T H.460.17 (09/2005) 3 Si ladresse IP du portier est connue a priori et si le port est inconnu, le port de signalisation dappel H.225.0 bien connu 1720 doit tre utilis pour la procdure de transport de me
39、ssages RAS sur connexion H.225.0. 7 Transport de messages RAS sur connexion H.225.0 7.1 Utilisation de la signalisation H.225.0 Une entit qui prend en charge le transport de messages RAS sur connexion H.225.0 doit galement prendre en charge les connexions de transport H.225.0 persistantes dcrites au
40、 7.3/H.323. Un point dextrmit doit indiquer une telle prise en charge en mettant le fanion maintainConnection du message RRQ la valeur “TRUE“. Si lentit qui envoie le message RAS et lentit qui le reoit prennent en charge le transport de messages RAS sur connexion H.225.0, ces deux entits devraient u
41、tiliser cette connexion H.225.0 pour le transport de messages RAS. Pour maintenir ouverte la connexion de transport, les deux entits devraient utiliser un message RRQ simplifi, tel quil est dcrit au 7.2.2.1/H.323. Dans le cas dune traverse de dispositif NAT, la valeur timeToLive devrait tre infrieur
42、e la dure de la liaison NAT. Ces entits peuvent utiliser le mcanisme de rponse demande dinformation (IRR, information request response) pour prendre en charge la mme fonctionnalit. En revanche, lorsque le protocole de transport utilis est TCP, une entit ayant tabli la connexion TCP peut envoyer prio
43、diquement des paquets dunit de donnes protocolaires de transport (TPKT, transport protocol data unit packet) vides (paquets contenant uniquement les octets 03 00 00 04). Un intervalle de maintien denregistrement compris entre 5 et 30 secondes devrait tre utilis sauf lorsquon sait (par exemple daprs
44、les spcificits du rseau) quun intervalle plus long nentranera pas la fermeture des micro-trous. Pour pouvoir transmettre un message RAS entre deux entits H.323 prenant en charge la fonctionnalit de transport de messages RAS sur connexion H.225.0, une connexion de transport H.225.0 persistante doit t
45、re utilise entre ces deux entits. Si une telle connexion est dj tablie, elle peut tre rutilise ou on peut tablir une nouvelle connexion. Si aucune connexion persistante nest tablie, on doit en tablir une. En gnral, lentit qui envoie le premier message RAS tablit la connexion avec lentit qui le reoit
46、. Le point TSAP de signalisation H.225.0 de lentit recevant le message RAS est utilis en tant que destination de connexion de transport. La mme connexion de transport devrait tre utilise pour la signalisation du RAS sur connexion H.225.0 et pour la signalisation H.225.0 habituelle. Si on le souhaite
47、, plusieurs connexions de transport H.225.0 peuvent tre utilises entre deux entits donnes pour le transfert de messages RAS, auquel cas aucune association nest obligatoire entre les messages RAS et les connexions de transport. Pour indiquer quun mme point TSAP de signalisation de transport H.225.0 de portier doit tre utilis pour toutes les communications RAS et H.225.0, les champs callSignalAddress et rasAddress des messages RRQ et RCF doivent contenir une squence dlments nuls. Le message FACILITY H.225.0 doit tre utilis pour acheminer les messages RAS. Son champ CRV doit avoir pour valeur
