idnits 2.17.1 draft-yu-tel-dai-09.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4694]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (April 29, 2010) is 5111 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) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPTEL Working Group J.Yu 2 Internet Draft NueStar 3 Intended status: Standards track D. Hancock 4 Expires: October 31, 2010 CableLabs 5 F. Andreasen 6 Cisco 8 April 29, 2010 10 DAI Parameter for the "tel" URI 11 draft-yu-tel-dai-09 13 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on October 31, 2010. 35 Abstract 36 This document defines a "dai" parameter for the "tel" Uniform 37 Resource Identifier (URI) to support the Dial Around Indicator (DAI). 38 The "dai" parameter is associated with the "cic" parameter, defined 39 in [RFC4694], and indicates how the carrier identified in the "cic" 40 parameter was selected. This document also expands the use of the 41 "cic" parameter to support pre-subscribed and dialed long-distance 42 carrier requirements. 44 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC2119 [RFC2119]. 49 Internet-Draft DAI Parameter for the "tel" URI April 29, 50 2010 52 Table of Contents 54 1. Introduction...................................................2 55 2. Terminology....................................................3 56 3. Abbreviations..................................................3 57 4. Formal Syntax..................................................3 58 5. Normative Rules................................................5 59 6. Examples......................................................15 60 7. Security Considerations.......................................16 61 8. IANA Considerations...........................................17 62 9. References....................................................17 63 10. Change History...............................................17 65 1. Introduction 67 Before equal access was supported in the United States, only AT&T's 68 subscribers could dial "1" to reach AT&T when they made long distance 69 calls. Other long distance carriers' subscribers needed to dial 70 extra digits to reach their long distance carriers. For fair 71 competition, the Federal Communication Commission in the U.S. 72 mandated the support for equal access that allowed any long distance 73 carrier's subscriber to follow the same dialing plan to reach his/her 74 pre-subscribed long distance carrier. The regulatory bodies in many 75 other countries also have mandated equal access. 77 To allow a telephony subscriber to use a non-pre-subscribed long 78 distance carrier for some of their long distance calls, the U.S. has 79 implemented the dialing prefix "10XXX" that was later expanded to 80 "101XXXX" in the dialing plan. The prefix allows the caller to use 81 "XXX" or "XXXX" to specify the long distance carrier to handle that 82 particular call. This dialing prefix was also used to identify the 83 local toll carrier in the United States when equal access also 84 applied to the local toll calls. 86 One of the purposes of the DAI is to indicate to the long distance 87 carrier that receives a call from the local exchange carrier whether 88 the call came from a pre-subscribed customer or not. Due to 89 operator-assisted calls, where the called party or a third party may 90 be charged for the call in some cases, the DAI is also used to 91 indicate to the receiving long distance carrier if it is the primary 92 or alternate preferred long distance carrier of the charged party. 94 The long distance carrier information, the Carrier Identification 95 Code (CIC), can be carried in the "cic" parameter [RFC4694], a 96 parameter of the "tel" Uniform Resource Identifier (URI) [RFC3966]. 97 The "cic" parameter defined in [RFC4694] identifies the freephone 98 service provider that serves the freephone number. As described in 99 [RFC4694], it can also be used to carry the CIC associated with the 101 Internet-Draft DAI Parameter for the "tel" URI April 29, 102 2010 103 carrier who is to handle a call to a geographic telephone number; 104 such usage is leveraged in this document. When the carrier that is 105 assigned the CIC receives the call, the "dai" parameter defined in 106 this document indicates to that carrier how it was selected. 108 2. Terminology 110 This document uses the following terms: 112 o Long Distance Carrier: a telephone company that provides network 113 transit services to route long-distance calls between different 114 network operators. 116 o Network Operator: a service provider that operates a network for 117 the purpose of providing telephone service to its users. 119 o Operator: when the term "operator" is used on its own (without the 120 "network" qualifier), it refers to the third-party operator that 121 is temporarily connected in an operator-assisted call. The 122 operator may obtain billing information verbally from the caller, 123 such as the identity of the long distance carrier to handle the 124 call. 126 3. Abbreviations 128 ANSI American National Standards Institute 129 BNF Backus-Naur Form 130 CIC Carrier Identification Code (also cic) 131 DAI Dial Around Indicator (also dai) 132 FCC Federal Communications Commission 133 ENUM Telephone Number Mapping 134 GSTN Global Switched Telephone Network 135 GW Gateway 136 IETF Internet Engineering Task Force 137 IP Internet Protocol 138 ISUP Integrated Services Digital Network User Part 139 SS7 Signaling System number 7 140 SW Switch 141 URI Uniform Resource Identifier 143 4. Formal Syntax 145 The following syntax specification uses the Augmented Backus-Naur 146 Form (ABNF) as described in RFC 5234 [RFC5234] and defines the "dai" 147 pname and associated pvalues as an instantiation of the "parameter" 148 production rule of the "tel" URI defined in [RFC3966]. 150 Internet-Draft DAI Parameter for the "tel" URI April 29, 151 2010 153 dai = ";dai=" dai-value 154 dai-value = "no-ind" / 155 "presub" / 156 "presub-da" / 157 "presub-da-unkwn" / 158 "da" / 159 "cic-chrg-pty" / 160 "altcic-chrg-pty" / 161 "verbal-clg-pty" / 162 "verbal-chrg-pty" / 163 "emergency" / 164 "presub-unkwn-da" / 165 "operator" / 166 pvalue 168 The "dai" parameter can appear in the "tel" URI at most once. The 169 "dai" parameter MUST NOT be present if the "cic" parameter is not 170 present. When the "cic" parameter is present due to carrier 171 selection (whether presubscribed or not), the "dai" parameter MUST be 172 present so that its presence in the tel URI can differentiate the 173 carrier selection case from the freephone case. Please see [RFC4694] 174 for the syntax specification of the "cic" parameter. 176 Below are the descriptions of the values of the "dai" parameter. 178 "no-ind": indicates that it is not known how the carrier identified 179 in the CIC was selected. 181 "presub": indicates that the CIC contains the caller's presubscribed 182 carrier; the caller did not dial a Carrier Identification Code. 184 "presub-da": indicates that the CIC contains the caller's dialed 185 Carrier Identification Code; the selected carrier is the caller's 186 presubscribed carrier. 188 "presub-da-unkwn": indicates that the CIC contains the caller's 189 presubscribed carrier; no information is provided on whether or not 190 the caller dialed a Carrier Identification Code. 192 "da": indicates that the CIC contains the caller's dialed carrier- 193 identification-code; the selected carrier is not the caller's 194 presubscribed carrier. 196 "cic-chrg-pty": indicates that the CIC contains the preferred carrier 197 of the charged party. 199 "altcic-chrg-pty": indicates that the CIC contains the alternate 200 carrier of the charged party. 202 Internet-Draft DAI Parameter for the "tel" URI April 29, 203 2010 205 "verbal-clgPty": indicates that the CIC contains the carrier 206 delivered verbally by the calling party. 208 "verbal-chrg-pty": indicates that the CIC contains the carrier 209 delivered verbally by the charged party. 211 "emergency": indicates that the CIC is selected for emergency call 212 handling. 214 "presub-unkwn-da": indicates that the CIC contains the caller's 215 dialed carrier-identification-code; no information is provided on 216 whether or not the selected carrier is the caller's presubscribed 217 carrier. 219 "operator": indicates that the CIC contains a carrier selected by a 220 network operator. 222 5. Normative Rules 224 This section discusses how a network node adds the "dai" parameter to 225 the "tel" URI or handles a received "tel" URI that contains the "dai" 226 parameter. Since the "dai" parameter goes with the "cic" parameter, 227 the latter is included in some of the discussions below. The phone 228 numbers of the caller and called party are geographic numbers in the 229 discussions. 231 When the call signaling message contains a "tel" URI that carries the 232 "cic" parameter, ENUM [RFC3761] could map the phone number in the 233 "tel" URI to other URI(s) such as SIP URI [RFC3261]. In that case, 234 the mapped URI instead of the parameters in the "tel" URI MAY be used 235 to route the call. In this document it is assumed that ENUM is not 236 involved. 238 5.1. Network Model 240 The network model in Figure 1 is used to help describe the rules for 241 sending and receiving the "dai" parameter. The discussion below 242 focuses on the handling of the "tel" URI in the signaling messages. 243 It is assumed that the signaling message will contain the "cic" and 244 "dai" parameters after it leaves "Network Node A" for a call 245 originated by the user or after it leaves "GSTN GW" when the call 246 comes from the GSTN (Global Switched Telephone Network). 248 Internet-Draft DAI Parameter for the "tel" URI April 29, 249 2010 251 +-------------------------------+ 252 | | 253 +---------+ +---------+ +---------+ +---------+ 254 | Network | | Network | | Network | | User | 255 | Node C |-----| Node B |-----| Node A |------| Device | 256 +---------+ +---------+ +---------+ +---------+ 257 | | | 258 | | | 259 | | +---------+ +---------+ 260 | +----------| GSTN | | GSTN | 261 +--------------------------| GW |------| SW | 262 +---------+ +---------+ 264 Figure 1. Network Model 266 "User Device" generates the signaling message requesting a call 267 setup. 269 "Network Node A" represents those network nodes that receive the call 270 request and can analyze the type of call (e.g., local toll, long 271 distance or international based on the calling party number/address 272 and called party number) and determine or identify the carrier that 273 is to handle the call. The latter can be based on the information 274 from the caller (e.g., "101XXXX"), the presubscribed carrier 275 information in the service profile of the caller, or via the 276 involvement of an operator that interacts with the calling party, 277 called party (e.g., for collect call) or a third party (e.g., when 278 the call is charged to a third party) for an operator-assisted call. 279 If configured by the network operator, Node A can apply a preferred 280 CIC for all calls where carrier selection is needed. Note that 281 although Figure 1 shows Node A as a single entity, its 282 responsibilities can be shared amongst multiple Node As such that the 283 Node A that is connected to or communicates with the user device is 284 separate from the Node A that determines or identifies the carrier to 285 handle the call. 287 "Network Node B" represents those network nodes that are not 288 associated with the carrier identified in the "cic" parameter and 289 need to route the signaling message that contains the "cic" and "dai" 290 parameters towards the carrier identified in the "cic" parameter. 292 "Network Node C" represents those network nodes that receive the 293 signaling message from "Network Node B" and belongs to the carrier 294 identified in the "cic" parameter. 296 "GSTN GW" stands for "Global Switched Telephone Network (GSTN) 297 Gateway (GW)". It interfaces between the Internet Protocol (IP) 299 Internet-Draft DAI Parameter for the "tel" URI April 29, 300 2010 301 domain and the GSTN domain for signaling protocols and the user 302 traffic. The GSTN includes the wireline network, wireless network 303 and other circuit-switched networks. Signaling traffic and user 304 traffic could be handled by separate network nodes. In this 305 document, both types of traffic are handled by "GSTN GW" to simplify 306 the discussion. 308 "GSTN Switch (SW)" is a circuit switch in the GSTN that is connected 309 with the GSTN GW. 311 "User Device", "Network Node A", "Network Node B" and "Network Node 312 C" are in the IP domain. "Network Node A", "Network Node B" and 313 "Network Node C" can route the calls to the GSTN via the GSTN GW. 315 The rules for various scenarios are described below. 317 5.2. Adding the "dai" Parameter to the "tel" URI 319 This section discusses those cases where "Network Node A" receives a 320 call request containing a "tel URI" from "User Device" and may need 321 to add the "dai" parameter to the "tel" URI. If the "cic" Parameter 322 is included in the received "tel URI" but the "dai" Parameter is not 323 included, and "Network Node A" does not know how the carrier is 324 selected or does not want to reveal how the carrier is selected 325 (based on local policy), "Network Node A" MUST include the "dai" 326 Parameter and set it to "no-ind". If "Network Node A" does know how 327 the carrier is selected, and does want to reveal this information, 328 then it MUST include a "dai" parameter as described in the following 329 sub-sections. 331 DAI information has potential billing impacts, and it is therefore 332 important that it is trustworthy. "Network Node A" may have a trust 333 relationship with "User Device" whereby it trusts the information 334 provided by "User Device". In such cases, "Network Node A" may use 335 the DAI information provided by "User Device". In all other cases, 336 "Network Node A" MUST remove any DAI information provided by "User 337 Device" before further processing. Furthermore, the signaling message 338 including the "tel URI" SHOULD be hop-by-hop integrity-protected, 339 e.g. by the use of TLS in the case of SIP. If it is not, the 340 parameters provided cannot be trusted. 342 5.2.1. CIC Information Provided in Call Signaling from "User Device" 344 When an originating user dials the carrier prefix digits to select a 345 carrier at call setup time, "User Device" MUST signal the CIC 346 information to "Network Node A". "User Device" can provide the CIC 347 information via call signaling in one of two ways. 349 Internet-Draft DAI Parameter for the "tel" URI April 29, 350 2010 351 1. Include the "cic" parameter in the "tel" URI to carry the selected 352 CIC. It is outside the scope of this document as to how "User 353 Device" adds the "cic" parameter to the "tel" URI. 355 2. Include the selected CIC information in the dialed string (e.g., 356 "101XXXX" followed by a national number). [RFC4967] specifies one 357 way to deliver the dialed string in the SIP protocol [RFC3261]. 358 How the dialed string is carried in the signaling message to 359 "Network Node A", and how "Network Node A" identifies the CIC 360 information and the called phone number from the received dialed 361 string is outside the scope of this document. "Network Node A" 362 MUST convert the received dial string to a valid "tel" URI 363 containing a "cic" parameter (by means outside the scope of this 364 document), and continue processing as if the "tel" URI had been 365 received from the "User Device". 367 When receiving a call request that contains the "tel" URI "cic" 368 parameter but not the "dai" parameter (or on converting a received 369 dialed string to a "tel" URI containing a "cic" parameter), and an 370 operator is not involved in call handling, "Network Node A" MUST 371 follow the rules described below. The cases where an operator is 372 involved in determining/selecting a carrier to handle the call are 373 addressed in 4.2.3 and 4.2.4 below. 375 o If the call is to be handled by the carrier "Network Node A" is 376 associated with (that is, the carrier network is the network 377 within which Node A resides), "Network Node A" MUST remove the 378 "cic" parameter in the "tel" URI, and MUST NOT include the "dai" 379 parameter if it needs to forward the signaling message to another 380 network node. 382 o If "Network Node A" selects a carrier for the call (e.g., because 383 local policy does not allow the caller to specify a carrier), and 384 the selected carrier is different than the caller's pre-subscribed 385 carrier, or the caller does not have a pre-subscribed carrier, 386 then "Network Node A" MUST update the received "cic" parameter to 387 identify the selected carrier. In addition, "Network Node A" MUST 388 add a "dai" parameter containing the value "operator" to the "tel" 389 URI. 391 o If the "User Device" specified carrier is the same as the caller's 392 pre-subscribed carrier and "Network Node A" knows that the CIC 393 information is provided by "User Device", and "Network Node A" 394 chooses (based on local policy) to reveal that the presubscribed 395 carrier was selected by the user, then "Network Node A" MUST set 396 the "dai" parameter to "presub-da" and include the parameter in 397 the "tel" URI. 399 Internet-Draft DAI Parameter for the "tel" URI April 29, 400 2010 401 o If "Network Node A" is not sure whether the CIC information is 402 provided by "User Device" (e.g., a proxy server between "User 403 Device" and "Network Node A" is involved), and the specified 404 carrier is the same as the caller's pre-subscribed carrier, then 405 "Network Node A" MUST set the "cic" parameter to contain the 406 caller's pre-subscribed carrier's CIC and include the parameter, 407 if not yet present, in the "tel" URI. "Network Node A" MUST set 408 the "dai" parameter to "presub-da-unkwn" and include the parameter 409 in the "tel" URI. 411 o If the "User Device" specified carrier is different from the 412 caller's pre-subscribed carrier, "Network Node A" MUST set the 413 "cic" parameter to contain the "User Device" specified carrier and 414 include the parameter, if not yet present, in the "tel" URI. 415 "Network Node A" MUST set the "dai" parameter to "da" and include 416 the parameter in the "tel" URI. 418 o If the "User Device" specifies a carrier and "Network Node A" 419 cannot determine if the selected carrier is the caller's 420 presubscribed carrier, or "Network Node A" chooses (based on local 421 policy) not to reveal whether the selected carrier is the 422 presubscribed carrier, or there is no presubscribed carrier 423 assigned to the caller, then "Network Node A" MUST set the "cic" 424 parameter to contain the "User Device" specified carrier and 425 include the parameter, if not yet present, in the "tel" URI. 426 "Network Node A" MUST set the "dai" parameter to "presub-unkwn-da" 427 and include the parameter in the "tel" URI. 429 5.2.2. CIC Information Not Provided in Call Signaling From "User 430 Device" 432 In this scenario, "User Device" did not provide any CIC information 433 in call signaling and an operator is not involved in call handling. 434 "Network Node A" MUST follow the rules described below. The cases 435 where an operator is involved in determining/selecting a carrier to 436 handle the call are addressed in 4.2.3 and 4.2.4 below. 438 o If the call is to be handled by the carrier "Network Node A" is 439 associated with, "Network Node A" MUST NOT include the "cic" and 440 "dai" parameters in the "tel" URI if it needs to forward the 441 signaling message to another network node. 443 o If "Network Node A" selects a carrier that is different from the 444 caller's pre-subscribed carrier to handle the call, it MUST set 445 the "cic" parameter to contain the CIC it selects and include the 446 parameter in the "tel" URI. "Network Node A" MUST include the 447 "dai" parameter in the "tel" URI and set it to "operator". 449 Internet-Draft DAI Parameter for the "tel" URI April 29, 450 2010 451 o If the caller has a pre-subscribed carrier that can handle the 452 call, "Network Node A" MUST set the "cic" parameter to contain the 453 caller's pre-subscribed carrier's CIC and include the parameter in 454 the "tel" URI. "Network Node A" MUST set the "dai" parameter to 455 "presub" and include the parameter in the "tel" URI. 457 5.2.3. Operator-assisted Call Handling, Caller Pays for the Call 459 When an operator is involved in handling the call request from the 460 caller, "Network Node A" may or may not have the CIC information 461 available from the signaling message. If the caller is to pay for 462 the call, the operator may interact with the caller to determine the 463 carrier to handle the call when applicable. If the CIC information 464 is available from call signaling and the operator also interacts with 465 the caller to get the CIC information, the CIC provided by the 466 operator MUST be used. How the caller indicates an operator-assisted 467 call and passes the CIC information in call signaling is outside the 468 scope of this document. 470 "Network Node A" through the assistance of an operator MUST follow 471 the rules described below. 473 o If the call is to be handled by the carrier "Network Node A" is 474 associated with, "Network Node A" MUST remove the "cic" parameter, 475 if present in the "tel" URI, and MUST NOT include the "dai" 476 parameter if it needs to forward the signaling message to another 477 network node. 479 o If "Network Node A" selects a carrier other than the caller's pre- 480 subscribed carrier or the one specified by "User Device" in call 481 signaling or indicated verbally by the caller to the operator, 482 "Network Node A" MUST set the "cic" parameter to contain the CIC 483 it selects and include the parameter, if not yet present, in the 484 "tel" URI. "Network Node A" MUST include the "dai" parameter in 485 the "tel" URI and set it to "operator". 487 o If the carrier specified by "User Device" in call signaling or 488 indicated verbally by the caller to the operator is selected by 489 "Network Node A", and is the same as the caller's pre-subscribed 490 carrier, "Network Node A" MUST set the "cic" parameter to contain 491 the caller's pre-subscribed carrier's CIC and include the 492 parameter, if not yet present, in the "tel" URI. "Network Node A" 493 MUST set the "dai" parameter to "presub-da" and include the 494 parameter in the "tel" URI. 496 Internet-Draft DAI Parameter for the "tel" URI April 29, 497 2010 498 o If "Network Node A" is not sure whether the CIC information is 499 provided by "User Device" or the operator did not indicate if the 500 CIC information came from the caller (either verbally or dialed), 501 and the CIC provided is the same as the caller's presubscribed 502 carrier, then "Network Node A" MUST set the "dai" parameter to 503 "presub-da-unkwn" in the process described above. 505 o If the carrier specified by "User Device" in call signaling or 506 verbally by the caller to the operator is different from the 507 caller's pre-subscribed carrier, and that carrier is being used, 508 "Network Node A" MUST set the "cic" parameter to contain the CIC 509 of the selected carrier and include the parameter, if not yet 510 present, in the "tel" URI. "Network Node A" MUST set the "dai" 511 parameter to "da" and include the parameter in the "tel" URI. 513 o If the operator receives verbal instructions from the caller to 514 use a specific carrier and it is not known if that carrier is the 515 caller's presubscribed carrier, or "Network Node A" chooses (based 516 on local policy) not to reveal whether the selected carrier is the 517 presubscribed carrier, or there is no presubscribed carrier 518 assigned to the caller, then "Network Node A" MUST set the "cic" 519 parameter to contain the CIC of the specified carrier and include 520 the parameter, if not yet present, in the "tel" URI. "Network 521 Node A" MUST set the "dai" parameter to "verbal-clgPty" and 522 include the parameter in the "tel" URI. 524 5.2.4. Operator-assisted Call Handling, Called Party or Third Party 525 Pays for the Call 527 There are cases where the call is charged to the called party or a 528 third party. How the caller indicates an operator-assisted call and 529 passes the CIC information in call signaling is outside the scope of 530 this document. The caller will indicate to the operator that either 531 the called party or a third party is to pay for the call. The 532 operator then checks with the charged party if he/she agrees to pay 533 for the call and may verbally get the CIC information from the 534 charged party or retrieve the primary and alternate preferred carrier 535 information from some databases. It is assumed that the "tel" URI in 536 the call signaling from "User Device" does not contain the "cic" 537 parameter and/or "dai" parameter: They MUST be ignored if they are 538 present. 540 "Network Node A" through the assistance of an operator MUST follow 541 the rules described below. 543 Internet-Draft DAI Parameter for the "tel" URI April 29, 544 2010 545 o If the call is to be handled by the carrier "Network Node A" is 546 associated with, "Network Node A" MUST remove the "cic" parameter, 547 if present, and MUST NOT include the "dai" parameter in the "tel" 548 URI. 550 o If "Network Node A" selects a carrier other than the carrier 551 identified by the operator to handle the call, it MUST set the 552 "cic" parameter to contain the CIC it selects and include the 553 parameter in the "tel" URI. "Network Node A" MUST include the 554 "dai" parameter in the "tel" URI and set it to "operator". 556 o If the charged party's primary preferred carrier is indicated by 557 the operator, and that carrier is used for the call handling, 558 "Network Node A" MUST set the "cic" parameter to contain that 559 carrier's CIC and include the parameter in the "tel" URI. 560 "Network Node A" MUST set the "dai" parameter to "cic-chrg-pty" 561 and include the parameter in the "tel" URI. How "Network Node A" 562 knows that the selected carrier is the charged party's primary 563 preferred carrier is outside the scope of this document. 565 o If the charged party's alternate preferred carrier is indicated by 566 the operator, and that carrier is used for the call handling, then 567 "Network Node A" MUST set the "cic" parameter to contain that 568 carrier's CIC and include the parameter in the "tel" URI. 569 "Network Node A" MUST set the "dai" parameter to "altcic-chrg-pty" 570 and include the parameter in the "tel" URI. How "Network Node A" 571 knows that the selected carrier is the charged party's alternate 572 preferred carrier is outside the scope of this document. 574 o If the operator receives verbal instructions from the charged 575 party to use a specific carrier and it is not known if that 576 carrier is the charged party's primary or alternate preferred 577 carrier, then "Network Node A" MUST set the "cic" parameter to 578 contain the CIC of the specified carrier and include the parameter 579 in the "tel" URI. "Network Node A" MUST set the "dai" parameter 580 to "verbal-chrg-pty" and include the parameter in the "tel" URI. 582 o If the caller contacts an operator for an emergency situation and 583 a carrier that "Network Node A" is not associated with needs to 584 handle the call, "Network Node A" MUST set the "cic" parameter to 585 the CIC of that carrier and include the parameter in the "tel" 586 URI. "Network Node A" MUST set the "dai" parameter to "emergency" 587 and include the parameter in the "tel" URI. 589 5.2.5. Call Signaling Received From the GSTN SW by GSTN GW 591 The GSTN GW may receive the Signaling System number 7 (SS7) 592 Integrated Services Digital Network User Part (ISUP) signaling 593 message from the GSTN SW that contains the CIC information. For 595 Internet-Draft DAI Parameter for the "tel" URI April 29, 596 2010 597 example, American National Standards Institute (ANSI) ISUP carries 598 the CIC information in the "Carrier Selection Information" parameter. 599 The mapping between the "dai" parameter and ISUP is outside the scope 600 of this document. 602 5.2.6. CIC and DAI Information is Provided in Call Signaling From 603 "User Device" 605 This section describes the cases where the network operator 606 configures the "User Device" to provide the user-dialed or pre- 607 subscribed CIC, and the corresponding DAI information, to "Network 608 Node A". The mechanism to configure the "User Device" is outside the 609 scope of this document. 611 When the "User Device" is configured to provide the CIC and DAI 612 information to "Network Node A", it MUST insert the "tel" URI "cic" 613 and "dai" parameters in the call signaling toward "Network Node A" as 614 follows: 616 o If the caller-dialed carrier is the same as the caller's pre- 617 subscribed carrier, and the "User Device" inserts the "dai" 618 parameter in call signaling, the "User Device" MUST set the "dai" 619 parameter to "presub-da" and include the parameter in the "tel" 620 URI. 622 o If the caller-dialed carrier is different from the caller's pre- 623 subscribed carrier, and the "User Device" inserts the "dai" 624 parameter in call signaling, the "User Device" MUST set the "dai" 625 parameter to "da" and include the parameter in the "tel" URI. 627 o If the caller dials a carrier, and the "User Device" inserts the 628 "dai" parameter in call signaling, and "User Device" cannot 629 determine if the selected carrier is the caller's presubscribed 630 carrier, then "User Device" MUST set the "dai" parameter to 631 "presub-unkwn-da" and include the parameter in the "tel" URI. 633 o If the caller does not dial a carrier, and the "User Device" 634 inserts the caller's pre-subscribed carrier information and the 635 "dai" parameter in call signaling, then "User Device" MUST set the 636 "dai" parameter to "presub" and include the parameter in the "tel" 637 URI. 639 When receiving a call request containing the "tel" URI "cic" and 640 "dai" parameters from a "User Device" which is configured to send 641 these parameters, and an operator is not involved in call handling, 642 "Network Node A" MUST NOT alter "cic" and "dai" parameters in the 643 "tel" URI. The cases where an operator is involved in 644 determining/selecting a carrier to handle the call are addressed in 645 4.2.3 and 4.2.4. 647 Internet-Draft DAI Parameter for the "tel" URI April 29, 648 2010 650 5.3. Routing Calls Based on "tel" URI Containing "cic" and "dai" 652 This section discusses how "Network Node A", "Network Node B", 653 "Network Node C" or "GSTN GW" handles the signaling messages that 654 contain the "dai" and "cic" parameters in the "tel" URI. Scenarios 655 that do not involve the "dai" parameter in the "tel" URI are outside 656 the scope of this document. 658 DAI information has potential billing impacts, and it is therefore 659 important that it is trustworthy. It is assumed that all of the 660 Network Nodes have a trust relationship with each other whereby they 661 trust the DAI information provided. In all other cases, the Network 662 Node MUST remove any DAI information provided before further 663 processing. Furthermore, the signaling message including the "tel 664 URI" SHOULD be hop-by-hop integrity-protected, e.g. by the use of TLS 665 in the case of SIP. If it is not, the parameters provided cannot be 666 trusted. 668 5.3.1. Network Node A 670 After "Network Node A" has added the "dai" parameter and/or "cic" 671 parameter to the "tel" URI and is ready to route the call, it MUST 672 route the call based on the rules described in [RFC4694] to "Network 673 Node B", "Network Node C" or "GSTN GW". "Network Node A" MAY record 674 the "dai" value in the call detail record. If the carrier that 675 Network A is associated with is the one to handle the call, Network 676 Node A MUST remove the "cic" and/or "dai" if they are present before 677 routing the call. 679 5.3.2. Network Node B 681 Since "Network Node B" is not associated with the carrier identified 682 by the CIC in the "cic" parameter, it MUST route the call based on 683 the "cic" parameter as stated in [RFC4694] to another "Network Node 684 B", "Network Node C" or "GSTN GW". "Network Node B" MAY record the 685 "dai" value in the call detail record. 687 5.3.3. Network Node C 689 Since "Network Node C" is associated with the carrier identified by 690 the CIC in the "cic" parameter, it MUST remove the "cic" parameter 691 and the "dai" parameter, if present, before it determines how to 692 handle the call. "Network Node C" MAY record the "dai" value in the 693 call detail record. How "Network Node C" continues the call 694 routing/handling is outside the scope of this document. 696 Internet-Draft DAI Parameter for the "tel" URI April 29, 697 2010 698 5.3.4. GSTN GW 700 If "GSTN GW" determines that the call is to be routed from the IP 701 domain to "GSTN SW", and SS7 ISUP is used in the GSTN, then the "GSTN 702 GW" MUST map the "dai" parameter to the corresponding ISUP parameter. 703 For example, when interworking with ANSI ISUP, the "dai" parameter is 704 mapped to the ISUP "Carrier Selection Information" parameter. 706 When "GSTN GW" receives a signaling message from "GSTN SW" that 707 contains the carrier selection information, it MUST set the "dai" 708 parameter based on the received carrier selection information. "GSTN 709 GW" MUST route the call based on the "cic" parameter as stated in 710 [RFC4694] to "Network Node A", "Network Node B" or "Network Node C". 711 "GSTN GW" MAY record the "dai" value in the call detail record. 713 The mapping between the "dai" parameter and ISUP is outside the scope 714 of this document. 716 5.3.5. User Device 718 "User Device" is not expected to receive signaling messages that 719 contain the "dai" and/or "cic" parameters. If the received signaling 720 messages contain the "tel" URI with the "dai" and/or "cic" 721 parameters, "User device" SHALL ignore the parameter(s). 723 6. Examples 725 1. A caller whose pre-subscribed carrier has a CIC of "+1-6789" makes 726 an outbound call with the following "tel" URI: 728 tel:+1-202-533-1234 730 "Network Node A" adds the "dai" and "cic" parameters to the "tel" 731 URI as shown follows: 733 tel:+1-202-533-1234;cic=+1-6789;dai=presub 735 2. A caller whose pre-subscribed carrier has a CIC of "+1-6789" makes 736 an outbound call to +1-202-533-1234 and specifies to use the CIC 737 of "+1-2345" in call signaling with the following "tel" URI: 739 tel:+1-202-533-1234;cic=+1-2345 741 "Network Node A" recognizes that the caller has selected a non- 742 presubscribed carrier to handle the call. "Network Node A" adds 743 the "dai" parameter to the "tel" URI as shown follows: 745 tel:+1-202-533-1234;cic=+1-2345;dai=da 747 Internet-Draft DAI Parameter for the "tel" URI April 29, 748 2010 750 3. A caller makes a collect call to +1-202-533-1234 through an 751 operator. The operator at "Network Node A" interacts with the 752 called party and gets a verbal approval to use the CIC of "+1- 753 3456". "Network Node A" adds the "dai" and "cic" parameters to 754 the "tel" URI as follows: 756 tel:+1-202-533-1234;cic=+1-3456;dai=verbal-chrg-pty 758 7. Security Considerations 760 In addition to those security implications discussed in [RFC3966], 761 there may be new security implications associated with the "dai" 762 parameter depending on the carrier who uses the information. 764 Changing the content of the "dai" parameter may cause a call to be 765 rejected by or cause some problems (e.g., collecting call charge) to 766 the carrier who handles the call. For example, changing from 767 "presub" to "da" may cause the call to be rejected if the carrier 768 that is to handle the call only handles calls from its pre-subscribed 769 subscribers. Changing "da" to "presub" may cause a call that would 770 be rejected to be processed by a carrier who later finds out it 771 cannot collect the call charge from the caller or has to pay more 772 than the call charge to collect the call charge from the caller via a 773 third party (e.g., local exchange carrier). 775 DAI information has potential billing impacts, and it is therefore 776 important that it is trustworthy. "Network Node A" may have a trust 777 relationship with "User Device" whereby it trusts the information 778 provided by "User Device". In such cases, "Network Node A" may use 779 the DAI information provided by "User Device". In all other cases, 780 "Network Node A" MUST remove any DAI information provided by "User 781 Device" before further processing. 783 It is assumed that all of the Network Nodes have a trust relationship 784 with each other whereby they trust the DAI information provided. In 785 all other cases, the Network Node MUST remove any DAI information 786 provided before further processing. 788 It is RECOMMENDED that protocols carrying the "tel" URI provide hop 789 by hop integrity protection for the signaling messages including the 790 URI and its associated parameters. This allows detection of any 791 unauthorized changes to the contents of the "tel" URI. If integrity 792 protection is not used, the parameters provided cannot be trusted. 794 Please note that the information in the "dai" parameter may not be 795 authenticated; therefore, the use of the information by the recipient 796 of the "tel" URI is done at its own risk. 798 Internet-Draft DAI Parameter for the "tel" URI April 29, 799 2010 801 8. IANA Considerations 803 The "dai" parameter defined in this document needs to be registered 804 with IANA as a new parameter for the "tel" URI [RFC3966]. 806 1. Parameter name - dai 807 Applicability - used to indicate how a carrier was chosen for 808 handling a call 809 Mandatory or optional - optional 810 Restrictions on syntax - see Section 4. 811 Reference to a specification - defined in this document 813 9. References 815 9.1. Normative References 817 [RFC2119] S. Bradner, RFC 2119, "Key words for use in RFCs to 818 Indicate Requirement Levels", March 1997. 820 [RFC3966] H. Schulzrinne, RFC 3966, "The tel URI for Telephone 821 Numbers", December 2004. 823 [RFC5234] D. Crocker and P. Overell, RFC 5234, "Augmented BNF for 824 Syntax Specifications: ABNF", January 2008. 826 [RFC4694] J. Yu, RFC 4694, "NP Parameters for the "tel" URI", October 827 2006. 829 9.2. Informative References 831 [RFC3261] J. Rosenberg, et al., RFC 3261, "SIP: Session Initiation 832 Protocol", June 2002. 834 [RFC3761] P. Faltstrom and M. Mealling, RFC 3761, "The E.164 to 835 Uniform Resource Identifiers (URI) - Dynamic Delegation Discovery 836 System (DDDS) Application (ENUM)", April 2004. 838 [RFC4967] B. Rosen,RFC 4967, "Dial String Parameter for the Session 839 Initiation Protocol Uniform Resource Identifier ", July 2007. 841 10. Change History 842 (Note to editor - please remove this section in final version.) 844 10.1. Changes from version 01->02 846 - Section 3: clarified descriptions of "dai" parameter values 848 Internet-Draft DAI Parameter for the "tel" URI April 29, 849 2010 850 - Section 4.2.5, plus various other places: removed text that said 851 the "dai" parameter was not included in certain cases, since we 852 now use "no-ind" these cases. 853 - Section 4.3, 854 o Item A: added text specifying that if Node-A is the carrier 855 then it removes "cic" 856 o Item D: added procedures for inbound calls from GSTN 858 10.2. Changes from version 02->03 860 - Section 4.2 is updated to indicate that the "User Device" may 861 insert the "dai" parameter. 862 - Section 4.2.6 is added to include procedures when the "User 863 Device" inserts the "dai" parameter. 865 10.3. Changes from version 03->04 867 - Added note to Section 4.2 (and similar note to other sections) 868 describing the billing implications DAI, and the trust issues 869 related to the network accepting it from the "User Device". 871 10.4. Changes from version 04->05 873 - Clarified semantics of certain "dai" values in Section 3. 875 10.5. Changes from version 05->06 877 - Clarified semantics of "presub-unkwn-da" in Section 3. 878 - Section 4.2.1, 4th bullet, clarified that the "presub-da-unkwn" 879 case applies when the received carrier matches the presubscribed 880 carrier. Also added text to make 4th bullet stand-alone, instead of 881 referring to previous bullet. 882 - Fixed typos. 884 10.6. Changes from version 06->07 885 Section 4.2.1 886 - Updated point 2 to make result of the dialed-string case the same 887 as receiving tel URI containing a "cic" parameter. Updated and 888 simplified the following bullets to take advantage of this change, 889 since they could be written assuming "cic" parameter was always 890 present. 891 - Updated 2nd bullet to add case where caller does not have a pre- 892 subscribed carrier 893 - Updated 3rd bullet to clarify that "presub-da" is driven by local 894 policy setting to reveal that the presubscribed carrier was selected 895 by the user 897 Internet-Draft DAI Parameter for the "tel" URI April 29, 898 2010 899 - Updated 6th bullet to clarify that network-node-A sets the "DAI" 900 parm to "presub-unkwn-da" based on local policy, or because there is 901 no presubscribed carrier. 903 10.7. Changes from version 07->08 905 - Added new Terminology section-2 906 - Section 4 - updated syntax to all lower case. 907 - Section 5.2 - Clarified that sub-sections cover the case where 908 Node-A knows and wants to reveal the "dai" value 909 - Section 5.2.3 - clarified throughout that operator can receive CIC 910 either in signaling from user device, or verbally from user. 911 - Section 5.2.4 912 o Updated title; original title inadvertently included freephone 913 calls 914 o Clarified throughout that these are operator-assisted calls 915 - Section 5.2.5 and 5.3.4 - removed text that says there's a 1:1 916 mapping between ANSI and ISUP, and clearly sated that DAI-ISUP 917 mapping is out-of-scope 918 - Section 5.3 - Clarified title to distinguish this section from 919 5.2. 920 - Section 8 - corrected reference to section in this document that 921 defines syntax of the new "dai" parameter 923 10.8. Changes from version 08->09 925 Resubmitted to restart expiration timer. 927 Acknowledgments 929 The authors would like to thank Martin Dolly and Penn Pfautz for 930 their assistances in providing the relevant information on the DAI. 932 Authors' Addresses 934 James Yu 935 NeuStar, Inc. 936 46000 Center Oak Plaza 937 Sterling, VA 20166 938 U.S.A. 939 Phone: +1-571-434-5572 940 Email: james.yu@neustar.biz 942 David Hancock 943 CableLabs 944 858 Coal Creek Circle 945 Louisville, CO 80027-9750 946 U.S.A. 948 Internet-Draft DAI Parameter for the "tel" URI April 29, 949 2010 950 Phone: +1-303-661-3381 951 Email: d.hancock@cablelabs.com 953 Flemming Andreasen 954 Cisco Systems, Inc. 955 499 Thornall Street, 8th Floor 956 Edison, NJ 08837 957 U.S.A. 958 Email: fandreas@cisco.com 960 Copyright Statement 962 Copyright (c) 2009 IETF Trust and the persons identified as the 963 document authors. All rights reserved. 965 This document is subject to BCP 78 and the IETF Trust's Legal 966 Provisions Relating to IETF Documents 967 (http://trustee.ietf.org/license-info) in effect on the date of 968 publication of this document. Please review these documents 969 carefully, as they describe your rights and restrictions with respect 970 to this document. 972 This document may contain material from IETF Documents or IETF 973 Contributions published or made publicly available before November 974 10, 2008. The person(s) controlling the copyright in some of this 975 material may not have granted the IETF Trust the right to allow 976 modifications of such material outside the IETF Standards Process. 977 Without obtaining an adequate license from the person(s) controlling 978 the copyright in such materials, this document may not be modified 979 outside the IETF Standards Process, and derivative works of it may 980 not be created outside the IETF Standards Process, except to format 981 it for publication as an RFC or to translate it into languages other 982 than English. 984 Acknowledgment 986 Funding for the RFC Editor function is provided by the IETF 987 Administrative Support Activity (IASA).