ETSI TR 101 326 V2.0.0 (2002-02)
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); The procedure for determining IP addresses for routeing packets on interconnected IP networks that support public telephony
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); The procedure for determining IP addresses for routeing packets on interconnected IP networks that support public telephony
RTR/TIPHON-04006 [2]
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON) - Postopki za določanje naslovov IP za usmerjanje paketov po medsebojno povezanih omrežjih IP za podporo javne telefonije
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-april-2004
+DUPRQL]DFLMDWHOHNRPXQLNDFLMLQLQWHUQHWQHJDSURWRNRODSUHNRPUHåLM7,3+21
3RVWRSNL]DGRORþDQMHQDVORYRY,3]DXVPHUMDQMHSDNHWRYSRPHGVHERMQR
SRYH]DQLKRPUHåMLK,3]DSRGSRURMDYQHWHOHIRQLMH
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); The
procedure for determining IP addresses for routeing packets on interconnected IP
networks that support public telephony
Ta slovenski standard je istoveten z: TR 101 326 Version 2.0.0
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
Technical Report
Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON);
The procedure for determining IP addresses for
routeing packets on interconnected IP networks
that support public telephony
2 ETSI TR 101 326 V2.0.0 (2002-02)
Reference
RTR/TIPHON-04006 [2]
Keywords
architecture, functional, internet
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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, send your comment to:
editor@etsi.fr
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 2001.
All rights reserved.
ETSI
3 ETSI TR 101 326 V2.0.0 (2002-02)
Contents
Intellectual Property Rights.4
Foreword.4
Introduction .4
1 Scope.5
2 References.5
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations.8
4 The choice of naming system.8
4.1 Introduction to naming and addressing .8
4.1.1 Naming.8
4.1.2 Addressing.9
4.1.3 IP addresses.9
4.2 Naming schemes.11
4.2.1 E.164.12
4.2.2 Internet "names".12
4.2.3 Coding of names .12
4.3 The relationship of naming to services.13
4.4 The choice of naming for Tiphon.14
4.5 The relationship of the present document to ENUM.15
4.6 The use of aliases .18
4.7 Master IDs and personal numbering.18
4.8 Relationship to back end services.18
5 Types of resolution and their order .19
5.1 Introduction.19
5.2 Search resolution.21
5.3 Service resolution.21
5.4 Routing resolution.22
6 Routing in SCNs.22
6.1 Introduction.22
6.2 Routeing numbers.22
7 Resolutions in Tiphon Release 3 networks at the meta-protocol level.23
8 Other issues.24
8.1 Firewalls.24
8.2 NATs.25
9 Application to SIP and H.323.25
9.1 Application to SIP.25
9.2 Application to H.323.26
Annex A: Overview of SIP .28
Annex B: Overview of H.323.30
History .31
ETSI
4 ETSI TR 101 326 V2.0.0 (2002-02)
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 ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
Introduction
The present document explains the procedures for routeing of public telephony calls to an IP network. Starting point are
the existing requirements in TS 101 324 [2] on numbering, and the numbering options for users on IP terminals as
identified in TR 101 327 [3]. Additional general requirements for E.164/IP resolution are identified. These requirements
may form the basis for a service capability description for call routeing.
The present document is based on the architecture developed in Tiphon WG2.
ETSI
5 ETSI TR 101 326 V2.0.0 (2002-02)
1 Scope
The present document provides a collection of information and guidance relating to:
- the choice of naming schemes;
- the relationship of names to services;
- the role of the proposed ENUM system; and
- the resolution of names in the process of routing
for the routing of public telephone calls (i.e. calls where the called party is identified by an E.164 number) to a
terminating IP network or an IP network that supports a gateway back to an SCN. The calls may originate from or
transit public IP based or SCN based networks.
NOTE: This is intended to be approximately equivalent to the public telephone service defined in
ITU-T Recommendation E.105.
The present document is applicable to all networks that support the public telephony service and is therefore written on
the basis that the E.164 numbering scheme is used for calling and called party identification. Nevertheless the
underlying principles could also be applied with minor adaptation to private network numbering schemes.
The present document applies to calls to most types of number structures within E.164 [13], and includes the support of
carrier selection and number portability. It does not specifically address the support of mobility or roaming, although it
would apply to the routeing of a call to the home mobile network.
The types of IP network considered include but are not limited to TIPHON Release 3. Because the routing aspects of
the present document focus mainly on routing between networks for the support of a common service (public
telephony), the report has a different emphasis from the main emphasis of TIPHON Release 3, which is focused on the
provision of customized services to the customers of a single service provider.
The present document covers only the routeing between networks. It does not include the routeing inside a terminating
network.
2 References
For the purposes of this Technical Report (TR), the following references apply:
[1] ETSI TS 101 314: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Network architecture and reference configurations; TIPHON Release 2".
[2] ETSI TS 101 324: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Numbering; Scenarios 1, 2, 3 and 4".
[3] ETSI TR 101 327: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Guide to numbering options for public networks based on VoIP technology".
[4] ETSI TR 101 287: "Services and Protocols for Advanced Networks (SPAN); Terms and
Definitions".
[5] ETSI TR 102 081: "Network Aspects (NA); Number Portability Task Force (NPTF); Signalling
requirements to support number portability".
[6] ETSI TR 101 697: "Number Portability Task Force (NPTF); Guidance on choice of network
solutions for service provider portability for geographic and non-geographic numbers".
[7] ETSI TR 101 119: "Network Aspects (NA); High level description of number portability".
[8] ETSI TR 101 118: "Network Aspects (NA); High Level Network Architecture and Solutions to
support Number Portability".
ETSI
6 ETSI TR 101 326 V2.0.0 (2002-02)
[9] ETSI TR 101 122: "Network Aspects (NA); Numbering and addressing for Number Portability".
[10] ETSI EG 201 367: "Intelligent Network (IN); Number Portability Task Force (NPTF); IN and
Intelligence Support for Service Provider Number Portability".
[11] ITU-T Recommendation H.225.0: "Call signalling protocols and media stream packetization for
packet-based multimedia communication systems".
NOTE: See annex G: "Communication between Administrative Domains".
[12] ITU-T Recommendation Q.769.1: "Signalling system No. 7 - ISDN user part enhancements for the
support of number portability".
[13] ITU-T Recommendation E.164: "The international public telecommunication numbering plan".
[14] ITU-T Recommendation E.105: "International Telephone Service".
[15] ISO 3166: "Codes for the representation of names of countries and their subdivisions".
[16] ITU-T Recommendation E.191: "B-ISDN addressing".
[17] ETSI ETR 316: "Broadband Integrated Services Digital Network (B-ISDN); Numbering and
addressing in B-ISDN".
[18] IETF RFC 2543: "SIP: Session Initiation Protocol".
[19] IETF RFC 2131: "Dynamic Host Configuration Protocol".
[20] IETF RFC 1715: "The H Ratio for Address Assignment Efficiency".
[21] IETF RFC 1035: "Domain names - implementation and specification".
[22] ITU-T Recommendation H.323: "Framework and wire-protocol for multiplexed call signalling
transport".
[23] ITU-T Recommendation H.248: "Gateway control protocol".
[24] IETF RFC 2871: "A Framework for Telephony Routing over IP".
[25] IETF RFC 2327: "SDP: Session Description Protocol".
[26] ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call
control".
[27] ETSI TS 101 878: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Service Capability Definition; Service Capabilities for a simple call".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
address: string or combination of digits and symbols which identifies the specific termination points of a
connection/session and is used for routeing
called number: normally, name written as a numerical string identifying the called party or called terminal
ETSI
7 ETSI TR 101 326 V2.0.0 (2002-02)
contact ID: intermediate identifier for the destination of the next point of resolution, i.e. the destination of the next hop
for the signalling messages
NOTE: The form of the Contact ID may vary and may or may not depend on the protocol and the technology
used in the transport plane.
destination network: network to which a call is currently being routed
NOTE: For service resolutions that take place before the home network is reached, the destination network is the
home network. For service resolutions performed by the home network (e.g. call forwarding or the
support of roaming) this is the visited network.
E.164 number: number conforming to the numbering plan and structure specified in ITU-T Recommendation E.164
NOTE: See ITU-T Recommendation E.164 [13].
ENUM: telephone number mapping
NOTE: IETF working group.
home network name: network on which the customer's service application is provided whether by the network
operator or a separate service provider, e.g. the network on which the customer has a subscription
NOTE: This is in most cases the network through which the customer is assigned its E.164 number.
internet named telephony: service that supports conversational voice and uses Internet names for the identification of
the called party
name: combination of alpha, numeric or symbols that is used to identify end-users
NOTE: A name may be portable between Service Providers.
public telephony: service that conforms to ITU-T Recommendation E.105, i.e. it supports conversational voice and
uses E.164 numbers for the identification of the called party
NOTE: From the perspective of the present document, the only point of significance is the use of E.164 numbers.
The issue of whether any quality requirements should be applied to public telephony or whether E.164
numbers should be allocated only to services that achieve a certain threshold of quality is outside the
scope of the present document. See ITU-T Recommendation E.105 [14].
Routeing Number (RN): within TIPHON, specific number that is used by the networks to route the call
NOTE: The Routeing Number conveys information in a form more readily usable by the network (e.g. to route
calls to a ported number).
routeing: set of instructions on how to reach a destination
Second Level Domain name (SLD): part of the names in the DNS below the TLD
NOTE: Under the country code TLDs, there is a wide variation in the structure, in some countries the structure is
very flat, in others there is substantial structural organization. In some country domains the second levels
are generic categories (such as, AC, CO, GO, and RE), in others they are based on political geography,
and in still others, organization names are listed directly under the country code.
Top Level Domain name (TLD): part of name structure in the Domain Name System (DNS) under the control of the
Internet Corporation for Assigned Names and Number (ICANN)
NOTE: In the DNS naming of hosts (computers) there is a hierarchy of names. The root of system is unnamed.
Below the root, there is a set of what are called "top-level domain names" (TLDs). They include the
generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT and new ones that are under creation), and
the two letter country codes such as .UK, .DE and .JP from ISO-3166 [15].
transit network: network between two networks, e.g. between the originating network and the terminating network
NOTE: A transit network is not always present in a call, but in some calls there may be more than one transit
network present.
ETSI
8 ETSI TR 101 326 V2.0.0 (2002-02)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACK ACKnowledge
ALG Application Layer Gateway
CR Call Routing
DHCP Dynamic Host Configuration Protocol
DNS Domain Name Server
ICANN Internet Corporation for Assigned Names and Number
ID IDentifier
IETF Internet Engineering Task Force
IP Internet Protocol
ISDN Integrated Services Digital Network
ISP Internet Service Provider
ISUP ISDN User Part
ITU International Telecommunication Union
LAN Local Area Network
NAT Network Address Translators
NOA Nature Of Address
PSTN Public Switched Telephone Number
RN Routeing Number
RTP Real Time Protocol
SC Service Control
SCN Switched Circuit Network
SDP Session Description Protocol
SIP Session Initiation Protocol
SLD Second Level Domain
SMS Short Message Service
TCP Transmission Control Protocol
TLD Top Level Domain
TRIP Telephony Routing over IP Protocol
TSAP Transport layer Service Access Point
UAC User Agent Client
UAS User Agent Server
UCI Universal Communications Identifier
UDP User Datagram Protocol
UPT Universal Personal Telephony
URL Uniform Resource Locator
VoIP Voice over the Internet Protocol
4 The choice of naming system
4.1 Introduction to naming and addressing
4.1.1 Naming
A name is a "combination of characters and is used to identify end users (character may include numbers, letters and
symbols)".
NOTE: According to ITU-T Recommendation E.191 [16].
An end user is "a logical concept which may refer to a person, a persona (e.g. work, home etc.), a piece of equipment
(e.g. NTE, phone etc.), an interface, a service (e.g. freephone), an application (e.g. video on demand), or a location".
ETSI
9 ETSI TR 101 326 V2.0.0 (2002-02)
A name is distinct in function from an address, which " identifies the specific termination points of a connection and is
used for routeing". Addresses are essential for communication as the end points always have to be identified in a way
that can be used for routing, but names are not essential. Names are added for some services to make it easier for users
to identify the distant end-point or to provide an identification system that is independent of the structure of the
networks or the current location of the entity to be communicated with.
4.1.2 Addressing
An address is defined as "a string or combination of digits and symbols that identifies the specific termination points of
a connection and is used for routeing". An address is a specification of the location of the entity in terms of network
structure. It includes information about the location within the network and may also include the identity of the network
itself and its location in the topology of interconnected networks. An address identifies the interface at which the
connection is to be delivered without regard to whether the connection continues beyond that interface. It contains
location information and in telecommunications this is expressed in terms of the network structure in order to achieve as
high as possible a degree of aggregation that reduces the complexity of routing tables in switches or routers.
NOTE 1: According to ETR 316 [17].
Addresses differ from names in that addresses contain explicit network information and this information is what makes
them usable for routing. In order to route a call or a packet, the called name must be translated into an address that
identifies the location in network terms and so can be used in the routing process. When a name is ported from one
location or one service provider to another, the address associated with the name changes.
Unfortunately the distinction between name and address is not followed consistently and entities that are names, or
closer to names than addresses, are often spoken of as addresses. A Uniform Resource Locator (URL) pointing to a
company's web page is often called an Internet address, but is actually based on a domain name.
NOTE 2: Often the word "address" is used to mean "containing location information" but this is not sufficient for
the purposes of the distinction between names and address in telecommunications. Here the critical issue
is whether the location information is specified in terms of network structure. For example, An E.164
number may contain location information if numbering is related to geographical areas, but such a
number may be a name rather than an address if the structure that provides the location information does
not relate explicitly to network structure. This would be the case for example if there is number
portability between competing networks.
NOTE 3: Where a communications system is structured in terms of layers with each layer offering a service to the
layer immediately above and using the services of the layer immediately below, the identities offered to
the layers tend to have the properties of names. Yet when viewed from the layer above, the same
identifiers have the properties of addresses. This difference in perspective may explain why the term
"address" is used for email and SIP (see IETF RFC 2543, [18]) identifiers e.g. "email address" and SIP
"address".
4.1.3 IP addresses
IP addresses are allocated to interfaces, but different communication streams using different protocols may share the
same interface. These streams are differentiated using port numbers which are carried in the protocol (e.g. TCP, UDP or
RTP) that runs on top of IP. The combination of an IP address and a port number uniquely identifies the source or
destination of a stream of packets flowing between two end points. Each application protocol has a "well known" fixed
port number assigned to it plus a range of port numbers for dynamic assignment to communication streams.
IP addresses are divided, in principle, into two parts:
- the identity of the network (the network part);
- the identity of the interface attached to the network (the host address, which is the destination of the IP packet).
IP address allocations are normally made through ISPs to end networks. The allocations to ISPs are made in blocks and
are organized as far as practicable to be aggregatable so that traffic on a particular route is likely to have addresses in
contiguous blocks. This is important to reduce the size of the routeing tables in routers where several contiguous blocks
that share the same route require only one entry. The size of these routeing tables is a potential bottleneck in the growth
of the Internet as router technology is only just keeping ahead of the traffic growth.
ETSI
10 ETSI TR 101 326 V2.0.0 (2002-02)
ISPs normally allocate blocks of addresses to end networks. Where the end networks have permanently connected
terminals e.g. PCs connected to a LAN, the addresses may be allocated permanently to the terminals.
Conversely where terminals are likely to be disconnected frequently and where dial-up access is used, IP addresses are
normally allocated dynamically, e.g. using the Dynamic Host Configuration Protocol (DHCP) (see RFC 2131 [19]).
Addresses are allocated from a pool only while the customer is logged-on. After logging-off the same address will be
allocated to another user.
There are two versions of IP protocols, whose address formats differ significantly:
- IPv4, a 32-bit address, which is used throughout the Internet but which is considered to be in increasingly short
supply and whose allocations are being controlled carefully.
- IPv6, a 128-bit address, which is just starting to be used and should provide more than adequate capacity for the
future if it is administered effectively.
IPv4 is the version of the IP protocol in general use. Use of IPv6 is only just beginning. Because the address lengths are
different, the two addresses are not compatible and a long process of migration is beginning.
There are two main drivers for moving to IPv6:
- Avoiding problems when IPv4 addresses reach exhaustion.
- Obtaining benefits from features that IPv6 offers that are not available in IPv4.
There is however a disadvantage. The IPv4 header has a variable length with the minimum being 192 bits. The IPv6
header has a fixed length of 320 bits, with the possibility of additional extension headers that are normally used only by
the end nodes. The fixed header length simplifies the packet handling in routers but the increased length reduces the
efficiency of transmission unless header compression is applied.
UDP has a 64 bit header and TCP a 224 bit header. Therefore the maximum reduction in efficiency is 33 %
(100 x (1 - ((192 + 64) / (320 + 64)))) for a zero length packet. However for speech for a 4 kbit/s speech codec with a
packetization delay of 40 ms the speech packet would have a length of 4 000 x 0,04 = 160 bits and the efficiency
reduction would be 24 %. For data using TCP the minimum reduction for a zero length packet would be 21 %. Thus the
reduction in efficiency is greater for speech than data.
A significant uncertainty is the speed with which IPv6 will be introduced generally in the Internet world. Here there are
two extremes and a continuum of possibilities between them.
- The first extreme is that ISPs will perceive some real operational advantage in using IPv6 and will introduce it as
soon as possible in order to capitalize on these advantages.
- The other extreme is that ISPs will regard the introduction of IPv6 as an avoidable expense and will delay its
introduction as long as possible, i.e. until the shortage in IPv4 addresses begins to be felt.
Although IPv4 has a theoretical capacity of some 4 billion (4 x 10 ) addresses, in practice a realistic maximum is
probably some 200 million hosts. The lower practical limit is the result of the structuring of the address space and is a
prediction based on observations of the points at which other numbering schemes reach saturation (see RFC 1715 [20]
by Christian Huitema).
It is very difficult to obtain a well founded estimate of the current world-wide situation on allocations or when the
effects of exhaustion will first be experienced. According to a paper on the IANA part of the web site (see
http://www.iana.org/assignments/ipv4-address-space) of the Information Sciences Institute, there were in October 2000
some 102 unallocated/8 IP addresses out of the maximum total of 256. There were 23 allocations to the Regional
Internet Registries who currently handle the allocations to ISPs and large users. The demand for allocations from these
RIRs is doubling every year according to RIPE, suggesting that a further 2-3 years' growth can be accommodated
without making other changes. However the remaining 131 values are allocated to organizations and large corporate
and eventually some of this space could be released if necessary.
ETSI
11 ETSI TR 101 326 V2.0.0 (2002-02)
There are many "variables" that make estimation of the remaining life of IPv4 difficult to quantify including:
- the use of Network Address Translators to increase the utilization of IPv4 address space,
- WAP proxy server deployment (similar to NATs in terms of saving IP address space),
- the impact of dynamic address assignment in an "always on" environment,
- the possible impact of Windows 2000™ which includes IPSec and may lead to an increase demand for secure
end to end communication, (currently the use of NAT inhibits end to end IPSec),
- new demands from the "plug and play" (auto configuration) market.
In conclusion it does appear likely that some effects of IPv4 address exhaustion will begin to be felt in the 2004-2006
timeframe.
During the migration period, various techniques including dual stack will be used to provide interworking between IPv4
and IPv6. Some of these techniques require interworking equipment that itself needs IPv4 addresses. When eventually
IPv4 becomes seriously exhausted, new allocations will be possible only from IPv6. This will mean that equipment with
only IPv6 addresses will be able to communicate only with other equipment that have IPv6 addresses and therefore
communications with the unmodified IPv4 world will not be possible. This will be a significant commercial issue and
therefore there is a body of opinion that the introduction of IPv6 should be encouraged in order that it can become as
widespread as possible before IPv4 exhausts so that the loss of compatibility will be minimized.
The TIPHON standards do not specify the choice of version of IP protocol and are compatible with either version
because the TIPHON standards generally apply above the network layer. Thus the choice of Internet Protocol version
and any interworking between versions is outside the scope of TIPHON.
4.2 Naming schemes
There are two common naming schemes:
- E.164 names (numerical strings) defined by ITU-T Recommendation E.164 [13]. This scheme is a mixture of
names and addresses. It started primarily as an addressing system but has migrated to become more of a naming
system because location and operator portability are functions of names rather than addresses.
- Internet names of the form "user@domain" defined by RFC 1035 [21].
NOTE: The prefixes "http:", "sip:" etc denote the protocol and are not parts of the domain name.
The choice of identification scheme is related to the nature of the service because a service description needs to specify
which type of name is used. This is important because:
- users need to know how to identify their correspondents;
- the choice of identification system determines the set of potential correspondents that can be reached;
- interconnected networks need to have a common method of identifying communicating users.
For many services, names are used as the identification system, but some services allow addresses to be used as an
alternative to names (e.g. http allows users to identify web sites by IP addresses or domain names), and some services
use only addresses.
In the past services and hence name types were related to technology. For example telephony could be provided only on
circuit switched technology and Telex had its own naming scheme and own technology. However, third generation
mobile technology is designed to support multiple services and there is therefore the possibility of supporting more than
one type of name. For Tiphon Release 3 compliant systems, only E.164 names and related national numbers
(e.g. 0800, 112) are supported.
ETSI
12 ETSI TR 101 326 V2.0.0 (2002-02)
4.2.1 E.164
The international public telecommunication numbering plan is defined in ITU-T recommendation E.164 [13], and
numbers which comply with it are referred to as E.164 numbers. It includes PSTN, ISDN and mobile networks and
supports various services including public telephony, some special telephony services such as international freephone,
fax, some data services and the GSM Short Message Service (SMS). According to the ITU-T recommendations, some
telephony services such as national freephone in a strict sense do not use E.164 numbers although their numbering is
compatible with E.164 and thought by most people to be E.164 numbers. The E.164 number is not necessarily identical
to the dialled number as dialling prefixes and arrangements for local dialling are not part of
ITU-T Recommendation E.164 [13].
For various historical reasons, E.164 numbers are a mixture of names and addresses, but the trend is to reduce the
degree of address information and make them more names than addresses (i.e. to reduce the network specific
information). Various parts of E.164 [13] include structures related for example to geography. This structure may in the
past have been related precisely to network architecture but the relationship to network architecture has reduced or been
removed for example by operator and location portability.
For routeing in switched circuit networks (i.e. when network information is needed), routeing numbers are used to add
at least some location information. A routeing number may be:
- a separate E.164 number or E.164-like number (i.e. a number similar in format to E.164 numbers and compatible
with the E.164 [13] plan but not formally part of the plan) that contains the necessary network information;
- a non-E.164 number that contains the necessary routeing information;
- or a routeing prefix added to the front of the E.164 number.
4.2.2 Internet "names"
Within IP based networks, there are separate naming and addressing schemes. Names normally have the form:
User@domain
IP addresses are completely separate binary strings and there are different forms depending on whether IPv4 or IPv6 is
being used.
Table 1 shows some examples of the relationship between names and addresses for telephony and current web
applications. It includes the differences between the Tiphon and Internet telephony.
Table 1: Examples of names and addresses
Telephony on switched Email Tiphon Release 3 Internet telephony
circuit network solution for
telephony on IP
Name E.164 number user@domain E.164 number user@domain,
where domain may possibly with an E.164
be a host name alias for incoming calls
from the switched
circuit networks
Address Routeing E.164 number, IP address IP address IP address
or (routeing prefix +E.164
number)
(see note)
NOTE: There is also additional lower level addressing information in equipment numbers.
4.2.3 Coding of names
Table 1 refers to the naming scheme used, i.e. allocated to the users of a service, and not to the carriage of the names by
a signalling protocol which would depend on the specification for the protocol. For example, an E.164 name could be
coded in the form of @domain.
ETSI
13 ETSI TR 101 326 V2.0.0 (2002-02)
4.3 The relationship of naming to services
Normally each service that uses names specifies a single type of name that is used. However a type of name may be
used by several different services. Sometimes these services are distinguished by different ranges as is the case of
ITU-T Recommendation E.164 [13]. Where there is a separate method to identify different services, the same value of a
name of the same type may be used for different services. For example a given E.164 number may be shared for both
telephony and fax if the terminal can distinguish the services; equally under Internet naming the same value of
user@domain may be used for both email and various SIP (see RFC 2543 [18]) based services.
A user may therefore have several names for different services, e.g. GSM users have three different E.164 names for
voice fax and data services on GSM. This is not very user friendly because business cards become cluttered up with the
different names. A reasonable long term objective could be to work towards having one name per person for private use
and perhaps a separate name for business use, however this goal is constrained by the need for compatibility with
existing systems. Work within ETSI on the Universal Communications Identifier (UCI) is considering these
possibilities.
Figure 1 shows an example of the relationship of named entities to name types and values for different services.
Services Telephony Fax Mobile/SMS Email Other services
Service specific
Multi- service
Name
value
Name
E.164 ITU User@domain ICANN
type
ICANN = Internet Corporation for
Assigned Names and Numbers
Named Person/
entity Terminal
Figure 1: Naming relationships from a caller's perspective
A single name can also support several different users. Examples are an E.164 name for a telephone service in a house
shared by several occupants, or an E.164 name used by a call centre, or an email name used by several people who fulfil
the same function in an organizations (e.g. sales@company.com).
Although one name of the form "user@domain" may be used for several services, a given name may be used only for
services supported on a single host because the name will be mapped by DNS to an IP address of an interface on the
host. In most cases the host is operated or connected to a single service provider. Therefore a user that wishes to use one
service provider for one set of services and another for another set will need different names.
The IETF has distinguished names and addresses and introduced the public DNS to support the resolution of names into
addresses, however the IETF does not define services or service capabilities in the way that ETSI and ITU-T do,
because it assumes that users assemble their own services using application protocols. In other words, services are
created at the edge of networks and are not embedded in them. This means that there is a lack of clarity in relating
services defined in ITU-T/ETSI to work in IETF. This lack of clarity in turn leads to some confusion over the choice of
naming schemes for voice in IETF. From the perspective of ETSI, voice communications that use Internet names (e.g.
what the press calls PC-PC communications) are a different service from public telephony, we call this "Internet named
telephony". Internet named telephony will require interworking with the public telephony service and this interworking
will have to enable callers on the public telephony service to identify called parties on the Internet telephony service.
This is service interworking and there are two alternative methods of handling its numbering:
- to allocate hitherto unused E.164 numbers for this interworking (each customer of Internet telephony who
requires interworking would need to be allocated an E.164 number to use in parallel with their existing Internet
name);
- to use a database of associations between E.164 numbers already allocated for the public telephony service and
the Internet name used for Internet telephony (this is ENUM).
ETSI
14 ETSI TR 101 326 V2.0.0 (2002-02)
Figure 2 shows the differences between the approaches of Tiphon and the IETF.
The aim of Tiphon is to support the existing public telephony services, which use different parts of E.164, on IP
technology. This technology could include Internet at the transport layer but does not necessarily do so.
In contrast, the IETF is supporting a different "service" with interworking using ENUM as a method to translate E.164
numbers to Internet names. More information about ENUM is given in a later clause.
Common service model Different services model
New features
PPuubliblicc t teelelepphonyhony s seervrviciceess Public telephony Internet telephony
ENUM
E.E.161644 E.164 User@domain
Switched IP Switched
circuit Networks circuit
Internet
networks including
networks
Internet
Area worked Area worked
on by Tiphon on by IETF
Service interworking
Involves E.164 numbers either
- by association (ENUM), or
- by allocation in parallel with Internet names
Figure 2: The different approaches to telephony
There are several different forms of public telephony service that use different ranges of numbers within
ITU-T Recommendation E.164 [13]. For example in addition to the basic geographic telephony service there are mobile
services, freephone, shared cost and premium rate services. These different forms are shown by the stacked boxes in the
diagram.
NOTE: The issue of whether any quality requirements should be applied to public telephony or whether E.164
numbers should be allocated only to services that achieve a certain threshold of quality is outside the
scope of the present document.
4.4 The choice of naming for Tiphon
Tiphon is aiming to produce standards that meet the needs primarily of new and old "telcos" who wish to offer new
services on IP-based technology or migrate existing services from circuit switched technology to IP-based technology.
(The commercial framework for TIPHON is assumed to be networks where service providers create and control
services a
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...