1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T H.460.14TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2004) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Supplementary services for multimedia Support for Multi-Level Precedence and Preemption (MLPP) within H.32
2、3 systems ITU-T Recommendation H.460.14 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.2
3、39 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 audiov
4、isual 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 multimedia
5、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 H.5
6、60H.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.14 (03/2004) i ITU-T Recommendation H.460.14 Support for Multi-Level Precedence and Preemption (MLPP) with
7、in H.323 systems Summary This Recommendation describes the procedures and the signalling protocol for Multi-Level Precedence and Preemption (MLPP), which allow the originator of a call in an H.323 environment to specify a precedence level of the call and for an existing lower precedence call to be p
8、reempted to release resources needed to complete that higher precedence call. For the networks and domains that allow this functionality, the H.460.14 mechanism ensures that important calls can be established and can remain connected during periods of congestion. These procedures use the H.323 Gener
9、ic Extensibility Framework (GEF) and therefore do not require any changes to the base standards. Source ITU-T Recommendation H.460.14 was approved on 15 March 2004 by ITU-T Study Group 16 (2001-2004) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. H.460.14 (03/2004) FOREWORD The Internat
10、ional 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 questions and issuing Recommendatio
11、ns 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 Recommendations on these topics. The approval
12、 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, the expression “Administration“
13、 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 applicability) and compliance wit
14、h 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 with the Recommendation is require
15、d 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 applicability of claimed Intellectua
16、l 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 implement this Recommendation. Howev
17、er, 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 rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. IT
18、U-T Rec. H.460.14 (03/2004) iii CONTENTS Page 1 Scope 1 2 Introduction 1 2.1 Direct Endpoint Signalling. 1 2.2 Gatekeeper Routed Signalling 2 2.3 Decomposed Gateway 2 2.4 H.248 managed devices 3 2.5 Stimulus device 3 3 References. 4 4 Definitions 4 5 Abbreviations 5 6 Multi-level Precedence and Pree
19、mption Service description . 5 6.1 Provision of precedence levels . 5 6.2 Preemption of facilities. 6 6.3 Diversion 6 6.4 Interactions with other services 6 7 Signalling elements for MLPP . 9 7.1 Feature identifier 9 7.2 Parameter 10 8 Procedures 10 8.1 Registration, Admission and Status (RAS) 10 8.
20、2 Call signalling procedures for H.450 endpoints. 13 9 Dynamic description. 15 9.1 Operational model 15 9.2 Signalling flows 15 9.3 Call states 20 9.4 Timers. 21 10 Specification and Description Language (SDL) diagrams for MLPP 21 10.1 Behaviour of User As endpoint . 22 10.2 Behaviour of User Bs end
21、point 23 10.3 Behaviour of User Cs endpoint 26 11 Protocol interactions with other endpoint features . 26 11.1 Functional endpoints 26 11.2 Stimulus-based endpoints. 28 11.3 Interworking with Switched Circuit Network 28 Annex A ASN.1 definition . 28 ITU-T Rec. H.460.14 (03/2004) 1 ITU-T Recommendati
22、on H.460.14 Support for Multi-Level Precedence and Preemption (MLPP) within H.323 systems 1 Scope Multi-Level Precedence and Preemption provides a framework for the treatment of calls based on precedence. It supports the preemption of active calls by higher-precedence calls when resources are limite
23、d. The system presented here is designed to be adaptable to different models of endpoints within H.323. It may be used to support direct endpoint call signalling or gatekeeper-routed endpoints of varying capabilities. For example, intelligent endpoints may support the MLPP procedures internally, whi
24、le simple (e.g., stimulus-based) endpoints may require their Gatekeeper to implement the procedures in their stead. In the latter case, MLPP-specific signalling would be used only between Gatekeepers and other Gatekeepers or intelligent Gateways. The elements of MLPP signalling are rather simple, he
25、nce they are defined using the tabular method described in ITU-T Rec. H.460.1. 2 Introduction This Recommendation applies to H.323 endpoints (including Gateways) and Gatekeepers, and the interactions between them. It may be used with the direct endpoint call signalling model or the gatekeeper-routed
26、 model. This Recommendation provides signalling elements that may be used from one end of a call to the other, that is, from a calling endpoint, possibly through one or more Gatekeepers, to a destination endpoint. In addition, two types of endpoints may be supported. Functional endpoints (e.g., thos
27、e supporting H.450-series operations) are expected to support MLPP signalling to the endpoint, and should implement feature negotiation, user interaction, signalling, and timing in the endpoint. Stimulus-driven endpoints (e.g., those supporting Annex L/H.323) may remain ignorant of MLPP since the fe
28、ature operation and interactions with the user are implemented within the controlling Gatekeeper or feature server. In either case, the elements of MLPP signalling defined herein should be used between Gatekeepers. The following configurations are supported by the protocol defined in this Recommenda
29、tion. It is possible for the various parties involved in an MLPP service to be using different configurations, that is, the following shall interwork. 2.1 Direct Endpoint Signalling The configuration for the Direct Endpoint Signalling is as shown in Figure 1. Figure 1/H.460.14 Direct Endpoint Signal
30、ling configuration This Recommendation describes the signalling required to support this configuration. 2 ITU-T Rec. H.460.14 (03/2004) 2.2 Gatekeeper Routed Signalling Gatekeeper Routed Signalling has three cases as shown in Figure 2. Figure 2/H.460.14 Gatekeeper Routed Signalling configurations Fo
31、r Configuration a, the Gatekeepers are completely transparent and only route the messages. The signalling between the endpoints is the same as for the Direct Endpoint Signalling case. For Configuration b, the Gatekeepers terminate the call signalling messages and perform the exchange functions such
32、as routing and feature interactions. The signalling between each Gatekeeper and its connected Endpoint and between the Gatekeepers is the same as for the Direct Endpoint Signalling case; however, the messages on each portion will be different. For Configuration c, the Gatekeepers terminate the call
33、signalling messages and perform the exchange functions such as routing and feature interactions. The signalling between the Gatekeepers is the same as for the Direct Endpoint Signalling case. This Recommendation does not address any non-standard protocol which might be used in Configuration c for co
34、mmunications with the endpoints. 2.3 Decomposed Gateway As shown in Figure 19/H.323, an endpoint may be a gateway to the PSTN. It may be decomposed and utilize H.248 signalling as shown in Figure 3. ITU-T Rec. H.460.14 (03/2004) 3 Figure 3/H.460.14 Decomposed Gateway configuration This Recommendatio
35、n does not address the H.248 capabilities which may be required for this configuration. 2.4 H.248 managed devices As shown in Figure 20/H.323, H.248 may be used to manage (control) the service operation in an endpoint. In this case, the end device functions as the Media Gateway portion of a decompos
36、ed Gateway as shown in Figure 4, but without capabilities related to interworking to other signalling systems. Figure 4/H.460.14 H.248 managed device This Recommendation does not address the H.248 capabilities which may be required for this configuration. 2.5 Stimulus device An endpoint may operate
37、using a stimulus protocol in accordance with Annex L/H.323 as shown in Figure 5 and Figure 21/H.323. The Feature Server functional entity may be associated with, or collocated with, a Gatekeeper. 4 ITU-T Rec. H.460.14 (03/2004) H.460.14Media(as above)FeatureServer BorGatekeeperStimulus Device B(end-
38、usersterminal)H.225.0 withAnnex L/H.323Figure 5/H.460.14 Stimulus signalling using Annex L/H.323 This Recommendation does not address the signalling between the Feature Server/Gatekeeper and the Stimulus Device which may be required for this configuration. As described in ITU-T Rec. H.323 for intera
39、ctions with H.450-services, the Feature Server must terminate the H.460 signalling and handle the MLPP operations described in this Recommendation, while using a stimulus protocol to signal via the terminal to the user as described in Annex L/H.323. 3 References The following ITU-T Recommendations a
40、nd 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 Recommendation are therefore enco
41、uraged 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 published regularly. The reference to a document within this Recommendation does not give it, as a stand-alone do
42、cument, 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.245 (2003), Control protocol for multimedia communication. ITU-T Recommendation H.323 (2003)
43、, Packet-based multimedia communications systems. ITU-T Recommendations of the H.450.x series, Supplementary services for multimedia. ITU-T Recommendation H.460.1 (2002), Guidelines for the Use of the Generic Extensible Framework. 4 Definitions This Recommendation defines the following terms: 4.1 al
44、ternate party: A third party to whom an MLPP call may be diverted if it is not accepted or acknowledged by the called user. 4.2 diversion: The operation in which a precedence call is redirected to a pre-assigned alternate party due to (in)action by the called party. 4.3 preemption: The act of forcib
45、ly removing a connection in order to free up facilities for another higher-precedence call. 4.4 preemption in progress: The period of time after a party is notified that their existing call is going to be preempted until the preemption actually occurs and is completed by the intended party acknowled
46、ging the action. ITU-T Rec. H.460.14 (03/2004) 5 4.5 served user, user A: The user who requests to originate a call using MLPP (calling user). 4.6 user B: The wanted user that is subject to the call preemption (called user). 4.7 user C: The other user in the established call, also referred to as the
47、 unwanted user. 5 Abbreviations This Recommendation uses the following abbreviations: ACF Admission confirmation ARJ Admission rejectation ARQ Admission request DCF Disengage confirmation DRQ Disengage request GCF Gatekeeper confirmation GK Gatekeeper GRQ Gatekeeper request LCF Location confirmation
48、 LRJ Location rejectation LRQ Location request MLPP Multi-level precedence and preemption RAS Registration, admission and status RCF Registration confirmation RRJ Registration rejectation RRQ Registration request 6 Multi-level Precedence and Preemption Service description The basic requirements for
49、MLPP are the ability of call processing equipment to signal the precedence of each call, and for each entity (Gatekeeper, Gateway, or endpoint) which handles a call to properly manage resources for that call according to its precedence. This may well include the termination (preemption) of one or more active calls of lower precedence. 6.1 Provision of precedence levels A maximum precedence level shall be allocated to each user, which shall have a value in the range from 4 (lowest level) to 0 (highest level). Each user shall be provided with a m
