dispatch R. Jesske
Internet-Draft Deutsche Telekom
Intended status: Informational July 30, 2012
Expires: January 31, 2013
Routing of Service Numbers with-in SIP (Session Initiation Protocol)
networks
draft-jesske-dispatch-servicenumber-routeing-01
Abstract
The combination of "rn" and "npdi" parameters which are normally used
for number portability (NP) can also solve numbering and routing
problems. Database dips to obtain routing numbers are not only
needed for NP, but also for the routing of service numbers and short
code numbers in the PSTN and also in SIP networks. This document
defines the use of the tel URI parameters defined for NP ("rn" and
"npdi") to route service numbers and short code numbers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Jesske Expires January 31, 2013 [Page 1]
Internet-Draft Sevicerouteing July 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overall Applicability . . . . . . . . . . . . . . . . . . . . 4
6. Normativ Rules . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Handling "tel" URI with NP Parameter or Parameters in
addition to the procedures described within RFC4694 . . . 8
6.2. Adding NP Parameter or Parameters to the "tel" URI . . . . 8
6.2.1. Retrieving Routinginformation for a Service
Telephone Number . . . . . . . . . . . . . . . . . . . 8
6.2.2. Adding NP Parameter or Parameters Due to Protocol
Conversion . . . . . . . . . . . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Jesske Expires January 31, 2013 [Page 2]
Internet-Draft Sevicerouteing July 2012
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses terms from [RFC3966].
2. Abbreviations
IAM Initial Address Message
ISUP Integrated Services Digital Network User Part
NP Number Portability
npdi NP Database Dip Indicator
rn Routing Number
SIP Session Initiation Protocol
URI Uniform Resource Identifier
VoIP Voice over IP
3. Overview
Within [E.164] the numbering schemes for national and international
numbers are defined.
The following numbers within E.164 are known:
International E.164-number for geographic areas.
International E.164-number for global services.
International E.164-number for Networks.
International E.164-number for Groups of Countries.
International E.164-number for Trials.
[RFC3966]defines the tel URI to reflect the numbering schema for
E.164 Numbers used within SIP networks.
Jesske Expires January 31, 2013 [Page 3]
Internet-Draft Sevicerouteing July 2012
But specific numbers used by operators like service numbers for
directory services, short numbers, specific networks or voting
numbers and many others are not within this scope. The routing of
such numbers is difficult in such case and depends on the environment
used.
Service numbers can result in many possible terminations, e.g. a 0800
service can be allocated to a nationwide company, or e.g. in Germany
a special number for local government services is used with the
number 115.
Due to the fact that such numbers must be routed based on the
location of the user within the network, and that the direct
reachability of the terminating user shall be avoided, the routing is
mainly based on a HEX digit prefix, like it is also used for ported
numbers.
For number portability RFC4694 [RFC4694] defines a routing number to
route correctly the dialled number of the user which is ported to an
other carrier domain. To allow the routing to a ported user the
originally dialled number has to be extended by an routing number.
This routing number points to the other network domain where the user
is now located. In many countries HEX digit are used for such
routing.
Also PSTN is using routing prefixes not only for ported numbers but
also for service numbers. In many cases the routing is depended on
the location where the call was originated. In such cases within the
SIP network a specific mechanism is needed.
4. Requirements
REQ-1:
A mechanism is needed to route telephone numbers which are not E.164
numbers.
REQ-2:
A mechanism is needed where routing prefixes have to be interworked
from PSTN to SIP.
5. Overall Applicability
The SIP procedures specified in this document are foreseen to define
an routing mechanism for service numbers that is equal as defined for
Jesske Expires January 31, 2013 [Page 4]
Internet-Draft Sevicerouteing July 2012
ported numbers within RFC 4694. Service numbers maybe defines within
E.164 as global service numbers or within the national numbering pan.
Short code numbers normally defined within the national numbering
plan. The SIP procedures specified in this document are foreseen to
define an routing mechanism for service numbers. This mechanism that
is equal as to the procedures defined for ported numbers within RFC
4694. According to E.164 Service numbers may be defines within
Such numbers will be reformatted within specific service platforms
(Intelligent Network IN) to route that through the network. Such
numbers are not dialable for the user, they have HEX digits or digits
that are not publicly allocated.
A format of such reformatted service number looks like <0> + <routing
prefix> + <service specific number> e.G <0> + < BC123> + <61511131>.
Note that the <0> in Germany is dialled to identify the call as a
national call and the <0> is not shown within the number it is
indicated as "Nature of address indicator" is National Significant
Number,.
As shown in Figure 1 a SIP interworking Gateway receives an Initial
Address Message (IAM) with the Called Party Number including the
routing prefix.
The SIP procedures specified in this document define a routing
mechanism for service numbers. This mechanism is equal to the
procedures defined for ported numbers within RFC 4694. According to
E.164 service numbers may be defined as global service numbers or
within the national numbering plan.
Short code numbers are normally defined within the national numbering
plan. Such numbers will be reformatted within specific service
platforms (Intelligent Network IN) in order to enable the routing
through the network. Such numbers can not be dialled by the user,
they have HEX digits or digits that are not publicly allocated.
A format of such reformatted service number looks like <0> + <routing
prefix> + <service specific number> e.G <0> + < BC123> + <61511131>.
Note that the <0> in Germany is dialled to identify the call as a
national call and the <0> is not shown within the number, it is
indicated as "Nature of address indicator" is National Significant
Number.
As shown in Figure 1 a SIP interworking gateway receives an Initial
Address Message (IAM) with the Called Party Number including the
routing prefix.
Example: A received IAM (Initial Address Message) from the PSTN/ISDN
Jesske Expires January 31, 2013 [Page 5]
Internet-Draft Sevicerouteing July 2012
network includes a CdPN: BC123-6151-1131 and the "Nature of address
indicator" is National Significant Number. The routing prefix in
this case is the BC123. The coding of ISUP is described within
[Q.763]
The interworked coding of the request URI in the INVITE should looks
like the following INVITE:
sip:+496151131;rn=+49BC1236151131@own-domain.com;user=phone
Figure 1 Gateway Scenario
+-----------+
IAM (CdPN) | | INVITE sip URI, rn, npdi
--------------->| PSTN GW |----------------->
| |
+-----------+
In principle either a tel URI or sip URI could be used the format at
the SIP outgoing side of the PSTN GW could be as follows.
INVITE
sip:+49-6151-1131;rn=+49-BC123-6151-1131@own-domain.com;user=phone
INVITE tel:+49-6151-1131;rn=+49-BC123-6151-1131
Figure 2 SIP network Scenario
+-----------+ +-----------+
| Routing Nr| | Serv. Nr. |
| DB | Dip to DB | DB | Dip to
| | to find | | translate to
+-----------+ destination +-----------+ terminating URI
| |
| |
INVITE +-----------+ INVITE +-----------+ INVITE
tel URI | | tel URI, rn, npdi| | tel URI
-------->|SIP Server |----------------->| SIP Server|--------->
SIP | SP A | | SP B | SIP
UA +-----------+ +-----------+ UA
Another scenario is a SIP network which is used to apply the service
number routing based on the same principles. Prefixes are used where
service numbers or short code numbers are dialled. Such a scenario
is a service provider B which is hosting a service which can be
Jesske Expires January 31, 2013 [Page 6]
Internet-Draft Sevicerouteing July 2012
accessed also by customers of other networks. Meanwhile such numbers
are not ported and they are very generic, and the originating
(geographical E.164 Number) of the dialling user has to be taken into
account. Or the service is hosted within the PSTN of the same
operator So the SIP Server of SP B in Figure 2 could be also an
application within the PSTN. And finally it can also be a local data
base only accessable by the owner e.g. a private network or PBX.
European number 115 for the "Single Government Service Telephone" is
used in this example. The user dials 115 for a the "Government
Service Telephone". He is living in village A and has the telephone
local area code 6201. But the l "Government Service Telephone" is
centralised and is in city B with the telephone local area code 6221.
So now to find the correct destination there is routing mechanism
needed to route the INVITE to the correct terminating UA.
Due to the fact that such numbers (115) could be routed in principle
to more than one location. To avoid that the caller is routed to
city C instead of city B a data base needs to include a routing
number to identify the termination application or network. So the
tel URI sent from the UA hat to be attached by the correct phone
context like country code plus local area code. So that the URI
looks like: INVITE tel:+49-115; phone-context=+49-6201
So the phone context of URI shows to which area the dialled number
belongs. Dipping the database for s numbers the dialled number
including the phone context is pointing to the related routing number
which is put into the INVITE as follows.
INVITE tel:115; phone-context=+49-6201;rn=+49-1986-115; npdi
Note that other service numbers or emergency numbers in Germany are
using HEX digits within the routing number
As mentioned in RFC 4964 how the call is actually routed based on the
routing number in the "rn" parameter is outside the scope of this
document. The terminating SIP Server could dip a second data base
either convert the request URI to the URI of the terminating UA.
6. Normativ Rules
This section describes the use of the parameters defined within
RFC4694 [RFC4694] that are used for the routing of service numbers,
short code numbers or other non E.164 numbers using additional
routing information to reach the destination.
Jesske Expires January 31, 2013 [Page 7]
Internet-Draft Sevicerouteing July 2012
6.1. Handling "tel" URI with NP Parameter or Parameters in addition to
the procedures described within RFC4694
The "npdi" parameter is used as described within RFC4694.
The "cic" parameter is NP+freephone specific and is not needed for
the purpose described within this document. The "cic" describes when
the call is sent to an other carrier where service numbers are
located. RFC4694 describes this case as ported free phone number.
This could be each service number like voting calls or 0900 services.
Also not each free phone number is ported it is given to the operator
by the regulator.
The "rn" parameter is used for routing to the destination. The
principles used for "rn" parameter in this document are the same as
described within RFC4694. The "rn" parameter identifies the
destination that could be a network domain, service number
application server or a PSTN application behind a PSTN GW. The
network node may access a data base or routing table or forward the
request to a default address where further call handling on the
request URI could appear. The data bases used are not within the
scope of NP. Note that the routing for NP is only described within
RFC4694.
6.2. Adding NP Parameter or Parameters to the "tel" URI
RFC 4684 describes two cases in terms of NP database access. One is
for an geographical telephone number and the other is for a free
phone number.
This document extends the use of routing database access for other
numbers like service numbers and shortcut numbers where a "rn"
parameter for routing is needed. As already mentioned this could be
numbers like 115 or 0900 and others.
The principle of adding the parameters "rn" and "npdi" are the same
as described within RFC 4694.
6.2.1. Retrieving Routinginformation for a Service Telephone Number
Service numbers could be personal numbers, 0900 numbers or other
specific service extensions. The rules of generating the "rn" and
"npdi" parameter in RFC4694 apply in such cases. The "cic" is not
used in such cases.
Jesske Expires January 31, 2013 [Page 8]
Internet-Draft Sevicerouteing July 2012
6.2.2. Adding NP Parameter or Parameters Due to Protocol Conversion
For interworking between PSTN and SIP networks the "rn" and "npdi"
parameters are used for numbers using routing extensions within the
request URI. The mapping of the Called Party Number to the "rn"
parameter and request URI depends on the national ISUP implementation
and is outside the scope of this document. For not ported service
number the "cic" is not within the scope of this document.
7. Examples
A "tel" URI, tel:+49-900-5331, contains a service telephone number
"+49-900-5331". This service number does not include any
geographical information on that could be routed. So the global
context should also include the validity indicating the local area.
Assume that this number cannot be routed via its own number the
number is associated with a routing number "+49-CC202-900-0000".
After retrieving the service-related information, the "tel" URI would
be set to tel:+49-900-5331;npdi;rn=+49-CC202-900-0000
8. Security Considerations
The same security considerations as described within RFC4694 apply.
9. IANA Considerations
This document does not have any implications for IANA.
10. Normative References
[E.164] "The international public telecommunication numbering
plan", February 2005.
[Q.763] "International Telecommunications Union, "Formats and
codes of the ISDN User Part of Signaling System No. 7",".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3966] "The tel URI for Telephone Numbers", October 2006.
[RFC4694] "Number Portability Parameters for the "tel" URI",
October 2006.
Jesske Expires January 31, 2013 [Page 9]
Internet-Draft Sevicerouteing July 2012
Author's Address
Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307
Germany
Phone: +4961515812766
Email: r.jesske@telekom.de
Jesske Expires January 31, 2013 [Page 10]