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> + + 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> + + 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]