ITU-T H 501-2002 SERIES H AUDIOVISUAL AND MULTIMEDIA SYSTEMS Mobility and Collaboration procedures C Overview of Mobility and Collaboration definitions protocols and procedures Pro-.pdf

《ITU-T H 501-2002 SERIES H AUDIOVISUAL AND MULTIMEDIA SYSTEMS Mobility and Collaboration procedures C Overview of Mobility and Collaboration definitions protocols and procedures Pro-.pdf》由会员分享，可在线阅读，更多相关《ITU-T H 501-2002 SERIES H AUDIOVISUAL AND MULTIMEDIA SYSTEMS Mobility and Collaboration procedures C Overview of Mobility and Collaboration definitions protocols and procedures Pro-.pdf（46页珍藏版）》请在麦多课文档分享上搜索。

1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T H.501TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2002) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSMobility and Collaboration procedures Overview of Mobility and Collaboration, definitions, protocols and procedures Protocol for mobility management

2、 and intra/inter-domain communication in multimedia systems ITU-T Recommendation H.501 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 sync

3、hronization H.220H.229 Systems aspects H.230H.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.399 SUPPLEMENTARY SERVICES FOR MULTIMEDIA H.450H.499 MOBILITY AND COLLABORATION PR

4、OCEDURES 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 applications and services H.520H.529 Security for mobile multimedia systems and services H.530H.539 Secur

5、ity 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 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. H.501 (03/2002) i ITU-T Reco

6、mmendation H.501 Protocol for mobility management and intra/inter-domain communication in multimedia systems Summary The purpose of this Recommendation is to define messages and procedures for mobility management and for communication within and between domains of a mobile or non-mobile multimedia e

7、nvironment for the purpose of address resolution, user authentication, service data exchange, access authorization, call validation and usage reporting. Source ITU-T Recommendation H.501 was prepared by ITU-T Study Group 16 (2001-2004) and approved under the WTSA Resolution 1 procedure on 29 March 2

8、002. Keywords Address resolution, administrative domains, authentication, authorization, H.225.0 Annex G, mobility management, multimedia systems, usage reporting. ii ITU-T Rec. H.501 (03/2002) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the f

9、ield 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 Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The

10、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 procedure laid down in WTSA Resolution 1.

11、 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 telecommunication administration and a re

12、cognized operating agency. 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

13、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 implement this Recommenda

14、tion. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2002 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission

15、 of ITU. ITU-T Rec. H.501 (03/2002) iii CONTENTS Page 1 Scope 1 2 Normative references 1 3 Definitions 2 4 Symbols and abbreviations. 2 5 Requirements 2 5.1 Transport requirements. 2 5.2 Security considerations. 3 5.3 Addressing conventions 3 5.4 Address templates and descriptors . 4 6 Message defin

16、itions 4 6.1 Descriptor . 5 6.2 Descriptor information . 6 6.3 Address template 6 6.3.1 Pattern. 6 6.3.2 Route information. 7 6.3.3 Pricing information. 7 6.3.4 Contact information 8 6.4 Common structures. 9 6.4.1 AlternatePE. 9 6.4.2 PartyInformation. 9 6.4.3 CallInformation 10 6.4.4 UserInformatio

17、n . 10 6.4.5 Usage specification. 10 6.4.6 Security Mode 11 6.5 Service relationship 11 6.5.1 Service Request 11 6.5.2 Service Confirmation 12 6.5.3 Service Rejection 13 6.5.4 Service Release. 14 6.6 Descriptor distribution 14 6.6.1 Descriptor Request . 14 6.6.2 Descriptor Confirmation. 14 6.6.3 Des

18、criptor Rejection. 14 6.6.4 Descriptor ID Request 15 6.6.5 Descriptor ID Confirmation . 15 6.6.6 Descriptor ID Rejection 15 iv ITU-T Rec. H.501 (03/2002) Page 6.6.7 Descriptor Update. 16 6.6.8 Descriptor Update Acknowledgement . 16 6.7 Address resolution 16 6.7.1 Access Request. 16 6.7.2 Access Conf

19、irmation 17 6.7.3 Access Rejection 17 6.8 Request in Process 18 6.9 Non-standard messages 18 6.9.1 Non-Standard Request 18 6.9.2 Non-Standard Confirmation . 18 6.9.3 Non-Standard Rejection . 18 6.10 Unknown Message Response. 19 6.11 Usage reports 19 6.11.1 Usage Request 19 6.11.2 Usage Confirmation

20、19 6.11.3 Usage Rejection 20 6.11.4 Usage Indication. 20 6.11.5 Usage Indication Confirmation 21 6.11.6 Usage Indication Rejection. 21 6.12 Validations 22 6.12.1 Validation Request . 22 6.12.2 Validation Confirmation. 22 6.12.3 Validation Rejection. 22 6.13 Authentication 23 6.13.1 Authentication Re

21、quest 23 6.13.2 Authentication Confirmation 23 6.13.3 Authentication Rejection 23 Annex A Message Syntax. 24 ITU-T Rec. H.501 (03/2002) 1 ITU-T Recommendation H.501 Protocol for mobility management and intra/inter-domain communication in multimedia systems 1 Scope This Recommendation describes a pro

22、tocol for communication between logical elements of a multimedia packet network to allow the completion of calls to and from users managed by such logical elements. This protocol can be used in mobile and non-mobile environments for the purpose of address resolution, user authentication, service dat

23、a exchange, access authorization, call validation and usage reporting. These capabilities enable the protocol to be used for mobility management in mobile environments. The general procedure is for logical elements to exchange information regarding the location of users or endpoints, in the form of

24、addresses each administrative domain can resolve. Addresses can be specified in a general manner or in an increasingly specific manner. Additional information allows elements within an administrative domain to determine the most appropriate administrative domain to serve as the destination for the c

25、all. Logical elements may control access to their exposed addresses, and require reports on the usage made during calls to those addresses. Other Recommendations will specify how the protocol defined in this Recommendation is used by particular applications. It is not necessary for an application to

26、 implement the full protocol. The application can select from the messages and procedures those relevant to its requirements. 2 Normative references The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recomm

27、endation. 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 encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other referen

28、ces listed below. A list of the currently valid ITU-T Recommendations is regularly published. ITU-T Recommendation E.164 (1997), The international public telecommunication numbering plan. ITU-T Recommendation H.225.0 Version 4 (2000), Call signalling protocols and media stream packetization for pack

29、et-based multimedia communication systems. ITU-T Recommendation H.235 Version 2 (2000), Security and encryption for H-series (H.323 and other H.245-based) multimedia terminals. ITU-T Recommendation H.323 Version 4 (2000), Packet-based multimedia communications systems. ITU-T Recommendation X.680 (19

30、97), Information technology Abstract Syntax Notation One (ASN.1): Specification of basic notation. ITU-T Recommendation X.691 (1997), Information technology ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). IETF RFC 2401 (1998), Security Architecture for the Internet Protocol. IETF

31、 RFC 2402 (1998), IP Authentication Header. IETF RFC 2406 (1998), IP Encapsulating Security Payload (ESP). 2 ITU-T Rec. H.501 (03/2002) ISO 4217:2001, Codes for the representation of currencies and funds. 3 Definitions This Recommendation defines the following terms: 3.1 administrative domain: An ad

32、ministrative domain is a collection of logical and physical entities administered by one administrative entity. An administrative domain can consist of one or more zones. 3.2 gatekeeper: A logical element that provides specific services (number translation, access control, etc.) to other entities wi

33、thin an administrative domain (see also ITU-T Rec. H.323). 3.3 logical element: An entity with defined functionality in a network. Logical elements do not impose any requirements on their provision; their functionality can be implemented in any suitable way in hard- or software. 3.4 peer element: A

34、logical element which originates or terminates signalling messages defined in this Recommendation. Examples are H.225.0 Annex G border elements or H.323 gatekeepers. 3.5 zone: The subset of entities of an administrative domain under the control of a single gatekeeper. 4 Symbols and abbreviations Thi

35、s Recommendation uses the following abbreviations: AD Administrative domain DH Diffie-Hellman key agreement protocol (ITU-T Rec. X.509) DNS Domain Name System IP Internet Protocol OID Object Identifier PDU Protocol Data Unit RAS Registration, Admission and Status protocol SCN Switched Circuit Networ

36、k TCP Transmission Control Protocol TPKT Transport Packet UDP User Datagram Protocol URL Uniform Resource Locator UTC Universal Time Coordinated 5 Requirements 5.1 Transport requirements Messages may be sent over an unreliable transport service (e.g. UDP) or a reliable transport service (e.g. TCP) t

37、o a well-known address. On IP networks, the well-known port (2099) should be used for both TCP and UDP, unless another port has been communicated to the sender. Elements shall listen on both TCP and UDP ports. ITU-T Rec. H.501 (03/2002) 3 When messages are sent over the reliable transport service, w

38、hole messages shall be sent within the boundaries defined by the reliable transport protocol data unit (PDU). (In IP implementations, for instance as outlined in H.225.0 Appendix IV, this PDU is defined by TPKT; see Figure 1. Each H.501 PDU contains a single message defined in this Recommendation.)

39、TPKT H.501 PDU TPKT H.501 PDU TPKT H.501 PDU Figure 1/H.501 TCP transport When using an unreliable transport service, request messages may be retransmitted. The default value of the retransmission timer should be determined by an adaptive delay sensitive method (such as the one used by the TCP proto

40、col). Exponential backoff shall be used for subsequent retransmissions. The number of retransmissions shall not exceed 5. Responses shall not be retransmitted. In UDP IP implementations, messages shall also be prefixed with TPKT headers, to enable multiple messages per packet, see Figure 2. Each H.5

41、01 PDU contains a single message defined in this Recommendation. The UDP packet length field shall hold the total length of the payload, including all the messages and their TPKT headers. TPKT H.501 PDU TPKT H.501 PDU TPKT H.501 PDU UDP header Figure 2/H.501 UDP datagram format 5.2 Security consider

42、ations When authentication, integrity, and encryption on the transport layer is desired for messages exchanged between peer elements, the operation of IP security shall be followed as described in IETF RFC 2401, including either, or both, of IETF RFC 2402, and IETF RFC 2406. Where protection on the

43、application layer is required, the procedures and constructs of ITU-T Rec. H.235 shall be utilized to support application-level security. Specifically, the token formats and authentication exchanges shall be used. Tokens and crypto-tokens received in response messages should be used in a subsequent

44、related request. 5.3 Addressing conventions In order to provide interoperability between domains, it is important that the addressing formats sent in signalling messages are understood by the receiving system. A peer element shall support all types of AliasAddress that an application may globally us

45、e. At a minimum, the formats email-id and partyNumber (using PublicNumber with PublicTypeOfNumber of internationalNumber) shall be supported. When communicating with other peer elements, only the email-id and partyNumber types of AliasAddress should be used, unless there has been prior agreement on

46、the use of other formats between the administrative domains concerned. For example, if a group of administrative domains have agreed on the interpretation of a private numbering plan, then these numbers may be used in messages amongst them. In a mobile environment, the format mobileUIM may be used a

47、s a global user identification module upon agreement amongst the administrative domains concerned. This format is described in detail in ITU-T Rec. H.225.0. 4 ITU-T Rec. H.501 (03/2002) 5.4 Address templates and descriptors An address template (“template“, for short) defines a set of AliasAddress id

48、entifiers, pricing information to complete calls to those addresses, and the protocol to be used in reaching addresses in that set. An administrative domain advertises templates to indicate the calls it can resolve. Templates are grouped together by an identifier known as a “descriptor“. Once a temp

49、late is grouped by a descriptor, any change to a template under that descriptor implies a change to the descriptor “group“. Template information may allow the aggregation of addressing information if the addressing scheme is arranged in some hierarchical or routable manner (for example, a given zone might handle 1303538*, meaning all telephone numbers that begin with 1303538). NOTE Since “*“ is a meaningful character, the template actually includes an explicit field to indicate whether the address is a specific address or a wildcard