ITU-T H 460 8-2002 Querying for Alternate Routes within H 323 Systems Series H Audiovisual and Multimedia Systems Supplementary Services for Multimedia (Study Group 16)《H 323系统迂回路由.pdf

1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T H.460.8TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2002) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSSupplementary services for multimedia Querying for alternate routes within H.323 systems ITU-T Recommendation H.460.8 ITU-T H-SERIES RECOMMENDATIO

2、NS AUDIOVISUAL AND MULTIMEDIA SYSTEMS CHARACTERISTICS OF VISUAL TELEPHONE SYSTEMS H.100H.199 INFRASTRUCTURE OF AUDIOVISUAL SERVICES General H.200H.219 Transmission multiplexing and synchronization H.220H.229 Systems aspects H.230H.239 Communication procedures H.240H.259 Coding of moving video H.260H

3、.279 Related systems aspects H.280H.299 SYSTEMS AND TERMINAL EQUIPMENT FOR AUDIOVISUAL SERVICES H.300H.399 SUPPLEMENTARY SERVICES FOR MULTIMEDIA H.450H.499 MOBILITY AND COLLABORATION PROCEDURES Overview of Mobility and Collaboration, definitions, protocols and procedures H.500H.509 Mobility for H-Se

4、ries multimedia systems and services H.510H.519 Mobile multimedia collaboration applications and services H.520H.529 Security for mobile multimedia systems and services H.530H.539 Security for mobile multimedia collaboration applications and services H.540H.549 Mobility interworking procedures H.550

5、H.559 Mobile multimedia collaboration inter-working procedures H.560H.569 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. H.460.8 (11/2002) i ITU-T Recommendation H.460.8 Querying for alternate routes within H.323 systems Summary This Recommendation specifies a mec

6、hanism that allows endpoints to query a Gatekeeper or Border Element for routes and alternate routes multiple times for a single call. While querying the Gatekeeper or Border Element multiple times may increase the time required to establish the call, it is expected that most calls will establish wi

7、th a single query. However, this expectation does not always prove to be the case. This Recommendation is focused on the cases where the call cannot complete to the first provided route to a destination. In such cases, the endpoint may query for alternate routes. The alternate routes may also includ

8、e different source or destination alias information, different security tokens, or other information that may have been expensive or too time consuming to produce and/or provide in the initial query. Source ITU-T Recommendation H.460.8 was prepared by ITU-T Study Group 16 (2001-2004) and approved un

9、der the WTSA Resolution 1 procedure on 29 November 2002. ii ITU-T Rec. H.460.8 (11/2002) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ

10、 of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the to

11、pics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are pr

12、epared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the p

13、ractice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation dev

14、elopment process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are ther

15、efore strongly urged to consult the TSB patent database. ITU 2003 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. H.460.8 (11/2002) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Abbreviations 1 4 Cap

16、ability advertisement 2 5 Indication of alternate routes 3 6 Querying for alternate routes 3 ITU-T Rec. H.460.8 (11/2002) 1 ITU-T Recommendation H.460.8 Querying for alternate routes within H.323 systems 1 Scope Due to the dynamic nature of most packet-based networks and resources on those networks,

17、 it is entirely possible that resources that are available at the time that an endpoint queries a Gatekeeper, or that a Border Element is consulted in order to determine a route to a particular destination that the destination (or route to reach said destination), is no longer acceptable or reachabl

18、e. It is also possible that, due to conditions on the network that are outside the view of the Gatekeeper or Border Element, a particular destination is not reachable, or is out of service, at the time that the route was initially provided to the calling endpoint. To address this issue, this Recomme

19、ndation provides a means for an entity to query a Gatekeeper or Border Element multiple times in order to get alternate routes to destinations. This Recommendation does not replace the “alternate endpoint“ facilities within H.323, or the ability to provide multiple routes as part of the route inform

20、ation provided by the Border Element, but is intended to supplement those facilities. There are a number of reasons why an entity may wish to take advantage of the ability to perform multiple queries when attempting to establish communication between the calling and called entities. As examples, dif

21、ferent destinations may require different source or destination information to appear in the Setup message. In addition, it is possible that unique security information may be required for each destination and generating that security information for each alternate destination upon the initial query

22、 may be considered too expensive, especially if calls are expected to usually succeed upon the first query. The mechanisms described in this Recommendation are suitable for Gatekeeper or Border Element communication as defined in ITU-T Recs H.323 and H.225.0, respectively. 2 References The following

23、 ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommend

24、ation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give

25、 it, as a stand-alone document, the status of a Recommendation. 1 ITU-T Recommendation H.323 (2000), Packet-based multimedia communications systems. 2 ITU-T Recommendation H.225.0 (2000), Call signalling protocols and media stream packetization for packet-based multimedia communication systems. 3 Ab

26、breviations This Recommendation uses the following abbreviations: ACF Admission Confirm ARQ Admission Request CRV Call Reference Value DRQ Disengage Request 2 ITU-T Rec. H.460.8 (11/2002) LCF Location Confirm LRQ Location Request RCF Registration Confirm RRQ Registration Request 4 Capability adverti

27、sement Endpoints capable of querying the Gatekeeper for alternate routes shall advertise that capability in all RRQ messages sent to the Gatekeeper, except lightweight RRQ messages. The capability shall not be advertised in lightweight RRQ messages. A Gatekeeper may signal support for this capabilit

28、y within the LRQ message when sending LRQs to remote Gatekeepers. A Gatekeeper using the direct call model for a particular call should only advertise this capability to its peer Gatekeeper if the endpoint originating that call had indicated support for querying for alternate routes and provided the

29、 Call Identifier in the ARQ message. If a Gatekeeper is simply forwarding an LRQ received from another Gatekeeper, it may also include the advertisement of this feature if present in the received LRQ. Advertising this capability in the LRQ when the endpoint does not have a means of querying for alte

30、rnate routes may result in a smaller route set being returned by the remote Gatekeeper, whereas perhaps alternate endpoint information would have otherwise been provided. A Border Element may signal support for this capability in each AccessRequest message sent to another Border Element. A Border El

31、ement should only advertise this capability if it knows, by some means, that the endpoint that originated the call indicated support for this feature. Support for this capability by the endpoint may be assumed, for example, if the Border Element also has Gatekeeper functionality and/or receives an L

32、RQ that contains this capability. Advertising this capability in the AccessRequest message, when the source endpoint does not have a means of querying for alternate routes, may result in smaller routing information being returned by the remote Border Element, whereas more complete route information

33、would have been returned had the capability not been advertised. An endpoint signals support by advertising the capability in the featureSet.supportedFeatures field of the RRQ message. A Border Element signals support for this capability by advertising this capability in the common.featureSet.suppor

34、tedFeatures field. A Gatekeeper signals support for this capability to another Gatekeeper by advertising the capability in the featureSet.supportedFeatures field of the LRQ message. The capability is indicated with the feature identifier shown in Table 1 as a supportedFeatures element and without pa

35、rameters. Table 1/H.460.8 Indication of the ability to Query for Alternate Routes Feature name: Querying for Alternate Routes Feature Description: This feature allows an H.323 entity to query a Gatekeeper or Border Element for alternate routes in the event that the previously provided route is not u

36、sable. Feature identifier type: Standard Feature identifier value: 8 ITU-T Rec. H.460.8 (11/2002) 3 5 Indication of alternate routes A Gatekeeper or Border Element that wishes to signal the availability of alternate routes for a call to another Gatekeeper, Border Element, or endpoint, as appropriate

37、, and having learned that the peer entity supports the capability of querying for alternate routes, may do so by signalling the capability shown in Table 1 in the ACF, LCF, or AccessConfirmation message. The capability shall be signalled in the genericData field of the aforementioned messages, not i

38、n the featureSet field. If this capability value is not contained within the genericData structure, it indicates that either there are no additional alternate routes, or that the entity does not support the ability to query for alternate routes. In either case, the requesting entity shall not submit

39、 new queries for the same call if the route returned cannot be reached for any reason. 6 Querying for alternate routes An entity, having learned that its peer may provide an alternate set of routes, and having need to submit a new query, shall send a new request message to its peer. This new request

40、 message shall not have the same request sequence number as the previous query. The request shall contain a genericData element advertising the capability shown in Table 1 and shall include a parameters value, as shown in Table 2. Table 2/H.460.8 Parameter to indicate Query Count Parameter name: Que

41、ry Count Parameter description: This value indicates the number of queries performed thus far Parameter identifier type: Standard Parameter identifier value: 1 Parameter type: number8 Parameter cardinality: Once and only once When an entity queries a peer for a route for a call the first time, this

42、parameter shall not be present, but an internal value of 0 shall be maintained for the request. In addition, the Call Identifier for the call shall be present. In case the Call Identifier is not available to the Gatekeeper or Border Element, the said entity shall not attempt to utilize the functiona

43、lity defined within this Recommendation, as the Call Identifier is the key used for associating subsequent queries. When an entity issues a subsequent query for a call, the value of the query count shall be incremented by one and shall be present. Thus, the second time a request is made for a call,

44、this parameter shall be included with a value of 1. This value may be used by the recipient as an index value into a table of alternate routes. The requesting entity shall also include the same Call Identifier and, in the case of an ARQ, the same CRV as used in the initial request. An endpoint that

45、queries for alternate routes for a call shall not send a DRQ message prior to transmitting subsequent ARQ message(s). A DRQ shall only be transmitted once the call has been completed or once all attempts to establish the call have failed. Additionally, the subsequent ARQ message(s) shall contain, wh

46、enever the information is available, a CallTerminationCause structure containing the reason for the Release Complete message of the previously failed call attempt. That information may be utilized by the entity providing the routes and should be propagated between Gatekeepers and Border Elements whe

47、re possible. The Call Termination Cause shall be carried as an element of parameters as shown in Table 3. 4 ITU-T Rec. H.460.8 (11/2002) Table 3/H.460.8 Parameter to contain the Call Termination Cause Parameter name: Call Termination Cause Parameter description: The CallTerminationCause structure co

48、ntains the reason for the previously failed call attempt Parameter identifier type: Standard Parameter identifier value: 2 Parameter type: raw Parameter cardinality: Zero or one All other parameters present, but not listed in this clause, shall be ignored and shall not be treated as errors. Printed

49、in Switzerland Geneva, 2003 SERIES OF ITU-T RECOMMENDATIONS Series A Organization of the work of ITU-T Series B Means of expression: definitions, symbols, classification Series C General telecommunication statistics Series D General tariff principles Series E Overall network operation, telephone service, service operation and human factors Series F Non-telephone telecommunication services Series G Transmission systems and media, digital systems and networks Series H Audiovisual and multimedia systems Series I Integrated services digital network Series J Cable netwo