ITU-T H 460 16-2005 Multiple message release sequence capability within H 323 Systems《H 323多种信息发布序列能力》.pdf

1、 International Telecommunication Union ITU-T H.460.16TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (01/2005) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Supplementary services for multimedia Multiple-message release sequence capability within H.323 systems IT

2、U-T Recommendation H.460.16 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.230H.239 Communica

3、tion 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 audiovisual and mu

4、ltimedia 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 multimedia collaboratio

5、n 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.559Mobile multimedia collaboration inter-working procedures H.560H.569 BROAD

6、BAND 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.16 (01/2005) i ITU-T Recommendation H.460.16 Multiple-message release sequence capability within H.323 systems Summary

7、This Recommendation specifies a mechanism that allows H.323 endpoints to negotiate and use a multiple-message release sequence. Source ITU-T Recommendation H.460.16 was approved on 8 January 2005 by ITU-T Study Group 16 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. H.460.16

8、 (01/2005) 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 of ITU. ITU-T is responsible for studying technical, operating and tariff que

9、stions 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 topics for study by the ITU-T study groups which, in turn, produce Recommendatio

10、ns 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 prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation,

11、 the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or a

12、pplicability) 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 equivalents are used to express requirements. The use of such words does not suggest that compliance wi

13、th 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 a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or appl

14、icability 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 had not received notice of intellectual property, protected by patents, which may be required to impl

15、ement 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 2005 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the pri

16、or written permission of ITU. ITU-T Rec. H.460.16 (01/2005) iii CONTENTS 1 Scope 1 2 References. 1 3 Introduction 1 4 Feature description 2 4.1 H.501 signalling . 2 4.2 RAS signalling 2 4.3 Call signalling negotiation. 2 4.4 Call signalling release 4 4.5 Call signalling timers 4 5 Generic data usage

17、 5 5.1 Multiple-message release sequence feature 5 5.2 Multiple-message release sequence parameters . 5 6 Message flows 6 6.1 Three-message sequence 6 6.2 Time-outs 7 6.3 Two-message sequence 7 6.4 Simultaneous initiation of two-message MMRS procedure. 8 6.5 Simultaneous initiation of two- and three

18、-message MMRS procedures 8 6.6 Simultaneous initiation of MMRS and H.225.0 procedures 9 ITU-T Rec. H.460.16 (01/2005) 1 ITU-T Recommendation H.460.16 Multiple-message release sequence capability within H.323 systems 1 Scope This Recommendation specifies a mechanism, using the generic extensibility f

19、ramework defined in ITU-T Rec. H.460.1, which allows endpoints to use a multiple-message release sequence rather than the single release complete message procedure defined in ITU-T Rec. H.225.0. It includes the capability for one endpoint to inform the other that it supports and will use the alterna

20、te multiple-message release sequence. 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 Recommendations and o

21、ther 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 published. The

22、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 Recommendation H.323

23、(2003), Packet-based multimedia communications systems. ITU-T Recommendation Q.931 (1998), ISDN user-network interface layer 3 specification for basic call control. 3 Introduction The call control signalling defined in ITU-T Rec. H.225.0 is based on Q.931 signalling. ITU-T Rec. Q.931 defined a multi

24、ple-message sequence to be used between the user and the network to control release of a connection. This used the disconnect message from the user as a request to release a connection, and then the release and release complete messages to actually release the connection. This allowed additional inf

25、ormation to be passed in both directions during the disconnect process and allowed the initiator of the disconnect to supervise the operation and to retransmit the request in case of failure. ITU-T Rec. H.225.0 does not use the disconnect and release messages and, therefore, depends on a single mess

26、age without acknowledgement by the application. While this suffices for many cases, some applications require the functionality of a multiple-message sequence for release of a connection. Further, an occasional loss of the release complete message could cause significant problems. This Recommendatio

27、n, using the generic extensibility framework, provides the capability with H.225.0 of performing the multiple-message release sequence of a connection in a way that is analogous to Q.931. The H.225.0 facility message is used for the additional messages of the sequence, with the addition of the GEF p

28、arameter defined herein to distinguish its place and function in the sequence. The multiple-message release sequence may be used to provide additional capabilities such as: 1) supervision of acknowledgement of release and repetition in case of failure; 2) inclusion of supplemental information in bot

29、h directions during the release procedure; 2 ITU-T Rec. H.460.16 (01/2005) 3) provision of in-band tones and announcements; 4) full coordination of release of resources; 5) called user release control. 4 Feature description 4.1 H.501 signalling When a Gatekeeper uses the H.501 access request procedu

30、res to request that another gatekeeper perform address resolution, it may indicate the requirement for support of the MMRS feature by inclusion of the MMRS parameters. The responding gatekeeper shall use this information in the selection of a location, which matches the address and complies with any

31、 MMRS support requirement. 4.2 RAS signalling 4.2.1 Registration Support for the MMRS feature shall be indicated by the endpoint in an RRQ when the endpoint initially attempts to register. This shall indicate that MMRS will be supported by the endpoint if requested and it may indicate if support for

32、 MMRS is required for all calls to and from this endpoint. A gatekeeper may reject a registration due to the lack of support for MMRS by inclusion of neededFeatureNotSupported in the rejectReason in the RRJ, for example, if the gatekeeper knows that all calls in the network must use the MMRS procedu

33、res. The desiredFeatures field shall not be used to carry the MMRS parameter in an RRQ. 4.2.2 Location request When an endpoint sends an LRQ to the gatekeeper for address resolution, it may indicate the requirement or desire for MMRS support by inclusion of the MMRS indication in either the neededFe

34、atures or the desiredFeatures field. The gatekeeper shall use this information for the selection of a location, which matches the address and complies with any MMRS support requirement. 4.2.3 Admission request Support for the MMRS feature for an individual call is negotiated between an endpoint and

35、gatekeeper at call set-up time as part of the admission request procedure. For this purpose, an endpoint that supports this feature shall include the feature descriptor defined in 5.1 in supportedFeatures and may include the neededFeatures in the ARQ message in order to indicate whether the endpoint

36、 requires support for MMRS for the calls for which admission is being requested. If support for the feature is not indicated, a gatekeeper may reject an ARQ due to the lack of support for MMRS by the endpoint by inclusion of neededFeatureNotSupported in the rejectReason in the ARJ, for example, if t

37、he network or destination endpoint requires the use of MMRS. The MMRS parameter shall not be including in the desiredFeatures field in RAS admission request signalling, since support either is or is not required. Further, the “MMRS Sse Required“ parameter shall not be used, since support always impl

38、ies that it can be used if required by call signalling. 4.3 Call signalling negotiation The required or optional use of the MMRS procedure shall be negotiated by the two ends exchanging call-signalling messages using the Setup message and the first positive response to that ITU-T Rec. H.460.16 (01/2

39、005) 3 setup. Positive responses are the setup acknowledge, alerting, call proceeding, progress, and connect messages. 4.3.1 Setup If the calling endpoint supports the MMRS feature, but does not require the called endpoint to support it, it shall include the MMRS feature identifier in the supportedF

40、eatures field in the setup to indicate its support for the feature. If the calling endpoint requires that the called party supports the MMRS feature as a condition for setting up the call, it shall include the MMRS feature identifier in the neededFeatures field. The MMRS feature identifier shall not

41、 be including in the desiredFeatures field since support either is or is not required. In addition, the setup may also include the “MMRS Use Required“ parameter to indicate that the feature must be used by the responder if the responder initiates release of this call. In summary, the following combi

42、nations of supported, needed, and use required are possible in the setup message: Case Supported (by sender) (Support) needed (by responder) Use required 1 Yes No No 2 Yes Yes No 3 Yes Yes Yes 4.3.2 Response Depending on the contents of the setup messages, the response shall be as follows: If the se

43、tup indicated that support for MMRS by the responder is not required, the first positive response to setup may contain the supportFeatures field indicating that the responder supports the feature. In addition, the response message may include the “MMRS Use Required“ parameter to indicate that the fe

44、ature must be used by the other endpoint if the other endpoint initiates release of this call. Otherwise, the absence of the MMRS feature indication in the supportedFeatures field indicates that the responder does not support MMRS. The originator and responder shall continue to set up the call as no

45、rmal. If the setup indicated that support for MMRS is needed (required) but that use of the feature is not required for this call, the first positive response to setup may contain the supportFeatures field indicating that the responder supports the feature. In addition, the response message may incl

46、ude the “MMRS Use Required“ parameter to indicate that the responder requires that the feature be used by the other endpoint if the other endpoint initiates release of this call. Otherwise, the absence of the MMRS feature indication in the supportedFeatures field indicates that the responder does no

47、t support MMRS. The responder shall continue to set up the call as normal, however the originator may decide to release the call setup. If the setup indicated that MMRS must be used for this call, the first positive response to setup may contain the MMRS feature indication in the supportedFeatures t

48、o indicate that the responder supports the feature and will use it to release calls. Otherwise, the absence of the MMRS feature indication in the supportedFeatures field indicates that the responder does not support MMRS or cannot use it for this call, in which case the originator may release the ca

49、ll setup. 4 ITU-T Rec. H.460.16 (01/2005) 4.4 Call signalling release 4.4.1 Facility message encoding The function of the Q.931 disconnect and release messages are provided by the H.225.0 facility message. The corresponding fields of the facility message shall be used to carry the information normally in the disconnect and release messages. Those additional fields, which are not defined in H.225.0 as being included in the facility message but are required in the release sequence shall be encoded in the “MMRS Additional IEs“ parameter. 4.4.2 Facility