ISO/IEC TR 12861:2009

Information technology — Telecommunications and information exchange between systems — Next Generation Corporate Networks (NGCN) — Identification and routing

ISO/IEC TR 12861:2009 is one of a series of 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. ISO/IEC TR 12861:2009 discusses issues related to user identities and routing and builds upon concepts introduced in ISO/IEC TR 12860.

Technologies de l'information — Télécommunications et échange d'information entre systèmes — Réseaux d'entreprise de prochaine génération (NGCN) — Identification et routage

General Information

• Status: Published
• Publication Date: 02-Apr-2009
• ICS: 35.110 - Networking
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Current Stage: 9060 - Close of review
• Start Date: 02-Sep-2019
• Completion Date: 03-Sep-2019

Standards Content (Sample)

TECHNICAL ISO/IEC
REPORT TR
12861
First edition
2009-04-15


Information technology —
Telecommunications and information
exchange between systems — Next
Generation Corporate Networks
(NGCN) — Identification and routing
Technologies de l'information — Télécommunications et échange
d'information entre systèmes — Réseaux d'entreprise de prochaine
génération (NGCN) — Identification et routage




Reference number
ISO/IEC TR 12861:2009(E)
©
ISO/IEC 2009

---------------------- Page: 1 ----------------------
ISO/IEC TR 12861:2009(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


©  ISO/IEC 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO/IEC 2009 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC TR 12861:2009(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .2
3.1 External definitions .2
3.2 Other definitions.3
4 Abbreviated terms .3
5 Background.4
6 Identified entities .4
7 Types of identifier.5
7.1 SIP, SIPS and TEL URIs as user identifiers (AoRs) .5
7.1.1 Use of E.164 numbers.8
7.1.2 Private numbers formatted as telephone-subscriber strings.10
7.1.3 Email-style SIP URIs.11
7.2 Dial strings .12
7.3 Service identifiers.13
7.4 Device identifiers.13
8 Routing .14
8.1 General routing principles.14
8.2 Routing to the enterprise domain.15
8.3 Routing to the home server within the enterprise domain .15
8.4 Roaming considerations.16
9 Identification delivery and restriction .17
9.1 Identification delivery.17
9.2 Authenticity.17
9.3 Restriction.18
10 Summary of requirements and standardisation gaps .19
10.1 Requirements on NGNs .19
10.2 Requirements on enterprise networks.20
10.3 Standardisation gaps .20

© ISO/IEC 2009 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC TR 12861:2009(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 12861 was prepared by Ecma International (as ECMA TR/96) and was adopted, under a special
“fast-track procedure”, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with
its approval by national bodies of ISO and IEC.
iv © ISO/IEC 2009 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC TR 12861:2009(E)
Introduction
This 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
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. This particular Technical Report discusses issues related to user identities and routing and builds
upon concepts introduced in ISO/IEC TR 12860.
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 JTC 1, 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.

© ISO/IEC 2009 – All rights reserved v

---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC TR 12861:2009(E)

Information technology — Telecommunications and information
exchange between systems — Next Generation Corporate
Networks (NGCN) — Identification and routing
1 Scope
This 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 networks)
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 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.
This particular Technical Report discusses session level user identification and routing. It uses terminology
and concepts developed in ISO/IEC TR 12860. 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 a real-time element, including but not
limited to voice, video, real-time text and instant messaging.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
[1] ISO/IEC 11571:1998, Information technology — Telecommunications and information exchange
between systems — Private Integrated Services Networks — Addressing
[2] ECMA TR/86, Corporate Telecommunication Networks — User Identification in a SIP/QSIG
Environment
[3] ISO/IEC TR 12860:2009, Information technology — Telecommunications and information exchange
between systems — Next Generation 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 Protocol (SIP) for Asserted Identity
within Trusted Networks
© ISO/IEC 2009 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/IEC TR 12861:2009(E)
[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 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 Authenticated Identity Management in the Session Initiation
Protocol (SIP)
[13] IETF RFC 4916, Connected Identity 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 Routable User Agent (UA) URIs (GRUU)
in the Session Initiation Protocol (SIP)
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 longer available,
readers should look for the RFC with the same title.
[17] ITU-T Rec. E.164, The international public telecommunication numbering plan
[18] ITU-T Rec. H.350, Directory services architecture for multimedia conferencing
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1 External definitions
This Technical Report uses the following terms defined in ISO/IEC TR 12860:
• Domain
• Enterprise network
• Home server
• Next Generation Corporate Network (NGCN)
• Next Generation Network (NGN)
• Private network traffic
• Public network traffic
• Roaming
• Roaming hub
2 © ISO/IEC 2009 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC TR 12861:2009(E)
• SIP intermediary
This Technical Report uses the following terms defined in ISO/IEC 11571 [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.
3.2.4
Telephone number
A numeric identifier that conforms to the numbering plan of a circuit-switched network.
4 Abbreviated terms
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
PSTN Public Switched Telephone Network
SIP Session Initiation Protocol
© ISO/IEC 2009 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/IEC TR 12861:2009(E)
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 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 [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
this Technical Report, 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.
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).
4 © ISO/IEC 2009 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC TR 12861:2009(E)
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 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 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 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 [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 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: [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.
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 (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. This Technical Report 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.
This Technical Report refers to SIP URIs containing the user=phone parameter and a telephone-subscriber
string as number-based SIP URIs.
© ISO/IEC 2009 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/IEC TR 12861:2009(E)
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 [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, e.g.:
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.
Where a user is identified by a telephone number, this can also be expressed by means of a TEL URI, RFC
3966 [11] containing the telephone number formatted as a telephone-subscriber string, e.g.:
tel: [phone]
tel:1234;phone-context=+411234
tel:1234;phone-context=switzerland.example.com
6 © ISO/IEC 2009 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC TR 12861:2009(E)
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 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
Additional considerations apply to each of the three basic forms of identifier (shown in red in the Figure):
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.
© ISO/IEC 2009 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/IEC TR 12861:2009(E)

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 communicatio
...