ETSI TR 102 634 V1.1.1 (2008-11)

Corporate Networks (NGCN) Next Generation Corporate Networks (NGCN) - Identification and Routing

DTR/ECMA-00353

General Information

• Status: Published
• Publication Date: 05-Nov-2008
• Technical Committee: Ecma - Standardizing information and communications systems
• Current Stage: 12 - Completion
• Due Date: 12-Nov-2008
• Completion Date: 06-Nov-2008

Standards Content (Sample)

ETSI TR 102 634 V1.1.1 (2008-11)
Technical Report


Coporate Networks (NGCN)
Next Generation Corporate Networks (NGCN) -
Identification and Routing

---------------------- Page: 1 ----------------------
2 ETSI TR 102 634 V1.1.1 (2008-11)



Reference
DTR/ECMA-00353
Keywords
ID, IP, SIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2008.
All rights reserved.

TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TR 102 634 V1.1.1 (2008-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 6
3 Definitions . . 7
3.1 External definitions . 7
3.2 Other definitions . 7
3.2.1 Number-based SIP URI . 7
3.2.2 Home number-based SIP URI . 7
3.2.3 Transient number-based SIP URI . 7
3.2.4 Telephone number . 8
4 Abbreviations . 8
5 Background . 8
6 Identified entities . 8
7 Types of identifier . 9
7.1 SIP, SIPS and TEL URIs as user identifiers (AoRs) . 9
7.1.1 Use of E.164 numbers . 12
7.1.2 Private numbers formatted as telephone-subscriber strings . 14
7.1.3 Email-style SIP URIs . 15
7.2 Dial strings . 16
7.3 Service identifiers . 16
7.4 Device identifiers . 17
8 Routing . 17
8.1 General routing principles . 17
8.2 Routing to the enterprise domain . 18
8.3 Routing to the home server within the enterprise domain . 19
8.4 Roaming considerations . 19
9 Identification delivery and restriction . 20
9.1 Identification delivery . 20
9.2 Authenticity . 21
9.3 Restriction . 21
10 Summary of requirements and standardisation gaps . 22
10.1 Requirements on NGNs . 22
10.2 Requirements on enterprise networks. 23
10.3 Standardisation gaps . 23
History . 24

ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 102 634 V1.1.1 (2008-11)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ECMA on behalf of its members and those of the European
Telecommunications Standards Institute (ETSI).
Introduction
The present document 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 Next
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. The
present document discusses issues related to user identities and routing and builds upon concepts introduced in ECMA
TR/95.
The present document 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 standardization bodies. It represents a pragmatic and widely based consensus. In particular, ECMA
acknowledges valuable input from experts in ETSI TISPAN.
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 102 634 V1.1.1 (2008-11)
1 Scope
The present document 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 networks) and in particular Next
Generation Corporate Networks (NGCN). The series particularly focuses on session level communication based on the
Session Initiation Protocol (SIP) [i.4], with an emphasis on inter-domain communication. This includes communication
between parts of the same enterprise (on dedicated 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
standardisation 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.
The present document discusses session level user identification and routing. It uses terminology and concepts
developed in TR/NGCN-General [i.3]. It identifies a number of requirements impacting NGN standardisation and
concerning deployment of enterprise networks.
The scope of the present document is limited to communications with a real-time element, including but not limited to
voice, video, real-time text and instant messaging.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 102 634 V1.1.1 (2008-11)
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ECMA-155: "Private Integrated Services Networks - Addressing".
[i.2] ECMA TR/86: "Corporate Telecommunication Networks - User Identification in a QSIG/SIP
Environment".
[i.3] ECMA TR/95: "Next Generation Corporate Networks (NGCN) - General".
[i.4] IETF RFC 3261: "SIP: Session Initiation Protocol".
[i.5] IETF RFC 3263: "Session Initiation Protocol (SIP): Locating SIP Servers".
[i.6] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
[i.7] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks".
[i.8] IETF RFC 3327: "Session Initiation Protocol (SIP) Extension Header Field for Registering
Non-Adjacent Contacts".
[i.9] IETF RFC 3608: "Session Initiation Protocol (SIP) Extension Header Field for Service Route
Discovery During Registration".
[i.10] IETF RFC 3761: "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)".
[i.11] IETF RFC 3966: "The tel URI for Telephone Numbers".
[i.12] IETF RFC 4474: "Enhancements for Identity Management in the Session Initiation
Protocol (SIP)".
[i.13] IETF RFC 4916: "Connected Identity in the Session Initiation Protocol (SIP)".
[i.14] IETF RFC 4967:"Dial String Parameter for the Session Initiation Protocol Uniform Resource
Identifier".
[i.15] IETF RFC 5031:"A Uniform Resource Name (URN) for Emergency and Other Well-Known
Services".
[i.16] IETF draft-ietf-sip-gruu-15 "Obtaining and Using Globally Routable User Agent (UA) URIs
(GRUU) in the Session Initiation Protocol (SIP)".
NOTE: At the time of publication of the present document, 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 longer available, readers should look for the RFC with the same title.
[i.17] ITU-T Recommendation E.164: "The international public telecommunication numbering plan".
[i.18] ITU-T Recommendation H.350: "Directory services architecture for multimedia conferencing".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 102 634 V1.1.1 (2008-11)
3 Definitions
For the purposes of the present document the following terms and definitions apply:
3.1 External definitions
The present document uses the following terms defined in ECMA TR/95 [i.3]:
• Domain
• Enterprise network
• Home server
• Next Generation Corporate Network (NGCN)
• Next Generation Network (NGN)
• Private network traffic
• Public network traffic
• Roaming
• Roaming hub
• SIP intermediary
The present document uses the following terms defined in ECMA-155 [i.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-subscriber 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 Transient 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 concerned. 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.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 102 634 V1.1.1 (2008-11)
3.2.4 Telephone number
A numeric identifier that conforms to the numbering plan of a circuit-switched network.
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
NAT Network Address Translation
NGCN Next Generation Corporate Network
NGN Next Generation Network
PDA Personal Digital Assistant
PSTN 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 [i.3]. In particular, that document describes use of the Session Initiation
Protocol (SIP) [i.4] for session 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 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 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 to which establishment was originally requested.
SIP provides various forms of identifiers for users. These have already been discussed in ECMA TR/86 [i.2], primarily
for the purpose of interworking with circuit-switched enterprise networks based on the QSIG signalling protocol.
However, the topic needs 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 the
present document, the most important identified entity is a user. A user's 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 communication request);
• charging.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 102 634 V1.1.1 (2008-11)
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 even 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 particular 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 (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 the present document is to mean a user identifier.
Identifiers are also required to identify entities other than users.
One example is for device identification. 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 identification, 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 of authenticating identifiers are outside the scope of the present document.
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 SIP (or SIPS) URIs of the form sip:[e-mail], where "example.com" 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 [i.4]. For the purposes of the present 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 the present document.
When a SIP URI is used as an AoR, in 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 [i.17]) or a private number (in accordance
with a private numbering plan [i.1]).
EXAMPLE:
- sip: [e-mail];user=phone
- sip:1234;phone-context=[e-mail];user=phone
- sip:1234;phone-context=[e-mail];user=phone
The first example is a fully qualified E.164 number. The remaining examples represent private numbers.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 102 634 V1.1.1 (2008-11)
In these examples the user part is formatted as what is defined as a telephone-subscriber string in RFC 3966 [i.11] for
use in a TEL URI, and is in fact fully qualified (globally 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. The present document strongly endorses that recommendation.
REQUIREMENT E1: Enterprises shall include the user=phone parameter in SIP URIs in which the user part is
a telephone-subscriber string.
The present document 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:[e-mail];user=phone
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 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,
which 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:[e-mail]
The user part in this example, whilst it is not marked as being a telephone number, very often is a telephone number.
URIs formatted in this way should be treated as email style identifiers, since they rely on the domain part to make them
globally unique.
The advantage of a number-based SIP URI is that the number can be used in legacy networks to reach the enterprise
user or to identify the enterprise user as a caller. ECMA TR/86 [i.2] discusses this matter extensively for interworking
between SIP and QSIG. The same advantage applies when an enterprise network interworks with other networks using
SIP (public networks or other enterprise networks) if those networks might in turn interwork with legacy networks.
Other forms of user part (referred to here as email style) have limitations when it comes to interworking. However,
forms that reflect the name of the user have obvious attractions from a usability perspective.
EXAMPLE:
- sip:[e-mail]
Internally an enterprise network can use email-style SIP URIs (i.e. URIs that do not contain a telephone number), but
may need to map to telephone number forms for inter-domain use or when interworking with legacy networks.
To be reachable directly from the public telephone network (PSTN/ISDN) a user must be identifiable by an E.164
number. Users not identifiable by an E.164 number are still reachable internally by means of a private number or other
form of SIP URI, and can be reached indirectly from the public telephone network (e.g. via an attendant). Such users
may also be directly reachable from other SIP networks where the caller is able to enter a SIP URI. In some countries
the availability of E.164 numbers is such that it is impracticable or too costly to assign one per user.
Often within an enterprise all SIP URIs identifying users will have the same value in the domain part (i.e. example.com
in the examples above). This allows identifiers to be portable within the enterprise (e.g. between different departments
or between different geographic locations). Some enterprises will use sub-domains of their top level domain
(e.g. domain1.example.com and domain2.example.com) in SIP URIs, or even different top level domains, particularly
as a result of a merger or the desire to promote different brand names.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 102 634 V1.1.1 (2008-11)
Where a user is identified by a telephone number, this can also be expressed by means of a TEL URI, RFC 3966 [i.11]
containing the telephone number formatted as a telephone-subscriber string
EXAMPLE:
- tel: [phone]
- tel:1234;phone-context=+411234
- tel:1234;phone-context=switzerland.example.com
However, for some purposes within a SIP environment SIP (or SIPS) URIs must be used, so a TEL URI can only be an
alias for a SIP URI.
Although a TEL URI can be derived from a SIP URI that has the user=phone parameter, certain information is lost in
the process, in particular the domain part and any parameters of the SIP URI other than user=phone (e.g. the
gr parameter - see clause 7.4). Any attempt then to convert the resulting TEL URI back to a SIP URI will not
necessarily result in the same domain part and may lack important parameters.
All SIP and TEL URIs are globally unique. This is achieved through the domain part of the SIP URI and/or (except
where a fully qualified E.164 number is given) the context parameter of a telephone-subscriber string in a number-based
SIP URI or a TEL URI.
Since SIP (or SIPS) and TEL URIs are fully qualified and hence globally unique, in principle any form can be applied
to inter-domain working. However, there are some additional considerations.
There may be a desire not to disclose private numbering plans or other email-style identification schemes outside the
enterprise network. Furthermore, other domains might be restricted in the forms they can handle, and in particular might
only support E.164 numbers when they provide interworking with legacy networks. Therefore, even where non-E.164
forms of identifier are used within an enterprise, there might be a need to publish E.164 aliases for use outside the
enterprise. Where a particular user is
...