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)

Technical Report
Coporate Networks (NGCN)
Next Generation Corporate Networks (NGCN) -
Identification and Routing
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
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
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
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
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
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
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
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
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
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 not assigned an E.164 number (because of shortage or cost), an alternative E.164
number (e.g. that of an attendant) might need to be published for reaching that user from outside the enterprise.
Figure 1 illustrates the relationships between different forms of SIP and TEL URIs.
Identity (represented by SIP/SIPS/TEL URI)
Telephone number
Other
Private number
(not as telephone-
subscriber string)
Private number
E.164 number (as telephone-subscriber Email-style
string)
SIP/SIPS URI, e.g: SIP/SIPS URI, e.g:
sip:6789;phone-context=+12345 sip:[e-mail]
SIP/SIPS URI, e.g:
sip:[e-mail] @example.com sip:[e-mail]
TEL URI, e.g:
TEL URI, e.g:
tel:[phone]
tel:6789;phone-context=+12345
Figure 1: Relationships between different forms of SIP and TEL URIs
ETSI
12 ETSI TR 102 634 V1.1.1 (2008-11)
Additional considerations apply to each of the three basic forms of identifier (shown in red in figure 1): E.164 numbers,
private numbers formatted as telephone-subscriber strings and email-style identifiers. A given user may have multiple
identifiers as aliases.
When part or all of an enterprise network is hosted, the hosting infrastructure will need to support all types of SIP and
TEL URI discussed above. In particular, an NGN that hosts enterprise functions will need to support these different
types, at least for private network traffic.
REQUIREMENT N1: An NGN or other public network hosting enterprise functions shall support the different
types of user identifier described above, at least for private network traffic.
7.1.1 Use of E.164 numbers
When a user has a fully qualified E.164 number (international number) as identifier, it can be used universally,
including within the PSTN. The E.164 number can always be used for establishing a communication to the user
concerned and (subject to authentication) is always meaningful if delivered as the identification of a user involved in a
communication. It can be stored in directories or in call detail records. However, as discussed earlier in clause 7.1, there
may be some users who are not assigned E.164 numbers.
NOTE: National and subscriber E.164 numbers are not fully qualified and can be represented in SIP and TEL
URIs by inclusion of a phone-context parameter. Such numbers are not seen as meaningful for use within
enterprise networks.
When an E.164 number is represented as a SIP URI, a domain part is included. In common with any other SIP URI,
normally this will be the domain that provides home server (registrar and proxy) functionality for that identifier, in other
words the home domain. That home domain's name must be used in the To URI of a SIP REGISTER request when
registering a User Agent (UA) as a contact for an E.164 number, and inbound requests to an E.164 number must be
routed to the home server within that home domain. Thus for a given E.164 number there must be a SIP URI that uses
the home domain's name. We can call this the home number-based SIP URI for that E.164 number. For an E.164
number assigned by an appropriate authority to an enterprise (and assigned by that enterprise to a user of the enterprise
network), normally the domain part of the home number-based SIP URI will be that of the enterprise, or a sub-domain
thereof.
There is no clear definition of what the domain part of a SIP URI representing an E.164 number should contain. One
possibility might be to use the domain that "owns" the E.164 number, but the concept of ownership is unclear. Does an
enterprise domain "own" the E.164 numbers assigned to it? Does a public network "own" the E.164 numbers assigned
to an enterprise? What if the enterprise obtains services associated with these numbers from multiple public networks or
moves from one public network to another?
In practice, since a fully qualified E.164 number is globally unique anyway, in many circumstances values other than
the home domain are placed in the domain part, e.g. the domain of a public network through which a communication
needs to be routed to reach the domain to which the number is assigned, or a domain through which a communication
has been routed. The domain denoted by the domain part should at least be able to route the request onwards towards
the destination. Therefore if a SIP URI containing an E.164 number is the target of a SIP request, the request can be
routed to the domain given in the domain part and that domain will be able to route the request onwards, in this case to
the enterprise domain concerned. Compared with the home number-based SIP URI for a given telephone number, SIP
URI's for the same E.164 number but with different domain parts are merely aliases for that home number-based SIP
URI. In practice, such aliases are often used, although perhaps not the original intent of RFC 3261. In the present
document these aliases are called transient number-based SIP URIs, because often their use is of a transient nature
during routing.
The choice of domain part for a home number-based SIP URI for an E.164 number merits consideration. For a home
server in a dedicated NGCN (supported by the enterprise's own infrastructure) it is fairly clear that the home
number-based SIP URI should use the enterprise's own domain name (or a sub-domain thereof). If the NGCN uses
services of an NGN for external communications, a potential alternative might be to use the NGN's domain name, but
this would lead to a number of problems, e.g.:
• Placing the NGN's domain name in the Request-URI of a SIP REGISTER request (e.g. REGISTER
sip:ngn.com) would, according to normal SIP routing rules, cause the request to be routed to the NGN, rather
than to the home server in the NGCN. Special measures would need to be used in the NGCN to prevent that.
ETSI
13 ETSI TR 102 634 V1.1.1 (2008-11)
• A request originated in the NGCN to another NGCN user identified by a SIP URI using the NGN's domain
name would, according to normal SIP routing rules, cause the request to be routed to the NGN, which
presumably would then route it back to the home server in the NGCN. To prevent this undesirable behaviour,
special measures would need to be taken within the NGCN.
• The NGCN operator might require the user to be reachable from more than one NGN, in which case any
benefits of basing the home number-based SIP URI on the domain name of one of the NGNs would not apply
to the other NGNs.
• Identifiers would need to change if the NGCN operator were to change the NGN operator from which services
are obtained, i.e. identifiers would not be portable.
• This would be inconsistent with other identifiers (see clause 7.1.3), which are forced to use the domain name
of the enterprise.
REQUIREMENT N2: An NGN or other public network providing services based on SIP to an NGCN shall allow
use of the enterprise domain name in the domain part of SIP URIs containing E.164 numbers.
When hosting is used, it might be possible to use the hosting organisation's domain name (e.g. that of a hosting NGN or
NGCN) as the domain part of home number-based SIP URIs. This too has some significant drawbacks, e.g.:
• If an enterprise network is a mixture of dedicated NGCN and hosted domains, users in hosted domains would
have identifiers based on the hosting organisation's domain name and users in NGCN domains would have
identifiers based on the enterprise's domain name. This would prevent identifier portability in support of users
who change location or for other reasons need to change domain within the enterprise network.
• If different domains of an enterprise network are supported by different hosting networks, again identifier
portability would be lost.
• Identifiers would need to change if the enterprise changes the organisation from which it obtains hosting
services.
• This would be inconsistent with other identifiers (see clause 7.1.3), which are forced to use the domain name
of the enterprise.
REQUIREMENT N3: An NGN or other network that hosts enterprise users shall allow use of the enterprise
domain name in the domain part of SIP URIs containing E.164 numbers.
Notwithstanding the need to have a home number-based SIP URI, normally based on the enterprise's domain name,
practices within public networks tend to modify the domain part during routing and during the delivery of calling or
connected user identification. In other words, aliases in the form of transient number-based SIP URIs are used. This is
discussed further in the context of routing (see clause 8) and identification delivery (see clause 9). The use of transient
number-based SIP URIs has a number of consequences:
1) There is not a single unique SIP URI that represents a given E.164 number.
2) The rules in RFC 3261 for comparing SIP URIs do not consider SIP URIs with different domain parts as being
equivalent, although in practice these URIs are equivalent.
3) An endpoint that has stored in its address book an E.164 number represented as a SIP URI will be unable to
match received SIP URIs against that stored SIP URI according to normal RFC 3261 comparison rules unless
the two URIs happen to have the same domain part. This might interfere with functionality at the endpoint,
e.g. the ability to display a name and other details based on address book look-up, or the ability to check a
caller's identity against a black list or white list.
4) The domain part of a SIP URI containing an E.164 number, when received as the source of a SIP request, does
not necessarily represent the domain in which that SIP request originated and thus the domain of the remote
user in the communication.
ETSI
14 ETSI TR 102 634 V1.1.1 (2008-11)
Therefore when an E.164 number is represented as a SIP URI, it is only the user part that is meaningful to other users as
a means of identifying the user (although the domain part of a SIP URI will help in routing a request back to the
identified user and may be of use in determining where a request has come from). The number could equally well be
represented as a TEL URI, but TEL URIs are not suitable for all purposes:
1) They are unsuitable for including in a Request-URI and for routing in accordance with RFC 3263 [i.5].
2) They are unsuitable for signing in accordance with RFC 4474 [i.12] (see also clause 9.2).
3) They are unsuitable for use as contact URIs to identify particular endpoints.
Because of potential modification of the domain part of a SIP URI by SIP intermediaries, the domain part must be
considered unreliable as a means of determining the enterprise to which the user of an E.164 number belongs. This is
unfortunate, because a user receiving a SIP URI as the identity of a communication partner might not recognise the
E.164 number but might recognize the domain.
With these considerations in mind, it is impossible to avoid the use of SIP URIs representing E.164 numbers, but
because a given E.164 number does not have a unique domain part such URIs have to be treated with care. For some
purposes they can be treated as TEL URIs and the domain part ignored, but there are occasions when the domain part
can be useful. For example, when displaying the identity of a communication partner to a user, the domain part may on
occasions be of value.
It is recommended that transient number-based SIP URIs should be avoided or at least used with care in enterprise
networks.
REQUIREMENT E3: An enterprise shall avoid the use of transient number-based SIP URIs as aliases for home
number-based SIP URIs identifying enterprise users.
REQUIREMENT N4: An NGN that hosts enterprise network capabilities shall avoid the use of transient
number-based SIP URIs as aliases for home number-based SIP URIs identifying enterprise users.
When publishing identifiers for users, e.g. in directories, on business cards, on web pages, care needs to be taken. By
publishing only the telephone number or the home number-based SIP URI based on the enterprise's domain name,
problems can be avoided.
REQUIREMENT E4: When publishing user identifiers based on E.164 numbers, enterprises should publish only
the E.164 number (alone or as a TEL URI) and/or the home number-based SIP URI.
7.1.2 Private numbers formatted as telephone-subscriber strings
Even though such private numbers are fully qualified, in general they cannot be used outside the enterprise concerned.
Public NGNs may support them within the context of private network traffic (e.g. between hosted enterprise users
and/or between NGCN sites), but are not expected to support them for public network traffic. They are not supported in
PSTN. Generally they are supported within non-SIP domains of the enterprise network concerned
(e.g. circuit-switched). Compared with E.164 numbers, they have the benefit of brevity (insofar as users need remember
only the number if the phone-context is automatically appended) and any user in an enterprise network can be assigned
a private number, even though there may be a shortage of E.164 numbers.
Examples of private numbers formatted as telephone-subscriber strings are:
- sip:1234;phone-context=[e-mail];user=phone
- sip:1234;phone-context=[e-mail];user=phone
ETSI
15 ETSI TR 102 634 V1.1.1 (2008-11)
The first of these examples says that the number 1234 is to be interpreted within the context of the entity to which E.164
numbers beginning with 411234 are assigned. The second of these examples says that the number 1234 is to be
interpreted within the context of the domain switzerland.example.com. The combination of the number and the contents
of the phone-context parameter is globally unique.
NOTE: Where a numeric phone-context is used, appending the phone number to the phone-context does not
necessarily result in a valid international E.164 number. For example:
- sip:5555;phone-context=[e-mail];user=phone
- is not necessarily the same as:
- sip:[e-mail];user=phone
Private numbers here are considered the equivalent of Private Numbering Plan (PNP) Numbers as defined in
ECMA-155 [i.1] and therefore belong to a PNP, also defined in ECMA-155.
The considerations for the domain part of SIP URIs carrying E.164 numbers apply also to the domain part of SIP URIs
carrying private numbers formatted as telephone-subscriber strings. This includes the concepts of home and transient
number-based SIP URI. Essentially the domain part is used only for routing purposes, given the existence of the
phone-context parameter in the user part. Therefore it is possible to put any value in there (e.g. the domain of an NGN
providing services to an NGCN or hosting the enterprise network), provided the identified domain can rout
...