idnits 2.17.1 draft-ietf-iptel-tel-np-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 740. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 726. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 2006) is 6441 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3261' is mentioned on line 283, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-06) exists of draft-ietf-iptel-tel-reg-02 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL Working Group J. Yu 3 Internet Draft NeuStar 4 Document: draft-ietf-iptel-tel-np-11.txt August 28, 2006 5 Category: Standards Track 7 NP Parameters for the "tel" URI 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 27, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines five parameters in the "tel" Uniform Resource 41 Identifier (URI) to carry the number portability (NP)-related 42 information. Those parameters can be passed to the next-hop network 43 node after an NP database dip has been performed. 45 Table of Contents 47 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 3. Abbreviation . . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 4 51 5. Normative Rules . . . . . . . . . . . . . . . . . . . . . . 5 52 5.1. Handling "tel" URI with NP Parameter or Parameters . . . 6 53 5.2. Adding NP Parameter or Parameters to the "tel" URI . . . 8 54 5.2.1. Retrieving NP-related information for a geographical 55 telephone number . . . . . . . . . . . . . . . . . . 8 56 5.2.2. Retrieving NP-related information for a freephone 57 number . . . . . . . . . . . . . . . . . . . . . . . 9 58 5.2.3. Adding location information about the caller . . . . 10 59 5.2.4. Adding NP parameter or parameters due to protocol 60 Conversion . . . . . . . . . . . . . . . . . . . . . 10 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 7. Security Considerations . . . . . . . . . . . . . . . . . . 12 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 66 9.2. Informative References . . . . . . . . . . . . . . . . . 13 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . . 14 71 1. Conventions 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC2119 [RFC2119]. 77 2. Introduction 79 Number portability (NP) [RFC3482] allows telephony subscribers to 80 keep their telephone numbers when they change service provider 81 (service provider portability), move to a new location (location 82 portability), or change the subscribed services (service 83 portability). The telephone numbers can be the geographical 84 telephone numbers, mobile telephone numbers, freephone numbers or 85 other types of non-geographical telephone numbers. Some mobile 86 telephone numbers are like geographical telephone numbers (e.g., 87 those in the North America) and others are of non-geographical 88 nature but their routing is similar to the routing of geographical 89 telephone numbers so they are not specifically mentioned in this 90 document. The freephone numbers are also known as the toll free 91 phone numbers. The called party who is assigned the freephone 92 number pays the call charge when the caller dials the freephone 93 number. 95 NP impacts call signaling and routing. One impact is the need to 96 carry the NP-related information in the "tel" URI [RFC3966] for 97 protocols such as the Session Initiation Protocol (SIP) [RFC3261] 98 and H.323 [H323] after the NP database dip has been performed. 99 Another impact is for a Voice over IP (VoIP) server to use the NP- 100 related information in a received "tel" URI to determine routing. 102 A routing number is associated with a geographical or mobile 103 telephone number that has been ported out from a donor carrier to 104 another carrier. A donor carrier is the initial carrier where a 105 geographical telephone number was allocated before ever being 106 ported. A "non-ported" geographical or mobile telephone number does 107 not have any routing number associated with it because the first N 108 digits of the geographical or mobile telephone number can be used 109 for routing. A routing number can also be used to indicate the 110 switch or network node that originates a call or service similar to 111 the Jurisdiction Information Parameter in Signaling System Number 7 112 (SS7) Integrated Services Digital Network User Part (ISUP). The 113 "rn" parameter carries the routing number information. The "rn- 114 context" parameter describes how the "rn" parameter value should be 115 interpreted when the value is not a "global-rn" as is discussed in 116 Section 4. 118 The NP database dip indicator is used to inform the downstream 119 servers or switches during call setup that there is no need to 120 perform the NP database dip for a geographical telephone number 121 again. The "npdi" parameter carries such an indicator. 123 A "Carrier Identification Code (CIC)" identifies the current 124 freephone service provider for a freephone number. This parameter 125 can also be used to carry the pre-subscribed or dialed long distance 126 carrier information; however, that is outside the scope of this 127 document. The "cic" parameter carries the CIC information. The 128 "cic-context" parameter describes how the "cic" parameter value 129 should be interpreted when the value is not a "global-cic" as is 130 discussed in Section 4. 132 3. Abbreviations 134 ABNF Augmented Backus-Naur Form 135 ANSI American National Standards Institute 136 CIC Carrier Identification Code (also cic) 137 CIP Carrier Identification Parameter 138 FCI Forward Call Indicator 139 GAP Generic Address Parameter 140 GSTN Global Switched Telephone Network 141 HTML HyperText Markup Language 142 IC Identification Code 143 ISUP Integrated Services Digital Network User Part 144 JIP Jurisdiction Information Parameter 145 NP Number Portability 146 NPDB Number Portability Database 147 npdi NP Database Dip Indicator 148 rn Routing Number 149 PNTI Ported Number Translation Indicator 150 SIP Session Initiation Protocol 151 SS7 Signaling System Number 7 152 URI Uniform Resource Identifier 153 VoIP Voice over IP 155 4. Formal Syntax 157 The following syntax specification uses the Augmented Backus-Naur 158 Form (ABNF) as described in RFC-4234 [RFC4234] and defines the five 159 parameters, rn, npdi, cic, rn-context and cic-context, by extending 160 the "parameter" production rule of the "tel" URI defined in 161 [RFC3966]. 163 Parameter =/ rn / cic / npdi 164 rn = ";rn=" (global-rn / local-rn) 165 npdi = ";npdi" 166 cic = ";cic=" (global-cic / local-cic) 167 global-rn = global-hex-digits 168 local-rn = 1*hex-phonedigit rn-context 169 rn-context = ";rn-context=" rn-descriptor 170 rn-descriptor = domainname / global-hex-digits 171 global-hex-digits = "+" 1*3(DIGIT) *hex-phonedigit 172 hex-phonedigit = HEXDIG / visual-separator 173 visual-separator = "-" / "." / "(" / ")" 174 domainname = *( domainlabel "." ) toplabel ["."] 175 domainlabel = alphanum 176 / alphanum *( alphanum / "-" ) alphanum 177 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 178 alphanum = ALPHA / DIGIT 179 global-cic = global-hex-digits 180 local-cic = 1*hex-phonedigit cic-context 181 cic-context = ";cic-context=" rn-descriptor 183 The "rn", "npdi" or "cic" parameter each can appear in the "tel" URI 184 at most once. 186 The first "hex-phonedigit" value in "local-rn" or "local-cic" MUST 187 be a hex-decimal digit. 189 For a "global-rn", the routing number information after "+" MUST 190 begin with a valid E.164 [E164] country code. Hexadecimal digit is 191 allowed after the country code in the "global-rn". 193 For a "local-rn", the routing number in the "rn" parameter MUST be 194 interpreted according to the "rn-context". For example, if a 195 national routing number is in the "rn" parameter, the "rn-context" 196 MUST contain a valid E.164 country code after "+" if it is in the 197 "global-hex-digits" format. Hexadecimal digit is allowed in the 198 "local-rn". 200 For a "global-cic", the CIC information after "+" MUST begin with a 201 valid E.164 country code. 203 For a "local-cic", the CIC value in the "cic" parameter MUST be 204 interpreted according to the "cic-context". For example, if the 205 national CIC value is in the "cic" parameter, the "cic-context" MUST 206 contain a valid E.164 country code after "+" if it is in the 207 "global-hex-digits" format. 209 The inclusion of the visual separator in the "rn" or "cic" is 210 optional. 212 5. Normative Rules 214 There are two distinct uses for the tel URI. In one use, the tel URI 215 appears in a piece of static content. For example, it might appear 216 in a HyperText Markup Language (HTML) page or a presence document. 217 In another use, the tel URI appears in call signaling protocols, 218 such as SIP and H.323, where it is used to guide routing of the call 219 setup messages. The tel URI extensions defined in this document are 220 targeted at call signaling protocols. When a tel URI is placed in 221 static content, the parameters defined here SHOULD NOT be present, 222 and any entity receiving them SHOULD remove them prior to using the 223 tel URI. 225 Within the context of signaling protocols, these parameters are 226 meant for usage between call signaling entities, called network 227 nodes, amongst them there is a trust relationship. Since parameters 228 inserted by one network node can impact the routing of a request at 229 a downstream node, processing of these parameters depends on 230 trusting that the upstream element properly followed the rules 231 defined here. A call signaling protocol can verify that an upstream 232 element is part of its circle of trust through hop-by-hop integrity 233 mechanisms. See Section 7, Security Considerations, for more 234 information. If a network node receives a call signaling message 235 from an element it does not trust, it SHOULD ignore the parameters. 237 This section discusses how a network node handles a received "tel" 238 URI that contains one or more of the parameters defined in this 239 document or has accessed an NP database for a freephone number or 240 geographical telephone number and needs to add some of the 241 parameters defined in this document to a "tel" URI. 243 In countries where there is no freephone number portability or 244 geographical telephone number portability, the call routing can be 245 based on the leading digits of the freephone number or geographical 246 telephone number. This document does not describe those scenarios. 248 Please note that two accesses to the freephone databases are 249 normally done for routing a call to a freephone number. The first 250 one is done by the originating network that queries a freephone 251 database for the CIC information so that the call can be routed to 252 the serving freephone service provider of the called freephone 253 number. When the call reaches the serving freephone provider, the 254 second database access is performed to map the freephone number to a 255 geographical telephone number and/or internal routing information. 256 This document does not address the case where internal routing 257 information is returned. 259 The first freephone database contains the CIC information for all 260 the active freephone numbers while the second one usually contains 261 mapping information only for those freephone numbers served by a 262 freephone service provider. Because the originating carrier may 263 provide freephone service, its freephone database would contain the 264 CIC information for all the active freephone numbers plus the 265 mapping information for those freephone numbers it serves. This 266 document refers to the two database accesses as "the first freephone 267 database access" and "the second freephone database access". 269 When handling the "rn" and "cic" parameters and the phone numbers in 270 the "tel" URI for the purposes such as database access and routing, 271 the visual separators in them are removed before using the 272 information in them. 274 When a network node handles a "tel" URI that contains invalid "rn" 275 or "cic" information, it may release the call or drop the invalid 276 parameter and access the appropriate NP database or freephone 277 database to see if it can retrieve a valid routing number for a 278 geographical telephone number or valid CIC for the freephone number. 280 When a "tel" URI is received from an untrusted source, a network 281 node MAY redo the NPDB query. 283 SIP [RFC 3261] has mechanisms in place to detect routing loops due to 284 URI re-writing, and the new parameters added here work within these 285 established contexts. The npdi parameter in the URI that indicates a 286 NPDB query has already been done can also prevent routing loop. 287 Other protocols considering using these "tel" URI parameters SHOULD 288 ensure that they have mechanisms in place to detect loops when re- 289 writing the "tel" URI. 291 5.1 Handling "tel" URI with NP Parameter or Parameters 293 If the "tel" URI contains the "npdi" parameter, the network node 294 MUST NOT retrieve the NP-related information for geographical 295 telephone numbers even if it is set to do so. 297 If the "tel" URI contains the "cic" parameter whose CIC value is 298 different from the one this network node is associated with, this 299 network node MUST NOT retrieve the NP-related information for the 300 geographical telephone number or perform the first freephone 301 database access for the freephone number in the "tel" URI. 303 For the "cic" and "rn" parameters and either a freephone number or 304 geographical telephone number, the order of processing is to look 305 for the "cic" parameter first for call routing. If the CIC 306 information is not useful or the "cic" parameter does not exist, 307 then the next step is to look for the "rn" parameter. If the 308 information in the "rn" parameter is not useful or the "rn" 309 parameter does not exist, then the freephone number or geographical 310 telephone number is used. 312 If the network node does not know how to route based on the "cic" or 313 "rn" parameter, the local policies MUST decide whether to stop the 314 call processing or continue the call processing by ignoring the 315 invalid/unknown information. 317 When looking for the "cic" parameter and that parameter exists in 318 the "tel" URI: 320 - The network node MUST ignore the "cic" parameter if the CIC 321 identifies a carrier or service provider associated with that node 322 and look for the "rn" parameter for making the routing decision. 323 It MUST remove the "cic" parameter when it routes the call to the 324 next-hop network node that belongs to another carrier or service 325 provider. 327 - The network node MUST invoke special handling process if the "cic" 328 parameter contains a code that requires such a treatment. For 329 example, a CIC value of "0110" in the response to a freephone DB 330 query in the North America indicates "local, translated 331 geographical telephone number provided". In this particular 332 example, the "cic" parameter is ignored. Please note that this 333 particular CIC value of "+1-0110" normally will not appear in the 334 call setup message. It is given as an example to show that such 335 special CIC values may exist. The exact code values and the 336 handling of them are outside the scope of this document. 338 - Otherwise, the network node MUST make the routing decision based 339 on the CIC. The network node MUST NOT remove the "cic" parameter 340 unless it is handing over the call to the carrier or service 341 provider identified by the CIC and the local policies require it 342 to remove the "cic" parameter. How the call is actually routed 343 based on the CIC value in the "cic" parameter is outside the scope 344 of this document. 346 When looking for the "rn" parameter and that parameter exists in the 347 "tel" URI: 349 - If the routing number in the "rn" parameter points to this network 350 node (e.g., the call has reached the intended network node), this 351 network node MUST look for the freephone number or geographical 352 telephone number for making the routing decision. It MUST remove 353 the "rn" parameter when setting up the call to the next-hop 354 network node regardless if that next-hop network node is in the 355 same or different network. 357 - If the routing number in the "rn" parameter points to a network 358 this network node is in (e.g., in some countries the routing 359 number gets the call to the serving carrier network where another 360 NP database access is required to locate the serving switch), this 361 network node MUST look for the freephone number or geographical 362 telephone number for making the routing decision. The network 363 node MAY access the NP database for routing information if it is 364 set to do so. It MUST remove the "rn" parameter if the next-hop 365 network node belongs to another carrier or service provider. 367 - Otherwise, the network node MUST make the routing decision based 368 on the routing number in the "rn" parameter. How the call is 369 actually routed based on the routing number in the "rn" parameter 370 is outside the scope of this document. 372 When the "cic" or "rn" parameter is not used for routing, the 373 network node uses the freephone number or geographical telephone 374 number for making routing decisions. It may access the NP database 375 if it is set to do so, or it may route the call to a designated 376 network node that will access the NP database, or it may route the 377 call based on the local routing table. How the call is handled at 378 this stage is outside the scope of this document. See Section 5.2 379 for rules in adding the parameter or parameters defined in this 380 document to the "tel" URI if the network node is set to access the 381 NP database. 383 5.2 Adding NP Parameter or Parameters to the "tel" URI 385 There are two cases in terms of NP database access. One is for a 386 geographical telephone number and the other is for a freephone 387 number. They are discussed in Sections 5.2.1 and 5.2.2 for a "tel" 388 URI that is used for routing. 390 Section 5.2.3 discusses a special case where the "rn" parameter is 391 added to a "tel" URI that is associated with the first network node 392 that handles the call request from the caller. Section 5.3.4 393 discusses the addition of the parameter or parameters defined in 394 this document to the "tel" URI due to protocol conversion. 396 5.2.1 Retrieving NP-related information for a geographical telephone 397 number 399 When a network node accesses an NP database for a geographical 400 telephone number: 402 - If the network node retrieves a routing number, it MUST add the 403 "rn" parameter to the "tel" URI to carry the routing number 404 information in the "global-rn" or "local-rn" format. It MUST also 405 add the "npdi" parameter. 407 - If the network node does not retrieve a routing number (e.g., for 408 a non-ported geographical telephone number), it MUST add the 409 "npdi" parameter to the "tel" URI. 411 The network node MUST follow the rules described in Section 5.1 for 412 using the information in the "tel" URI to make the routing decision. 414 5.2.2 Retrieving NP-related information for a freephone number 416 When a network node performs the first or second freephone database 417 access for a freephone number: 419 - If the network node retrieves a CIC that identifies a carrier or 420 service provider associated with that network node, or indicates 421 that a geographic number is supplied (e.g., "+1-0110" means 422 "local, translated geographical telephone number provided"), it 423 would have retrieved a geographical telephone number. The network 424 node MUST NOT add the "cic" parameter and MUST replace the 425 freephone number in the "tel" URI with the retrieved geographical 426 telephone number in either the "global-number" or "local-number" 427 format. 429 Some freephone databases may not return the geographical telephone 430 number but internal routing information in a proprietary format 431 (e.g., switch ID and trunk group ID). That case is outside the 432 scope of this document. 434 - If the network node retrieves a CIC that belongs to another 435 freephone service provider, the network node MUST add the "cic" 436 parameter to the "tel" URI that contains the CIC in the "global- 437 cic" or "local-cic" format. 439 The originating carrier may have business agreements with a 440 freephone service provider to return the geographical telephone 441 number in addition to the CIC. When a geographical telephone 442 number is returned, the network node MUST replace the freephone 443 number in the "tel" URI with the returned geographical telephone 444 number in either the "global-number" or "local-number" format. 446 - If the network node retrieves a geographical telephone number 447 (which is the typical case for the second freephone database 448 access), the network node MUST replace the freephone number in the 449 "tel" URI with the retrieved geographical telephone number in 450 either the "global-number" or "local-number" format. 452 When a geographical telephone number is returned in the response, 453 it is possible that the NP-related information for that 454 geographical telephone number could also be returned. In that 455 case, the network node MUST add the "npdi" parameter and MUST add 456 the "rn" parameter to contain the routing number in either the 457 "global-rn" or "local-rn" format only when the routing number is 458 available. 460 The network node MUST follow the rules described in Section 5.1 for 461 using the information in the "tel" URI to make the routing decision. 463 5.2.3 Adding location information about the caller 465 In SS7 ISUP, the JIP identifies the switch that originates the call 466 and the information in it may be used by the serving carrier to 467 determine the call charge to the caller or by the involved carriers 468 to determine the settlement amount between them. 470 A network node that is the first to handle the call request from the 471 caller MAY include the "rn" parameter to the "tel" URI associated 472 with the caller, if one exists. For example, if the network node is 473 a Global Switched Telephone Network (GSTN) gateway that receives an 474 ISUP message that contains the JIP, the correct location information 475 in the JIP can be placed in the "rn" parameter of the "tel" URI that 476 is associated with the caller. 478 Please note that the information in the "rn" parameter may not be 479 authenticated; therefore, the use of the information by the 480 recipient of the "tel" URI for anything related to charging is done 481 at its own risk. 483 5.2.4 Adding NP parameter or parameters due to protocol conversion 485 A GSTN gateway needs to convert between SS7 ISUP and the VoIP 486 protocol such as SIP or H.323. This type of network node MUST map 487 between the corresponding ISUP parameters and the parameters defined 488 in this document associated with the "tel" URI for routing and MAY 489 map between the corresponding ISUP parameters and the parameters 490 defined in this document that are in the "tel" URI associated with 491 the caller. 493 Since ISUP support for NP depends on the individual country, the 494 following discussion applies to a situation when a network node is 495 to map between the NP information in the American National Standards 496 Institute (ANSI) ISUP and the NP-related parameters in the "tel" 497 URI. 499 For a ported geographical telephone number, the network node MUST 500 convert the routing number in the ISUP Called Party Number parameter 501 to a routing number in either the "global-rn" or "local-rn" format 502 and carry it in the "rn" parameter for a "tel" URI that is used for 503 routing. The network node MUST convert the phone number that is 504 marked as the "ported number" in the ISUP Generic Address Parameter 505 (GAP) to a phone number in either the "global-number" or "local- 506 number" format [RFC3966] and put it in the global-number-digits or 507 local-number-digits (see [RFC3966]) part of the "tel" URI that is 508 used for routing. 510 For a non-ported geographical telephone number, the network node 511 MUST convert the phone number in the ISUP Called Party Number 512 parameter to a phone number in either the "global-number" or "local- 513 number" format and put it in the global-number-digits or local- 514 number-digits (see [RFC3966]) part of the "tel" URI that is used for 515 routing. The "rn" parameter MUST NOT appear in the "tel" URI unless 516 the local policies require the network node to include it. It is 517 outside the scope of this document how to include the "rn" parameter 518 if the local policies require the network node to do so. 520 The network node MUST include the "npdi" parameter in the "tel" URI 521 that is used for routing when the Ported Number Translation 522 Indicator (PNTI) bit in the Forward Call Indicator (FCI) parameter 523 is set to "1". 525 The network node MUST include the "cic" parameter in either the 526 "global-cic" or "local-cic" format in the "tel" URI that is used for 527 routing when the ISUP Carrier Identification Parameter (CIP) is 528 present. 530 The network node MAY include the "rn" parameter in the "tel" URI 531 associated with the caller information when the ISUP JIP is present. 532 This may be subject to the network node's local policy and/or the 533 signaling protocol that carries the "tel" URI. 535 Mapping NP-related parameters in a "tel" URI to the NP-related 536 information in the ISUP message depends on the national ISUP 537 implementation and is outside the scope of this document. 539 6. Examples 541 A. A "tel" URI, tel:+1-800-123-4567, contains a freephone number "+1- 542 800-123-4567". Assume that this freephone number is served by a 543 freephone service provider with a CIC "+1-6789". After retrieving 544 the NP-related information, the "tel" URI would be set to 546 tel:+1-800-123-4567;cic=+1-6789 548 B. A "tel" URI, tel:+1-800-123-4567;cic=+1-6789, is handled by a 549 network node in the serving freephone service provider's network. 550 Assume that the freephone number is mapped to a geographical 551 telephone number "+1-202-533-1234". After retrieving the NP- 552 related information, the "tel" URI would be set to 554 tel:+1-202-533-1234 556 C. A "tel" URI, tel:+1-202-533-1234, contains a geographical 557 telephone number "+1-202-533-1234". Assume that this geographical 558 telephone number is ported and is associated with a routing number 559 "1-202-544-0000". After retrieving the NP-related information, 560 the "tel" URI would be set to 562 tel:+1-202-533-1234;npdi;rn=+1-202-544-0000 564 D. A "tel" URI, tel:+1-202-533-6789, contains a geographical 565 telephone number "+1-202-533-6789". Assume that this geographical 566 telephone number is not ported. After accessing the NP database, 567 the "tel" URI would be set to 568 tel:+1-202-533-6789;npdi 570 E. A "tel" URI, tel:+1-202-533-1234;npdi;rn=+1-202-000-0000, contains 571 an invalid routing number (e.g., no routing information on "+1- 572 202-000-0000"), the network node may drop the "rn" parameter and 573 access the NP database again. 575 F. A "tel" URI, tel:+1-800-123-456, contains a freephone number "+1- 576 800-123-456" that is one digit short. When accessing the 577 freephone database, there won't be any "cic" information for this 578 freephone number. The call would be released. 580 G. A "tel" URI, tel:+1-800-123-4567;cic=+1-56789, is handled by a 581 network node in an originating or a transit network. The "cic" 582 information is invalid. The network node may drop the "cic" 583 parameter and access the freephone database again. If the same 584 wrong CIC information is received, the network node would release 585 the call because it does not know how to route the call with an 586 invalid CIC. If valid information is received, the network node 587 will use the received CIC in the "cic" and route the call based on 588 the "cic". 590 7. Security Considerations 592 In addition to those security implications discussed in the revised 593 "tel" URI [RFC3966], there are new security implications associated 594 with the parameters defined in this document. 596 If the value of the "rn" or "cic" in the "tel" URI is changed 597 illegally when the signaling message carrying the "tel" URI is en 598 route to the destination entity, the signaling message or call may 599 be routed to the wrong network or network node causing the call 600 setup to be rejected. 602 If the "npdi" is illegally inserted into the "tel" URI when the 603 signaling message carrying the "tel" URI is en route to the 604 destination entity, the call may be routed to the wrong network or 605 network node causing the call setup to be rejected. It is less a 606 problem if the "npdi" is illegally removed. An additional NPDB 607 query may be performed to retrieve the routing number information 608 and have the "npdi" included again. 610 If the "rn" in the "tel" URI that is associated with the caller is 611 illegally changed or inserted, the call charge based on that "rn" 612 would be incorrect. 614 Because of these considerations, these tel URI extensions are only 615 applicable within a set of network nodes amongst them there is 616 mutual trust. If a node receives a call signaling request from an 617 upstream node it does not trust, it SHOULD remove these parameters. 618 This will generally cause it to redo any DB queries. 620 To verify that an upstream neighbor is trusted, and to prevent man- 621 in-the-middle attacks whereby an attacker inserts or modifies these 622 parameters, call signaling protocols carrying these parameters 623 SHOULD provide hop-by-hop message integrity. In the case of SIP, 624 this is accomplished with the SIPS URI mechanism. 626 8. IANA Considerations 628 This document defines five parameters for the "tel" URI. Further 629 information on a registry for those parameters is covered in 630 [TELREG]. This document requires no IANA actions. 632 9. References 634 9.1 Normative References 636 [E164] ITU-T Recommendation E.164, "The international public 637 telecommunication numbering plan," May 1997. 639 [RFC2119] S. Bradner, RFC2119, "Key words for use in RFCs to 640 Indicate Requirement Levels," March 1997. 642 [RFC3966] H. Schulzrinne, RFC3966, "The tel URI for Telephone 643 Numbers," December 2004. 645 [RFC4234] D. Crocker and P. Overell, RFC4234, "Augmented BNF for 646 Syntax Specifications: ABNF," October 2005. 648 9.2 Informative References 650 [H323] ITU-T Recommendation H.323, "Packet-Based Multimedia 651 Communications Systems," November 2000. 653 [RFC3261] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation 654 Protocol," June 2002. 656 [RFC3482] M. Foster, T. McGarry and J. Yu, RFC3482, "Number 657 Portability in the GSTN: An Overview," February 2003. 659 [TELREG] C. Jennings and V. Gurbani, "The Internet Assigned Number 660 Authority (IANA) tel Uniform Resource Identifier (URI) 661 Parameter Registry", draft-ietf-iptel-tel-reg-02.txt (work 662 in progress), May 2006. 664 10. Acknowledgments 666 The author would like to thank Penn Pfautz, Jon Peterson, Jonathan 667 Rosenberg, Henning Schulzrinne, Antti Vaha-Sipila, Flemming 668 Andreasen and Mike Hammer for their discussions and comments. 670 Author's Address 672 James Yu 673 NeuStar, Inc. 674 46000 Center Oak Plaza 675 Sterling, VA 20166 676 U.S.A. 677 Phone: +1-571-434-5572 678 Email: james.yu@neustar.biz 680 Intellectual Property Statement 682 The IETF takes no position regarding the validity or scope of any 683 Intellectual Property Rights or other rights that might be claimed 684 to pertain to the implementation or use of the technology described 685 in this document or the extent to which any license under such 686 rights might or might not be available; nor does it represent that 687 it has made any independent effort to identify any such rights. 688 Information on the procedures with respect to rights in RFC 689 documents can be found in BCP 78 and BCP 79. 691 Copies of IPR disclosures made to the IETF Secretariat and any 692 assurances of licenses to be made available, or the result of an 693 attempt made to obtain a general license or permission for the use 694 of such proprietary rights by implementers or users of this 695 specification can be obtained from the IETF on-line IPR repository 696 at http://www.ietf.org/ipr. 698 The IETF invites any interested party to bring to its attention any 699 copyrights, patents or patent applications, or other proprietary 700 rights that may cover technology that may be required to implement 701 this standard. Please address the information to the IETF at 702 ietf-ipr@ietf.org. 704 Disclaimer of Validity 706 The IETF takes no position regarding the validity or scope of any 707 Intellectual Property Rights or other rights that might be claimed 708 to pertain to the implementation or use of the technology described 709 in this document or the extent to which any license under such 710 rights might or might not be available; nor does it represent that 711 it has made any independent effort to identify any such rights. 712 Information on the procedures with respect to rights in RFC 713 documents can be found in BCP 78 and BCP 79. 715 Copies of IPR disclosures made to the IETF Secretariat and any 716 assurances of licenses to be made available, or the result of an 717 attempt made to obtain a general license or permission for the use 718 of such proprietary rights by implementers or users of this 719 specification can be obtained from the IETF on-line IPR repository 720 at http://www.ietf.org/ipr. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights that may cover technology that may be required to implement 725 this standard. Please address the information to the IETF at ietf- 726 ipr@ietf.org. 728 Copyright Statement 730 Copyright (C) The Internet Society (2006). This document is subject 731 to the rights, licenses and restrictions contained in BCP 78, and 732 except as set forth therein, the authors retain all their rights. 734 This document and the information contained herein are provided on 735 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 736 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 737 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 738 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 739 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 740 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 742 Acknowledgment 744 Funding for the RFC Editor function is currently provided by the 745 Internet Society.