idnits 2.17.1 draft-jesske-dispatch-servicenumber-routeing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2012) is 4282 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dispatch R. Jesske 3 Internet-Draft Deutsche Telekom 4 Intended status: Informational July 30, 2012 5 Expires: January 31, 2013 7 Routing of Service Numbers with-in SIP (Session Initiation Protocol) 8 networks 9 draft-jesske-dispatch-servicenumber-routeing-01 11 Abstract 13 The combination of "rn" and "npdi" parameters which are normally used 14 for number portability (NP) can also solve numbering and routing 15 problems. Database dips to obtain routing numbers are not only 16 needed for NP, but also for the routing of service numbers and short 17 code numbers in the PSTN and also in SIP networks. This document 18 defines the use of the tel URI parameters defined for NP ("rn" and 19 "npdi") to route service numbers and short code numbers. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 31, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Overall Applicability . . . . . . . . . . . . . . . . . . . . 4 72 6. Normativ Rules . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6.1. Handling "tel" URI with NP Parameter or Parameters in 74 addition to the procedures described within RFC4694 . . . 8 75 6.2. Adding NP Parameter or Parameters to the "tel" URI . . . . 8 76 6.2.1. Retrieving Routinginformation for a Service 77 Telephone Number . . . . . . . . . . . . . . . . . . . 8 78 6.2.2. Adding NP Parameter or Parameters Due to Protocol 79 Conversion . . . . . . . . . . . . . . . . . . . . . . 9 80 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 10. Normative References . . . . . . . . . . . . . . . . . . . . . 9 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 This document uses terms from [RFC3966]. 94 2. Abbreviations 96 IAM Initial Address Message 98 ISUP Integrated Services Digital Network User Part 100 NP Number Portability 102 npdi NP Database Dip Indicator 104 rn Routing Number 106 SIP Session Initiation Protocol 108 URI Uniform Resource Identifier 110 VoIP Voice over IP 112 3. Overview 114 Within [E.164] the numbering schemes for national and international 115 numbers are defined. 117 The following numbers within E.164 are known: 119 International E.164-number for geographic areas. 121 International E.164-number for global services. 123 International E.164-number for Networks. 125 International E.164-number for Groups of Countries. 127 International E.164-number for Trials. 129 [RFC3966]defines the tel URI to reflect the numbering schema for 130 E.164 Numbers used within SIP networks. 132 But specific numbers used by operators like service numbers for 133 directory services, short numbers, specific networks or voting 134 numbers and many others are not within this scope. The routing of 135 such numbers is difficult in such case and depends on the environment 136 used. 138 Service numbers can result in many possible terminations, e.g. a 0800 139 service can be allocated to a nationwide company, or e.g. in Germany 140 a special number for local government services is used with the 141 number 115. 143 Due to the fact that such numbers must be routed based on the 144 location of the user within the network, and that the direct 145 reachability of the terminating user shall be avoided, the routing is 146 mainly based on a HEX digit prefix, like it is also used for ported 147 numbers. 149 For number portability RFC4694 [RFC4694] defines a routing number to 150 route correctly the dialled number of the user which is ported to an 151 other carrier domain. To allow the routing to a ported user the 152 originally dialled number has to be extended by an routing number. 153 This routing number points to the other network domain where the user 154 is now located. In many countries HEX digit are used for such 155 routing. 157 Also PSTN is using routing prefixes not only for ported numbers but 158 also for service numbers. In many cases the routing is depended on 159 the location where the call was originated. In such cases within the 160 SIP network a specific mechanism is needed. 162 4. Requirements 164 REQ-1: 166 A mechanism is needed to route telephone numbers which are not E.164 167 numbers. 169 REQ-2: 171 A mechanism is needed where routing prefixes have to be interworked 172 from PSTN to SIP. 174 5. Overall Applicability 176 The SIP procedures specified in this document are foreseen to define 177 an routing mechanism for service numbers that is equal as defined for 178 ported numbers within RFC 4694. Service numbers maybe defines within 179 E.164 as global service numbers or within the national numbering pan. 180 Short code numbers normally defined within the national numbering 181 plan. The SIP procedures specified in this document are foreseen to 182 define an routing mechanism for service numbers. This mechanism that 183 is equal as to the procedures defined for ported numbers within RFC 184 4694. According to E.164 Service numbers may be defines within 186 Such numbers will be reformatted within specific service platforms 187 (Intelligent Network IN) to route that through the network. Such 188 numbers are not dialable for the user, they have HEX digits or digits 189 that are not publicly allocated. 191 A format of such reformatted service number looks like <0> + + e.G <0> + < BC123> + <61511131>. 193 Note that the <0> in Germany is dialled to identify the call as a 194 national call and the <0> is not shown within the number it is 195 indicated as "Nature of address indicator" is National Significant 196 Number,. 198 As shown in Figure 1 a SIP interworking Gateway receives an Initial 199 Address Message (IAM) with the Called Party Number including the 200 routing prefix. 202 The SIP procedures specified in this document define a routing 203 mechanism for service numbers. This mechanism is equal to the 204 procedures defined for ported numbers within RFC 4694. According to 205 E.164 service numbers may be defined as global service numbers or 206 within the national numbering plan. 208 Short code numbers are normally defined within the national numbering 209 plan. Such numbers will be reformatted within specific service 210 platforms (Intelligent Network IN) in order to enable the routing 211 through the network. Such numbers can not be dialled by the user, 212 they have HEX digits or digits that are not publicly allocated. 214 A format of such reformatted service number looks like <0> + + e.G <0> + < BC123> + <61511131>. 216 Note that the <0> in Germany is dialled to identify the call as a 217 national call and the <0> is not shown within the number, it is 218 indicated as "Nature of address indicator" is National Significant 219 Number. 221 As shown in Figure 1 a SIP interworking gateway receives an Initial 222 Address Message (IAM) with the Called Party Number including the 223 routing prefix. 225 Example: A received IAM (Initial Address Message) from the PSTN/ISDN 226 network includes a CdPN: BC123-6151-1131 and the "Nature of address 227 indicator" is National Significant Number. The routing prefix in 228 this case is the BC123. The coding of ISUP is described within 229 [Q.763] 231 The interworked coding of the request URI in the INVITE should looks 232 like the following INVITE: 233 sip:+496151131;rn=+49BC1236151131@own-domain.com;user=phone 235 Figure 1 Gateway Scenario 237 +-----------+ 238 IAM (CdPN) | | INVITE sip URI, rn, npdi 239 --------------->| PSTN GW |-----------------> 240 | | 241 +-----------+ 243 In principle either a tel URI or sip URI could be used the format at 244 the SIP outgoing side of the PSTN GW could be as follows. 246 INVITE 247 sip:+49-6151-1131;rn=+49-BC123-6151-1131@own-domain.com;user=phone 249 INVITE tel:+49-6151-1131;rn=+49-BC123-6151-1131 251 Figure 2 SIP network Scenario 252 +-----------+ +-----------+ 253 | Routing Nr| | Serv. Nr. | 254 | DB | Dip to DB | DB | Dip to 255 | | to find | | translate to 256 +-----------+ destination +-----------+ terminating URI 257 | | 258 | | 259 INVITE +-----------+ INVITE +-----------+ INVITE 260 tel URI | | tel URI, rn, npdi| | tel URI 261 -------->|SIP Server |----------------->| SIP Server|---------> 262 SIP | SP A | | SP B | SIP 263 UA +-----------+ +-----------+ UA 265 Another scenario is a SIP network which is used to apply the service 266 number routing based on the same principles. Prefixes are used where 267 service numbers or short code numbers are dialled. Such a scenario 268 is a service provider B which is hosting a service which can be 269 accessed also by customers of other networks. Meanwhile such numbers 270 are not ported and they are very generic, and the originating 271 (geographical E.164 Number) of the dialling user has to be taken into 272 account. Or the service is hosted within the PSTN of the same 273 operator So the SIP Server of SP B in Figure 2 could be also an 274 application within the PSTN. And finally it can also be a local data 275 base only accessable by the owner e.g. a private network or PBX. 277 European number 115 for the "Single Government Service Telephone" is 278 used in this example. The user dials 115 for a the "Government 279 Service Telephone". He is living in village A and has the telephone 280 local area code 6201. But the l "Government Service Telephone" is 281 centralised and is in city B with the telephone local area code 6221. 282 So now to find the correct destination there is routing mechanism 283 needed to route the INVITE to the correct terminating UA. 285 Due to the fact that such numbers (115) could be routed in principle 286 to more than one location. To avoid that the caller is routed to 287 city C instead of city B a data base needs to include a routing 288 number to identify the termination application or network. So the 289 tel URI sent from the UA hat to be attached by the correct phone 290 context like country code plus local area code. So that the URI 291 looks like: INVITE tel:+49-115; phone-context=+49-6201 293 So the phone context of URI shows to which area the dialled number 294 belongs. Dipping the database for s numbers the dialled number 295 including the phone context is pointing to the related routing number 296 which is put into the INVITE as follows. 298 INVITE tel:115; phone-context=+49-6201;rn=+49-1986-115; npdi 300 Note that other service numbers or emergency numbers in Germany are 301 using HEX digits within the routing number 303 As mentioned in RFC 4964 how the call is actually routed based on the 304 routing number in the "rn" parameter is outside the scope of this 305 document. The terminating SIP Server could dip a second data base 306 either convert the request URI to the URI of the terminating UA. 308 6. Normativ Rules 310 This section describes the use of the parameters defined within 311 RFC4694 [RFC4694] that are used for the routing of service numbers, 312 short code numbers or other non E.164 numbers using additional 313 routing information to reach the destination. 315 6.1. Handling "tel" URI with NP Parameter or Parameters in addition to 316 the procedures described within RFC4694 318 The "npdi" parameter is used as described within RFC4694. 320 The "cic" parameter is NP+freephone specific and is not needed for 321 the purpose described within this document. The "cic" describes when 322 the call is sent to an other carrier where service numbers are 323 located. RFC4694 describes this case as ported free phone number. 324 This could be each service number like voting calls or 0900 services. 325 Also not each free phone number is ported it is given to the operator 326 by the regulator. 328 The "rn" parameter is used for routing to the destination. The 329 principles used for "rn" parameter in this document are the same as 330 described within RFC4694. The "rn" parameter identifies the 331 destination that could be a network domain, service number 332 application server or a PSTN application behind a PSTN GW. The 333 network node may access a data base or routing table or forward the 334 request to a default address where further call handling on the 335 request URI could appear. The data bases used are not within the 336 scope of NP. Note that the routing for NP is only described within 337 RFC4694. 339 6.2. Adding NP Parameter or Parameters to the "tel" URI 341 RFC 4684 describes two cases in terms of NP database access. One is 342 for an geographical telephone number and the other is for a free 343 phone number. 345 This document extends the use of routing database access for other 346 numbers like service numbers and shortcut numbers where a "rn" 347 parameter for routing is needed. As already mentioned this could be 348 numbers like 115 or 0900 and others. 350 The principle of adding the parameters "rn" and "npdi" are the same 351 as described within RFC 4694. 353 6.2.1. Retrieving Routinginformation for a Service Telephone Number 355 Service numbers could be personal numbers, 0900 numbers or other 356 specific service extensions. The rules of generating the "rn" and 357 "npdi" parameter in RFC4694 apply in such cases. The "cic" is not 358 used in such cases. 360 6.2.2. Adding NP Parameter or Parameters Due to Protocol Conversion 362 For interworking between PSTN and SIP networks the "rn" and "npdi" 363 parameters are used for numbers using routing extensions within the 364 request URI. The mapping of the Called Party Number to the "rn" 365 parameter and request URI depends on the national ISUP implementation 366 and is outside the scope of this document. For not ported service 367 number the "cic" is not within the scope of this document. 369 7. Examples 371 A "tel" URI, tel:+49-900-5331, contains a service telephone number 372 "+49-900-5331". This service number does not include any 373 geographical information on that could be routed. So the global 374 context should also include the validity indicating the local area. 375 Assume that this number cannot be routed via its own number the 376 number is associated with a routing number "+49-CC202-900-0000". 377 After retrieving the service-related information, the "tel" URI would 378 be set to tel:+49-900-5331;npdi;rn=+49-CC202-900-0000 380 8. Security Considerations 382 The same security considerations as described within RFC4694 apply. 384 9. IANA Considerations 386 This document does not have any implications for IANA. 388 10. Normative References 390 [E.164] "The international public telecommunication numbering 391 plan", February 2005. 393 [Q.763] "International Telecommunications Union, "Formats and 394 codes of the ISDN User Part of Signaling System No. 7",". 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", March 1997. 399 [RFC3966] "The tel URI for Telephone Numbers", October 2006. 401 [RFC4694] "Number Portability Parameters for the "tel" URI", 402 October 2006. 404 Author's Address 406 Roland Jesske 407 Deutsche Telekom 408 Heinrich-Hertz-Strasse 3-7 409 Darmstadt, 64307 410 Germany 412 Phone: +4961515812766 413 Email: r.jesske@telekom.de