1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T H.460.15TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2004) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Supplementary services for multimedia Call signalling transport channel suspension and redirection within
2、H.323 systems ITU-T Recommendation H.460.15 ITU-T H-SERIES RECOMMENDATIONS 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.23
3、0H.239 Communication procedures H.240H.259 Coding of moving video H.260H.279 Related systems aspects H.280H.299 Systems and terminal equipment for audiovisual services H.300H.349 Directory services architecture for audiovisual and multimedia services H.350H.359 Quality of service architecture for au
4、diovisual and multimedia services H.360H.369 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-Series multimedia systems and services H.510H.519 Mobile multime
5、dia 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.550H.559 Mobile multimedia collaboration inter-working procedures
6、 H.560H.569 BROADBAND AND TRIPLE-PLAY MULTIMEDIA SERVICES Broadband multimedia services over VDSL H.610H.619 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. H.460.15 (03/2004) i ITU-T Recommendation H.460.15 Call signalling transport channel suspension and redirect
7、ion within H.323 systems Summary This Recommendation specifies a mechanism that allows H.323 entities participating in a stable call to temporarily suspend and later resume the call signalling channel. Further, using the procedures described in this Recommendation, an intermediate entity (such as a
8、Gatekeeper that routes call signalling messages at the beginning of the call) may remove itself from the call signalling path once the call is stable, and establish the call signalling path directly between the other two entities. Source ITU-T Recommendation H.460.15 was approved on 15 March 2004 by
9、 ITU-T Study Group 16 (2001-2004) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. H.460.15 (03/2004) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU
10、-T) is a permanent organ 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 y
11、ears, establishes the topics 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 ne
12、cessary standards are prepared 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. Compliance with this Recommendation is voluntary. Howe
13、ver, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative e
14、quivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of
15、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 development process. As of the date of approval of this Recommendation, ITU
16、 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 therefore strongly urged to consult the TSB patent database. ITU 2004 All ri
17、ghts 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.15 (03/2004) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Abbreviations and acronyms 1 4 Capability advertisement 2 4.1 RAS messages 2 4.2 Call signal
18、ling messages. 2 5 Feature description 3 5.1 Transport channel suspend and resume 3 5.2 Transport channel redirection. 5 5.3 Operational considerations . 6 6 Generic Data usage. 7 7 Description of ASN.1 Types and Fields. 7 Annex A ASN.1 definitions 7 ITU-T Rec. H.460.15 (03/2004) 1 ITU-T Recommendat
19、ion H.460.15 Call signalling transport channel suspension and redirection within H.323 systems 1 Scope This Recommendation describes the procedures and the signalling protocol for temporarily suspending the call signalling transport channel between two H.323 entities on a call-by-call basis. This su
20、spension is performed between the entities after the call reaches a stable state and only after mutual agreement. The signalling channel is resumed when a signalling message needs to be sent. For purposes of procedures in this Recommendation, a call is considered to be in a stable state as defined i
21、n R.3.5/H.323. The basic suspension and resumption procedure between two entities is further extended to an intermediate entity, such as a Gatekeeper routing call signalling, that can use it to get out of the signalling path and let the signalling flow directly between two endpoints. These procedure
22、s use the H.323 Generic Extensible Framework (GEF). 2 References The following 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 Recomme
23、ndations and other references are subject to revision; users of this Recommendation 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 p
24、ublished. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T Recommendation H.225.0 (2003), Call signalling protocols and media stream packetization for packet-based multimedia communication systems. ITU-T Recomme
25、ndation H.323 (2003), Packet-based multimedia communications systems. ITU-T Recommendation H.460.1 (2002), Guidelines for the Use of the Generic Extensible Framework (GEF). ITU-T Recommendation H.460.6 (2002), Extended Fast Connect feature. ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, In
26、formation technology Abstract Syntax Notation One (ASN.1): Specification of basic notation. ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002, Information technology ASN.1 encoding rules Specification of Packed Encoding Rules (PER). 3 Abbreviations and acronyms This Recommendation uses the fol
27、lowing abbreviations: ACF Admission Confirm ARQ Admission Request ASN.1 Abstract Syntax Notation No. 1 CRV Call Reference Value GEF Generic Extensible Framework 2 ITU-T Rec. H.460.15 (03/2004) LCF Location Confirm LRQ Location Request PER Packed Encoding Rules RAS Registration, Admission and Status
28、RCF Registration Confirm RRQ Registration Request 4 Capability advertisement 4.1 RAS messages Endpoints capable of suspending active call signalling channels may advertise that capability in the featureSet.supportedFeatures field of the RRQ messages sent to the Gatekeeper. The capability shall not b
29、e advertised in lightweight RRQ messages. If the Gatekeeper routes call signalling messages, and supports this capability, then it shall indicate as such in the featureSet.supportedFeatures field of the RCF message. When initiating a call, an endpoint signals its desire or need for peering with anot
30、her endpoint that supports this capability by indicating as such in the featureSet.desiredFeatures or featureSet.neededFeature as appropriate in the ARQ message to its Gatekeeper. If the originating endpoints Gatekeeper is a direct mode Gatekeeper and needs to send one or more LRQs in order to resol
31、ve the address, it shall propagate this desired or needed information in the featureSet field of the LRQ message(s) that it sends to other Gatekeepers. A direct mode remote Gatekeeper shall select the appropriate endpoint(s) based on endpoints capabilities. If the originating endpoints Gatekeeper ro
32、utes call signalling and needs to send one or more LRQs in order to resolve the address, it shall signal its own desire, or need, for peering with another entity that support this capability in the featureSet field of the LRQ message(s). A remote Gatekeeper that routes call signalling shall indicate
33、 its own capabilities in the LCF message and shall select, based on local policy, the appropriate terminating endpoint. An Annex G/H.225.0 Peer Element signals requirement for this capability in the common.featureSet.desiredFeatures or common.featureSet.neededFeatures fields. Once the local Gatekeep
34、er identifies the signalling peer for the call (itself, a remote Gatekeeper or an endpoint), it shall indicate support of this feature in the featureSet.supportedFeatures of the ACF message it returns. 4.2 Call signalling messages The originating entity shall indicate its support in supportedFeature
35、s of the H.225.0 Setup message. Its signalling neighbour shall indicate its support in supportedFeatures of the Connect message. The capability is indicated with the feature identifier shown in Table 1. ITU-T Rec. H.460.15 (03/2004) 3 Table 1/H.460.15 Indication of the ability to suspend and redirec
36、t signalling transport channel Feature name: Call signalling transport channel suspension and redirection Feature description: This feature allows an H.323 entity to temporarily suspend and subsequently resume an active transport channel opened for call signalling. Feature identifier type: Standard
37、Feature identifier value: 15 The following table identifies the parameter contained in the generic data structure. Table 2/H.460.15 Signalling channel suspend and redirect parameter Parameter name: Signalling channel suspend and redirect Parameter description: This is the data sent in H.225.0 RAS an
38、d Call Signalling messages to manage suspension, resumption, and redirection of call signalling channel. Parameter identifier type: Standard Parameter identifier value: 1 Parameter type: Raw Parameter cardinality: Once and only once The ASN.1 structure of this parameter is described in clause 7. 5 F
39、eature description 5.1 Transport channel suspend and resume Once both the signalling entities recognize the support by the other, either one may invoke the feature by sending a StatusInquiry message and including the genericData field in its h323-uu-pdu containing ChannelSuspendRequest information a
40、s described in this Recommendation. The channelResumeAddress shall be set to the address(es) to which the connection should be re-established, with multiple addresses listed as an ordered set of alternatives. The ChannelSuspendRequest message contains an immediateResume flag which, when set to TRUE,
41、 indicates that the recipient shall immediately re-establish a new connection upon closure of the current connection. The signalling neighbour should reply with a Status message with the ChannelSuspendResponse in the genericData field. If it is agreeable to the suspension of the connection, it shoul
42、d indicate that by setting the okToSuspend field to TRUE. The entity that wishes to suspend the connection will then confirm with a ChannelSuspendConfirm message and proceed to gracefully shutdown the transport connection, taking care to flush any remaining messages in the sent buffer on both sides
43、of the connection. An entity shall not transmit further messages on that transport connection once it has indicated that it is acceptable to suspend the transport connection, unless the suspension is cancelled by the requesting entity by transmitting a ChannelSuspendCancel message. 4 ITU-T Rec. H.46
44、0.15 (03/2004) When either entity wishes to send a call-related message to its signalling neighbour, the connection needs to be re-established. To re-establish the signalling channel, the entity opens a transport connection to the transport address sent by the signalling neighbour. If there is more
45、than one transport address, the addresses will be tried in the order sent. After opening the connection the entity shall send a StatusInquiry message with ChannelResumeRequest. This message contains a random number. In case both the entities open a connection and send the ChannelResumeRequest at the
46、 same time, the entity that has the numerically lower random number shall close its connection. In case the random numbers are the same, both entities shall transmit a new StatusInquiry message over the transport connection with a different random number. Creating a new connection may not be necessa
47、ry if a signalling channel between the entities already exists and may be reused. The entity that receives an acceptable ChannelResumeRequest shall reply with a ChannelResumeResponse in a Status message before commencing regular call signalling messages on the channel. A ChannelSuspendRequest or a C
48、hannelResumeRequest embedded within a StatusInquiry that is replied with a Status message without the appropriate response (ChannelSuspendResponse or ChannelResumeResponse) shall be treated as a protocol error and handled as per 8.6/H.323. It is possible that an entity may not have sufficient resour
49、ces to initiate or accept a new transport connection especially if the motivation behind suspending connection is to optimize resource usage. To prevent this condition, it is recommended that each entity set aside a percentage of its resources for the resumption of suspended connections. In case of failure to establish the transport connection for resumption, the initiator shall cycle through the list of channelResumeAddress for a number of times determined by the implementation. Complete failure to resume a suspended signalling channel should
