ITU-T H 460 1-2013 Guidelines for the use of the generic extensible framework (Study Group 16)《(预发布)通用可扩展框架的使用指南》.pdf

《ITU-T H 460 1-2013 Guidelines for the use of the generic extensible framework (Study Group 16)《(预发布)通用可扩展框架的使用指南》.pdf》由会员分享，可在线阅读，更多相关《ITU-T H 460 1-2013 Guidelines for the use of the generic extensible framework (Study Group 16)《(预发布)通用可扩展框架的使用指南》.pdf（22页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T H.460.1TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2013) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Supplementary services for multimedia Guidelines for the use of the generic extensible framework Recommenda

2、tion ITU-T H.460.1 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 Communication proc

3、edures 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 multimedia

4、services H.360H.369 Supplementary services for multimedia H.450H.499MOBILITY 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 collaboration applicat

5、ions 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.560H.569 BROADBAND, TRI

6、PLE-PLAY AND ADVANCED MULTIMEDIA SERVICES Broadband multimedia services over VDSL H.610H.619 Advanced multimedia services and applications H.620H.629 Ubiquitous sensor network applications and Internet of Things H.640H.649 IPTV MULTIMEDIA SERVICES AND APPLICATIONS FOR IPTV General aspects H.700H.719

7、 IPTV terminal devices H.720H.729 IPTV middleware H.730H.739 IPTV application event handling H.740H.749 IPTV metadata H.750H.759 IPTV multimedia application frameworks H.760H.769 IPTV service discovery up to consumption H.770H.779 Digital Signage H.780H.789 For further details, please refer to the l

8、ist of ITU-T Recommendations. Rec. ITU-T H.460.1 (03/2013) i Recommendation ITU-T H.460.1 Guidelines for the use of the generic extensible framework Summary Recommendation ITU-T H.460.1 gives guidelines on how to use the “Generic Extensible Framework“ specified in Recommendation ITU-T H.323. It desc

9、ribes when to use the framework, and how to specify features using the framework. It also gives examples on how the frameworks negotiation scheme works. This revision introduces a number of corrections and clarifications by incorporating technical and editorial corrections from the ITU-T H.323-serie

10、s Implementers Guide (03/2011). History Edition Recommendation Approval Study Group 1.0 ITU-T H.460.1 2002-03-29 16 2.0 ITU-T H.460.1 2013-03-16 16 ii Rec. ITU-T H.460.1 (03/2013) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of teleco

11、mmunications, information and communication technologies (ICTs). 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 Recommendations on them with a view to standardizing telecomm

12、unications 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 of ITU-T Recommendations is covered by the proc

13、edure 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“ is used for conciseness to indicate both a tele

14、communication 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 with the Recommendation is achieved when all of t

15、hese 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 required of any party. INTELLECTUAL PROPERTY RIGHTS I

16、TU 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 Intellectual Property Rights, whether asserted by ITU mem

17、bers 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. However, implementers are cautioned that this may n

18、ot represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2013 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T H.460

19、.1 (03/2013) iii Table of Contents Page 1 Scope 1 2 References. 1 3 Abbreviations and acronyms 1 4 What is GEF . 1 5 When to use GEF 2 6 GEF module identification . 3 7 Specifying GEF modules 3 7.1 Table-based method 3 7.2 Encoded in raw method 5 Appendix I Sample GEF message exchanges . 6 I.1 Examp

20、les of GEF negotiation 6 Bibliography. 13 Rec. ITU-T H.460.1 (03/2013) 1 Recommendation ITU-T H.460.1 Guidelines for the use of the generic extensible framework 1 Scope This Recommendation provides information on when and how to use the generic extensible framework (GEF) defined in ITU-T H.323. It d

21、oes not repeat the text from ITU-T H.323. Instead, it expands and elaborates on the text in ITU-T H.323 and thus should be read in conjunction with ITU-T H.323 rather than being viewed as a substitute to it. The main topics covered by this Recommendation are: when to use GEF, how to specify GEF modu

22、les, and examples of the GEF negotiation mechanism. 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 H.225.0 Recommendation ITU-T H.225.0 (2009), Call signalling protocols and media stream packetization for packet-based multimedia communication systems.

25、 ITU-T H.323 Recommendation ITU-T H.323 (2009), Packet-based multimedia communications systems. 3 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: ABNF Augmented Backus-Naur Form ASN.1 Abstract Syntax Notation One GEF Generic Extensible Framework XML Exte

26、nsible Markup Language 4 What is GEF The generic extensible framework (GEF) provides a low overhead way of adding functionality to ITU-T H.323 without adding to the ASN.1 base specification of ITU-T H.225.0. GEF provides a common feature negotiation mechanism, and the ability to carry opaque data in

27、 all ITU-T H.225.0 and Annex G messages of ITU-T H.225.0. Thus it allows application specific extensions to be made to the ITU-T H.323 suite of Recommendations without burdening all ITU-T H.323 implementations with all specified extensions. GEF is explained formally in the main body of ITU-T H.323.

28、2 Rec. ITU-T H.460.1 (03/2013) 5 When to use GEF New functionality can be added to ITU-T H.323 by adding new syntax to the ITU-T H.225.0 ASN.1 base definition, defining a GEF module, or defining an ITU-T H.450 supplementary service. When deciding which method to use, it may be appropriate to conside

29、r the feature negotiation aspects and the data transport aspects of the feature separately. Thus, in some cases, it may be appropriate to implement a feature primarily as an ITU-T H.450 supplementary service, but negotiate the feature using GEFs feature negotiation capabilities. To decide which meth

30、od should be used to add new functionality, the following guidelines are suggested. If the feature is applicable to a large number of applications, then it may be appropriate to add it to the ITU-T H.225.0 ASN.1 base specification directly. Note that, as ITU-T H.323 is now fairly mature, it is not e

31、xpected that such features will be encountered and a strong case will need to be made for taking this course of action. The most likely situation in which this will occur is in the case of extending already existing parameters such as AliasAddress and TransportAddress. Or if the feature only require

32、s a few parameters, then define it as a GEF module. Or if the feature requires data to be carried in ITU-T H.225.0 RAS or Annex G of ITU-T H.225.0, then define it as a GEF module. Or if the feature contains numerous parameters, then define it as either ASN.1 (or similar method such as ABNF or XML) t

33、o be encoded into a raw element of a GEF content construct, or define an ITU-T H.450 supplementary service. These considerations are captured in the flow chart shown in Figure 1 below. H.460.1(13)_F01StartYesYesNoNoYesDefine inITU-T H.225.0Annex Hbase specificationUse GEF table-basedmethodUse GEF en

34、coded inraw method orITU-T H.450Use GEF encoded inraw methodCore to allapplications?Only a fewparametersrequired?Datarequired in RASand/orAnnex G?NoFigure 1 Decision tree for how to specify a new feature Rec. ITU-T H.460.1 (03/2013) 3 6 GEF module identification GEF allows for both ITU-T approved an

35、d non-ITU-T approved module definitions. All ITU-T approved GEF module definitions shall be defined as part of the ITU-T H.460 series of Recommendations and shall use the standard variant of id in GenericData to identify them. All non-ITU-T approved modules shall use either the oid or nonStandard va

36、riants of id in GenericData to identify them. There is a direct relationship between an ITU-T H.460 series Recommendations identity and the value encoded into the standard variant of id in GenericData. That is Recommendation ITU-T H.460.n (where n is an integer number) shall use the value n in the s

37、tandard variant of id in GenericData to identify the module. For example, ITU-T H.460.2 shall have the standard variant of id in GenericData set to 2. 7 Specifying GEF modules GEF modules may be specified in a number of ways, clarity of definition being the principle concern. To provide some consist

38、ency of specification, this clause describes two ways in which GEF modules can be defined, these being the table-based method and the encoded in raw method. Note that if a feature requires both negotiation and opaque data transfer, it may be necessary to document the requirements for each in separat

39、e sections of the specification. 7.1 Table-based method In the table-based method, each of the parameters constituting a feature is described in tabular form. Each parameter definition maps to a separate EnumeratedParameter for data exchange. Note that the tables are not expected to capture all the

40、detail of the features use and operation and additional explanatory text would typically be expected. An instance of Table 1 is used to describe the feature as a whole. This captures the features name, its identifier and a brief description. A single instance of this table suffices for features that

41、 contain both negotiation and data transport. Table 1 Tabular specification of a feature Feature name The name of the feature Feature Description: Short description of the feature. This may be augmented by text elsewhere in the document describing the feature. Feature identifier type: Indicates whet

42、her the identifier is Standard, oid, or nonStandard. Feature identifier value: The actual value of the identifier. Each parameter used by the feature is described using an instance of Table 2. Once again, this includes the parameters name, identifier and description as well as other information. Par

43、ameters conveyed within compound or nested parameters should be described in a separate section of the specification. If parameters are needed for both the negotiation and data transport aspects of the feature, it may be appropriate to have the two sets of parameters captured in different sections o

44、f the specification describing the feature. 4 Rec. ITU-T H.460.1 (03/2013) Table 2 Tabular specification of a parameter Parameter name The name of the parameter Parameter description: Short description of the parameter Parameter identifier type: Indicates whether the identifier is Standard, oid, or

45、nonStandard Parameter identifier value: The actual value of the identifier Parameter type: One of raw, text, unicode, bool, number8, number16, number32, id, alias, transport, compound, nested. Parameter cardinality: How many times the parameter may occur 7.1.1 Example definition of a fictitious feat

46、ure using the table-based method This clause gives a fictitious example of a feature using the table-based method of feature definition. Table 3 Specification of the fictitious example feature Feature name Fictitious example Feature description: This is a fictitious example to illustrate how to use

47、the table-based method to specify a GEF module. Feature identifier type: Standard Feature identifier value: 1 Table 4 Parameters for the fictitious example feature Parameter name priority Parameter description: Describes the priority of this call in relation to other calls that may be received. Para

48、meter identifier type: Standard Parameter identifier value: 0 Parameter type: number8 Parameter cardinality: Once and once only Parameter name destination Parameter description: Identity of the remote party that is being contacted. Parameter identifier type: Standard Parameter identifier value: 1 Pa

49、rameter type: alias Parameter cardinality: One or more Rec. ITU-T H.460.1 (03/2013) 5 Parameter name message-display-lines Parameter description: One of more message lines that should be displayed when the call is being processed. Parameter identifier type: Standard Parameter identifier value: 2 Parameter type: text Parameter cardinality: Zero or more 7.2 Encoded in raw method The second method of GEF module definition defines a feature using existing message encoding methods, such as ASN.1, XML or ABNF