ECMA TR 96-2008 Next Generation Corporate Networks (NGCN) - Identification and Routing (1st Edition)《下一代企业网络(NGCN) 识别和路由 第1版》.pdf

《ECMA TR 96-2008 Next Generation Corporate Networks (NGCN) - Identification and Routing (1st Edition)《下一代企业网络(NGCN) 识别和路由 第1版》.pdf》由会员分享，可在线阅读，更多相关《ECMA TR 96-2008 Next Generation Corporate Networks (NGCN) - Identification and Routing (1st Edition)《下一代企业网络(NGCN) 识别和路由 第1版》.pdf（27页珍藏版）》请在麦多课文档分享上搜索。

1、 Next Generation Corporate Networks (NGCN) - Identification and Routing ECMA TR/96 1stEdition / June 2008 Ecma International Rue du Rhne 114 CH-1204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org IW TR-096.doc 05/06/2008 12:11:00 Next Generation Corporate Networks (NGCN) - Identification

2、and Routing Technical Report ECMA TR/96 1stEdition / June 2008 . Introduction This Ecma Technical Report is one of a series of Ecma publications that explore IP-based enterprise communication involving Corporate telecommunication Networks (CNs) (also known as enterprise networks) and in particular N

3、ext Generation Corporate Networks (NGCN). The series particularly focuses on inter-domain communication, including communication between parts of the same enterprise, between enterprises and between enterprises and carriers. This particular Ecma Technical Report discusses issues related to user iden

4、tities and routing and builds upon concepts introduced in ECMA TR/95. This Technical Report is based upon the practical experience of Ecma member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI, IETF and other international and national

5、 standardization bodies. It represents a pragmatic and widely based consensus. In particular, Ecma acknowledges valuable input from experts in ETSI TISPAN. This Ecma Technical Report has been adopted by the General Assembly of June 2008. - i - Table of contents 1 Scope 1 2 References 1 3 Definitions

6、 2 3.1 External definitions 2 3.2 Other definitions 2 3.2.1 Number-based SIP URI 2 3.2.2 Home number-based SIP URI 2 3.2.3 Transient number-based SIP URI 2 3.2.4 Telephone number 2 4 Abbreviations 3 5 Background 3 6 Identified entities 3 7 Types of identifier 4 7.1 SIP, SIPS and TEL URIs as user ide

7、ntifiers (AoRs) 4 7.1.1 Use of E.164 numbers 7 7.1.2 Private numbers formatted as telephone-subscriber strings 10 7.1.3 Email-style SIP URIs 11 7.2 Dial strings 11 7.3 Service identifiers 12 7.4 Device identifiers 12 8 Routing 13 8.1 General routing principles 13 8.2 Routing to the enterprise domain

8、 14 8.3 Routing to the home server within the enterprise domain 15 8.4 Roaming considerations 15 9 Identification delivery and restriction 16 9.1 Identification delivery 16 9.2 Authenticity 16 9.3 Restriction 17 - ii - 10 Summary of requirements and standardisation gaps 18 10.1 Requirements on NGNs

9、18 10.2 Requirements on enterprise networks 19 10.3 Standardisation gaps 19 - 1 - 1 Scope This Ecma Technical Report is one of a series of publications that provides an overview of IP-based enterprise communication involving Corporate telecommunication Networks (CNs) (also known as enterprise networ

10、ks) and in particular Next Generation Corporate Networks (NGCN). The series particularly focuses on session level communication based on the Session Initiation Protocol (SIP) 4, with an emphasis on inter-domain communication. This includes communication between parts of the same enterprise (on dedic

11、ated infrastructures and/or hosted), between enterprises and between enterprises and public networks. Particular consideration is given to Next Generation Networks (NGN) as public networks and as providers of hosted enterprise capabilities. Key technical issues are investigated, current standardisat

12、ion work and gaps in this area are identified, and a number of requirements are stated. Among other uses, this series of publications can act as a reference for other standardisation bodies working in this field, including ETSI TISPAN, 3GPP, IETF and ITU-T. This particular Technical Report discusses

13、 session level user identification and routing. It uses terminology and concepts developed in TR/NGCN-General 3. It identifies a number of requirements impacting NGN standardisation and concerning deployment of enterprise networks. The scope of this Technical Report is limited to communications with

14、 a real-time element, including but not limited to voice, video, real-time text and instant messaging. 2 References 1 ECMA-155 Private Integrated Services Networks - Addressing 2 ECMA TR/86 Corporate Telecommunication Networks - User Identification in a QSIG/SIP Environment 3 ECMA TR/95 Next Generat

15、ion Corporate Networks (NGCN) - General 4 IETF RFC 3261 SIP: Session Initiation Protocol 5 IETF RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers 6 IETF RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP) 7 IETF RFC 3325 Private Extensions to the Session Initiation

16、Protocol (SIP) for Asserted Identity within Trusted Networks 8 IETF RFC 3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts 9 IETF RFC 3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration 10 IETF

17、 RFC 3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) 11 IETF RFC 3966 The tel URI for Telephone Numbers 12 IETF RFC 4474 Enhancements for Identity Management in the Session Initiation Protocol (SIP) 13 IETF RFC 4916 Connected Identit

18、y in the Session Initiation Protocol (SIP) 14 IETF RFC 4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier 15 IETF RFC 5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services 16 IETF draft-ietf-sip-gruu-15 Obtaining and Using Globally Rou

19、table User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) - 2 - NOTE At the time of publication of this Technical Report, the IETF had approved draft-ietf-sip-gruu-15 as a standards track RFC but had not published the RFC and had not allocated an RFC number. If the draft is no longe

20、r available, readers should look for the RFC with the same title. 17 ITU-T Recommendation E.164 The international public telecommunication numbering plan 18 ITU-T Recommendation H.350 Directory services architecture for multimedia conferencing 3 Definitions For the purposes of this Technical Report

21、the following definitions apply: 3.1 External definitions This Technical Report uses the following terms defined in ECMA TR/95 3: Domain Enterprise network Home server Next Generation Corporate Network (NGCN) Next Generation Network (NGN) Private network traffic Public network traffic Roaming Roamin

22、g hub SIP intermediary This Technical Report uses the following terms defined in ECMA-155 1: Numbering plan Private numbering plan 3.2 Other definitions 3.2.1 Number-based SIP URI A SIP or SIPS URI that contains a user=phone parameter, denoting the presence of a telephone number in telephone-subscri

23、ber format in the user part. NOTE The telephone number can be an E.164 number or a private number. 3.2.2 Home number-based SIP URI A number-based SIP URI for a user in which the domain part identifies the domain that provides home server (registrar and proxy) functionality for that user. 3.2.3 Trans

24、ient number-based SIP URI A number-based SIP URI for a user in which the domain part does not identify the domain that provides home server (registrar and proxy) functionality for that user. NOTE Transient number-based SIP URIs are aliases for the home number-based SIP URI for the telephone number c

25、oncerned. Typically they are used during the routing of a SIP request. The domain part might, for example, contain the domain of an NGN that supports the enterprise concerned, rather than the enterprise itself. 3.2.4 Telephone number A numeric identifier that conforms to the numbering plan of a circ

26、uit-switched network. - 3 - 4 Abbreviations AoR Address of Record B2BUA Back-to-Back UA DNS Domain Name System GRUU Globally Routable UA URI IMS IP Multimedia Subsystem IP Internet Protocol ISDN Integrated Services Digital Network NGCN Next Generation Corporate Network NGN Next Generation Network PS

27、TN Public Switched Telephone Network SIP Session Initiation Protocol UA User Agent URI Universal Resource Identifier URN Universal Resource Name 5 Background General concepts of NGCNs are discussed in 3. In particular, that document describes use of the Session Initiation Protocol (SIP) 4 for sessio

28、n level communications within enterprise networks and with other domains. It focuses on enterprise networks based on enterprise infrastructure (NGCN), but also covers hosting on other networks, in particular NGNs, using the same infrastructure that supports public networks. A major consideration for

29、 SIP-based communications is identification of the users involved and routing based on such identifiers. When one user initiates a communications session, that user needs to identify the user with which the session is to be established, and the network needs to establish the session to that user or

30、to a nominated alternative. The second user often needs to receive the identity of the first user (the calling user) for various purposes. Likewise the first user often needs to receive the identity of the user to which the communication session is eventually established, which might not be the user

31、 to which establishment was originally requested. SIP provides various forms of identifiers for users. These have already been discussed in ECMA TR/86 2, primarily for the purpose of interworking with circuit-switched enterprise networks based on the QSIG signalling protocol. However, the topic need

32、s to be examined from the broader perspective of NGCNs and their SIP-based operation with other domains. 6 Identified entities Identifiers are needed for entities involved in communication within an enterprise network. For the purposes of this Technical Report, the most important identified entity i

33、s a user. A users identifier is used for several purposes, including; indicating the user with which a communication is to be established; identifying a user already participating in a communication (e.g., the identity of the calling user or the identity of the user who has responded to a communicat

34、ion request); charging. - 4 - Although in many cases a user identifier, or an Address of Record (AoR), can identify a single human user, often it can indicate something else, e.g.: a role or function performed by a single human user (e.g., director of finance), this identifier remaining the same eve

35、n though the occupant of the role might change; a group of human users (e.g., a department or function); a service or function performed by an automaton (e.g., voicemail or conferencing service). A user identifier does not explicitly identify a particular device (e.g., terminal, server). In particul

36、ar cases there may be a one-to-one relationship between device and user, but in many cases this will not be so: a user can have more than one device (e.g., a user with a PC, a fixed phone and a mobile phone or PDA; a service replicated on a number of servers); a device can support more than one user

37、 (e.g., two or more users sharing a telephone; a server supporting two or more services). Unless otherwise stated, the term identifier is used in this Technical Report is to mean a user identifier. Identifiers are also required to identify entities other than users. One example is for device identif

38、ication. Device identifiers are generally used for purposes different from those for which user identifiers are used, e.g.: to ensure that a follow on communication reaches the same device as a previous communication; to identify a device for diagnostic purposes. Another example is service identific

39、ation, e.g., emergency services. Yet another example is session or call identification, e.g., the IP Multimedia Subsystem (IMS) Charging Identifier (ICID). Some uses of identifiers require the receiver of an identifier to obtain evidence of authenticity, i.e., to authenticate the identifier. Methods

40、 of authenticating identifiers are outside the scope of this Technical Report. 7 Types of identifier 7.1 SIP, SIPS and TEL URIs as user identifiers (AoRs) For session level communications based on SIP, identifiers are in the form of Universal Resource Identifiers (URIs). For most purposes this means

41、 SIP (or SIPS) URIs of the form sip:, where ““ is the domain part and identifies a domain in accordance with the domain name system (DNS) and “user“ is the user part and identifies a particular user within that domain. Also parameters can be present. SIP and SIPS URI formats are defined in RFC 3261

42、4. For the purposes of this document, considerations for SIPS URIs (which denote certain security requirements for accessing the resource) are identical to those for SIP URIs, and therefore SIPS URIs are not explicitly mentioned in the remainder of this document. When a SIP URI is used as an AoR, in

43、 present day deployments the user part is usually in the form of a telephone number, either an E.164 number (in accordance with the E.164 number plan 17) or a private number (in accordance with a private numbering plan 1), e.g.: sip: +;user=phone sip:1234;phone-context=+;user=phone sip:1234;phone-co

44、ntext=;user=phone The first example is a fully qualified E.164 number. The remaining examples represent private numbers. - 5 - In these examples the user part is formatted as what is defined as a telephone-subscriber string in RFC 3966 11 for use in a TEL URI, and is in fact fully qualified (globall

45、y unique). This is denoted by the presence of the user=phone parameter. RFC 3261 recommends the inclusion of the user=phone parameter when the user part contains a telephone number in telephone-subscriber format. This Technical Report strongly endorses that recommendation. REQUIREMENT E1: Enterprise

46、s shall include the user=phone parameter in SIP URIs in which the user part is a telephone-subscriber string. This Technical Report refers to SIP URIs containing the user=phone parameter and a telephone-subscriber string as number-based SIP URIs. Another example found in practice is: sip:;user=phone

47、 In this example the user part is not formatted as a telephone-subscriber string and is not globally unique, but is unique within the context of the domain part. Although perhaps not intended by the authors of RFC 3261, it is found in practice and therefore should be handled if received. This format

48、 should not be used, particularly as it may cause problems interworking with NGN (for both private network traffic and public network traffic). This is because within NGN the presence of user=phone is often used as an indication that the user part can be treated as a telephone-subscriber string, whi

49、ch in this case it cannot because of the lack of a phone-context parameter. REQUIREMENT E2: Enterprises shall avoid using URIs in which the user=phone parameter is present but the user part does not contain a telephone-subscriber string. Yet another example found in practice is: sip: The user part in this example, whilst it is not marked as being a telep