ITU-T H 460 8 FRENCH-2002 Querying for alternate routes within H 323 systems《H 323系统内的备用路由查询 系列H 视听和多媒体系统 多媒体的补充业务 16号研究组》.pdf

《ITU-T H 460 8 FRENCH-2002 Querying for alternate routes within H 323 systems《H 323系统内的备用路由查询 系列H 视听和多媒体系统 多媒体的补充业务 16号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T H 460 8 FRENCH-2002 Querying for alternate routes within H 323 systems《H 323系统内的备用路由查询 系列H 视听和多媒体系统 多媒体的补充业务 16号研究组》.pdf（12页珍藏版）》请在麦多课文档分享上搜索。

1、 UNION INTERNATIONALE DES TLCOMMUNICATIONS UIT-T H.460.8SECTEUR DE LA NORMALISATION DES TLCOMMUNICATIONS DE LUIT (11/2002) SRIE H: SYSTMES AUDIOVISUELS ET MULTIMDIAS Services complmentaires en multimdia Demande de routes alternatives dans les systmes H.323 Recommandation UIT-T H.460.8 RECOMMANDATION

2、S 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 transmission H.220H.229 Aspects systme H.230H.239 Procdures de communication H.240H.259 Codage

3、 des images vido animes H.260H.279 Aspects lis aux systmes H.280H.299 SYSTMES ET QUIPEMENTS TERMINAUX POUR LES SERVICES AUDIOVISUELS H.300H.399 SERVICES COMPLMENTAIRES EN MULTIMDIA H.450H.499 PROCDURES DE MOBILIT ET DE COLLABORATION Aperu gnral de la mobilit et de la collaboration, dfinitions, proto

4、coles et procdures H.500H.509 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 mult

5、imdia mobile H.540H.549 Procdures dinterfonctionnement de la mobilit H.550H.559 Procdures dinterfonctionnement de collaboration multimdia mobile H.560H.569 Pour plus de dtails, voir la Liste des Recommandations de lUIT-T. Rec. UIT-T H.460.8 (11/2002) i Recommandation UIT-T H.460.8 Demande de routes

6、alternatives dans les systmes H.323 Rsum La prsente Recommandation dcrit un mcanisme permettant aux points dextrmit de demander, plusieurs reprises, un portier ou un lment frontire dindiquer diffrentes routes, pour un mme appel, ce qui, dans certains cas, peut prolonger le temps ncessaire ltablissem

7、ent dun appel. Toutefois, dans la plupart des cas, une seule demande devrait suffire. La prsente Recommandation traite essentiellement des cas o lappel achemin par la premire route propose vers une destination ne peut aboutir. En pareil cas, le point dextrmit peut demander des routes alternatives. C

8、elles-ci peuvent tre associes diffrentes informations sur la source ou la destination, diffrents jetons de scurit ou dautres informations quil aurait t trop long ou trop onreux de produire et/ou de fournir dans la demande initiale. Source La Recommandation H.460.8 de lUIT-T, labore par la Commission

9、 dtudes 16 (2001-2004) de lUIT-T, a t approuve le 29 novembre 2002 selon la procdure dfinie dans la Rsolution 1 de lAMNT. ii Rec. UIT-T H.460.8 (11/2002) AVANT-PROPOS LUIT (Union internationale des tlcommunications) est une institution spcialise des Nations Unies dans le domaine des tlcommunications

10、. LUIT-T (Secteur 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 n

11、ormalisation des 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 d

12、finie dans la Rsolution 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 ds

13、igner de faon abrge aussi bien une administration de tlcommunications quune exploitation reconnue. 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 intellect

14、uelle. LUIT ne prend pas position en ce qui concerne lexistence, 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 Recomman

15、dation, lUIT navait pas t avise de lexistence dune proprit 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 consul

16、ter la base de donnes des brevets du TSB. UIT 2003 Tous 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.8 (11/2002) iii TABLE DES MATIRES Page 1 Domaine dapplication 1 2 Rfrences normatives

17、1 3 Abrviations 2 4 Indication de capacit . 2 5 Indication de routes alternatives . 3 6 Demande de routes alternatives 3 Rec. UIT-T H.460.8 (11/2002) 1 Recommandation UIT-T H.460.8 Demande de routes alternatives dans les systmes H.323 1 Domaine dapplication Compte tenu de la nature dynamique de la p

18、lupart des rseaux en mode paquet, et des ressources sur ces rseaux, il est tout fait possible que des ressources disponibles au moment o un point dextrmit demande un portier ou un lment frontire de dterminer une route vers une destination donne, ne le soient plus par la suite et quen consquence, la

19、destination (ou la route vers ladite destination) ne soit plus acceptable ni atteignable. Il est aussi possible quen raison de certaines conditions sur le rseau, non connues par le portier ou llment frontire, une destination donne ne puisse pas tre atteinte ou soit hors service au moment o la route

20、est propose initialement au point dextrmit demandeur. Pour rsoudre ce problme, la prsente Recommandation dcrit un moyen permettant une entit de demander plusieurs reprises un portier o un lment frontire dindiquer des routes alternatives vers les destinations voulues. La prsente Recommandation ne rem

21、place pas les fonctions “autre point dextrmit“ dcrites dans la Rec. UIT-T H.323, ni la possibilit de proposer diffrentes routes dans le cadre des informations sur les routes fournies par llment frontire, mais elle vise complter ces fonctions. Lorsquelle tente dtablir une communication entre les enti

22、ts appelantes et appeles, une entit peut souhaiter tirer parti de la possibilit de prsenter plusieurs demandes, pour de multiples raisons. Par exemple, selon les destinations, les informations sur la source ou la destination afficher dans le message dtablissement peuvent tre diffrentes. De plus, il

23、peut tre ncessaire de fournir des informations sur la scurit propres chaque destination et lors de la demande initiale, la fourniture de ces informations pour chacune des autres destinations peut tre considre comme onreuse, surtout si les appels aboutissent, en principe, la premire demande. Les mcan

24、ismes dcrits dans la prsente Recommandation conviennent pour les communications portier ou lment frontire dfinies respectivement dans les Recommandations UIT-T H.323 et H.225.0. 2 Rfrences normatives La prsente Recommandation se rfre certaines dispositions des Recommandations UIT-T et textes suivant

25、s 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 texte tant sujet rvision, les utilisateurs de la prsente Recommandation sont invits se reporter, si possible, aux versions les p

26、lus 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 Recommandation ne donne pas ce document, en tant que tel, le statut dune Recommandation. 1 Recommandation UIT-T H.323 (2000), Systm

27、es de communication multimdia en mode paquet. 2 Recommandation UIT-T H.225.0 (2000), Protocoles de signalisation dappel et paqutisation des flux monomdias dans les systmes de communication multimdias en mode paquet. 2 Rec. UIT-T H.460.8 (11/2002) 3 Abrviations La prsente Recommandation utilise les a

28、brviations suivantes: ACF confirmation dadmission (admission confirm) ARQ demande dadmission (admission request) CRV valeur de rfrence dappel (call reference value) DRQ demande de dsengagement (disengage request) LCF confirmation demplacement (location confirm) LRQ demande demplacement (location req

29、uest) RCF confirmation denregistrement (registration confirm) RRQ demande denregistrement (registration request) 4 Indication de capacit Les points dextrmit pouvant demander au portier des routes alternatives doivent indiquer cette capacit dans tous les messages RRQ envoys au portier, sauf dans les

30、messages RRQ courts, o cette capacit ne sera pas indique. Un portier peut signaler la prise en charge de cette capacit dans le message LRQ quil envoie aux portiers distants. Un portier qui utilise le modle dappel direct pour un appel donn ne devrait indiquer cette capacit son homologue que si le poi

31、nt dextrmit appelant a indiqu la prise en charge de la demande de routes alternatives et a fourni lidentificateur dappel dans le message ARQ. Si un portier retransmet simplement un message LRQ provenant dun autre portier, il peut aussi y inclure lindication de cette fonction, si elle est prsente dan

32、s le message LRQ reu. Si cette capacit est indique dans le message LRQ alors que le point dextrmit ne dispose pas dun moyen lui permettant de demander des routes alternatives, le portier distant peut retourner un ensemble de routes plus limit, alors quil aurait peut-tre t possible de fournir dautres

33、 informations au point dextrmit. Un lment frontire peut signaler la prise en charge de cette capacit dans chaque message AccessRequest quil envoie un autre lment frontire. Un lment frontire ne devrait indiquer cette capacit que sil sait, par un moyen quelconque, que le point dextrmit appelant a indi

34、qu la prise en charge de cette fonction. On peut supposer que cette capacit est prise en charge par le point dextrmit, par exemple, si llment frontire a aussi une fonctionnalit de portier et/ou reoit un message LRQ dans lequel figure cette capacit. Si cette capacit est indique dans le message Access

35、Request alors que le point dextrmit source ne dispose pas dun moyen lui permettant de demander des routes alternatives, llment frontire distant peut retourner moins dinformations sur lacheminement, alors que si la capacit navait pas t indique, des informations plus compltes sur les routes auraient t

36、 retournes. Un point dextrmit signale la prise en charge en indiquant la capacit dans le champ featureSet.supportedFeatures du message RRQ. Un lment frontire signale la prise en charge de cette capacit en indiquant cette capacit dans le champ common.featureSet.supportedFeatures. Un portier signale l

37、a prise en charge de cette capacit un autre portier en indiquant la capacit dans le champ featureSet.supportedFeatures du message LRQ. La capacit est indique avec lidentificateur de fonction prsent dans le Tableau 1 comme un lment supportedFeatures et sans parameters. Rec. UIT-T H.460.8 (11/2002) 3

38、Tableau 1/H.460.8 Indication de la capacit demander des routes alternatives Nom de la fonction: Demande de routes alternatives Description de la fonction: Cette fonction permet une entit H.323 de demander un portier ou un lment frontire dindiquer des routes alternatives au cas o la route prcdemment

39、propose nest pas utilisable. Type didentificateur de la fonction: Standard Valeur de lidentificateur de la fonction: 8 5 Indication de routes alternatives Un portier ou un lment frontire qui souhaite signaler la disponibilit de routes alternatives pour un appel, un autre portier, lment frontire ou p

40、oint dextrmit, selon le cas, et qui sait que lentit homologue prend en charge la capacit demander des routes alternatives, peut le faire en signalant la capacit indique dans le Tableau 1 dans le message ACF, LCF, ou AccessConfirmation. La capacit doit tre signale dans le champ genericData des messag

41、es susmentionns, pas dans le champ featureSet. Si la valeur associe cette capacit ne figure pas dans la structure genericData, cela signifie soit quil ny a pas de routes alternatives, soit que lentit ne prend pas en charge la capacit demander des routes alternatives. Dans les deux cas, lentit demand

42、euse ne doit pas soumettre pas de nouvelles demandes pour le mme appel si la route retourne ne peut tre atteinte pour une raison quelconque. 6 Demande de routes alternatives Une entit qui a appris que son homologue peut fournir un autre ensemble de routes, et qui a besoin de soumettre une nouvelle d

43、emande, doit envoyer un nouveau message de demande son homologue. Ce nouveau message ne doit pas avoir le mme numro de squence de demande que la demande prcdente. La demande doit contenir un lment genericData indiquant la capacit prsente dans le Tableau 1 et une valeur parameters, comme indiqu dans

44、le Tableau 2. Tableau 2/H.460.8 Paramtre indiquant le nombre de demandes Nom du paramtre: Nombre de demandes Description du paramtre: Cette valeur indique le nombre de demandes faites jusqu prsent Type didentificateur de paramtre Standard Valeur de lidentificateur de paramtre: 1 Type de paramtre: nu

45、mber8 Cardinalit du paramtre: Une occurrence uniquement Lorsquune entit demande la premire fois un homologue une route pour un appel, ce paramtre ne doit pas tre prsent, mais une valeur interne de zro doit tre associe la demande. De plus, lidentificateur dappel doit tre prsent. Si le portier ou llme

46、nt frontire ne dispose pas de lidentificateur dappel, ladite entit ne doit pas chercher utiliser la fonctionnalit dfinie dans la prsente Recommandation, car lidentificateur dappel est la cl utilise pour associer les demandes ultrieures. 4 Rec. UIT-T H.460.8 (11/2002) Lorsquune entit soumet une deman

47、de ultrieure pour un appel, la valeur associe au nombre de demandes doit tre incrmente de un et doit tre prsente. Ainsi, la deuxime demande faite pour un appel, ce paramtre sera inclus avec une valeur de 1. Cette valeur peut tre utilise par le destinataire comme indice dans un tableau des routes alternatives. Lentit demandeuse doit aussi inclure le mme identificateur dappel et, dans le cas dun message ARQ, la mme valeur CRV que celle utilise dans la demande initiale. Un point dextrmit qui demande de