idnits 2.17.1 draft-mohali-dispatch-cause-for-service-number-14.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4458, updated by this document, for RFC5378 checks: 2003-10-20) -- 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 (January 31, 2017) is 2643 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mohali 3 Internet-Draft Orange 4 Updates: 4458 (if approved) M. Barnes 5 Intended status: Informational MLB@Realtime Communications 6 Expires: August 4, 2017 January 31, 2017 8 Session Initiation Protocol (SIP) Cause URI parameter for Service Number 9 translation 10 draft-mohali-dispatch-cause-for-service-number-14.txt 12 Abstract 14 RFC4458 (SIP URIs for applications) defines a "cause" URI parameter, 15 which may appear in the Request-URI of a SIP request, that is used to 16 indicate a reason why the request arrived to the User Agent Server 17 (UAS) receiving the message. This document creates a new predefined 18 value for the "cause" URI parameter to cover service number 19 translation for cases of retargeting due to specific service action 20 leading to the translation of a called service access number. This 21 document also provides guidance, which was missing in RFC4458, for 22 using the "cause" URI parameter within the History-Info header field 23 since this use is mandatory in some IP networks' implementations. 25 This document updates RFC4458. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 4, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Table of Contents 58 1. Introduction, Terminology and Overview . . . . . . . . . . . 2 59 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Interaction with Request History Information . . . . . . 4 62 3.2. Handling and Processing the Service Number Translation 63 "cause" URI parameter value . . . . . . . . . . . . . . . 5 64 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction, Terminology and Overview 75 [RFC4458] defines a mechanism to identify retargeting due to call 76 forwarding supplementary services. The "cause" URI parameter in the 77 target URI identifies the reason for retargeting and has defined 78 values equivalent to the TDM (Time Division Multiplexing) Redirecting 79 Reasons [ITU-T_Q.763]. The concept of "retargeting" is defined in 80 [RFC7044]. 82 In the Public Switched Telephone Network (PSTN)/ Integrated Services 83 Digital Network (ISDN), there is another kind of retargeting 84 introduced by the Intelligent Network (IN) services based on a 85 translation of the called number as mentioned in [ITU-T_Q.1214]. 86 Indeed, IN aims to ease the introduction of new services (i.e. 87 Universal Personal Telecommunication (UPT), Virtual Private Network 88 (VPN), Freephone, etc.) based on greater flexibility and new 89 capabilities as described in [ITU-T_I.312_Q.1201]. For these IN 90 services, ISUP introduced the "called IN number" and the "original 91 called IN number" parameters to capture the information of the 92 requested service access number prior its translation [ITU-T_Q.763]. 94 The term "service access number" is used in this specification to 95 refer to the dialable number by which a specific service is reached. 96 This special number is not a globally routable number and therefore 97 needs to be translated into a routable SIP or tel URI to process the 98 session establishment. 100 This specification proposes a solution to allow the identification of 101 well-known services such as premium or toll free services that 102 perform service access number translation, and to enable interworking 103 with SIP signaling with the ISUP Called IN number and Original Called 104 IN numbers parameters. 106 The mechanism will allow a SIP network to insert and convey the 107 service access number requested prior its translation to the final 108 destination. 110 In order to provide full call forwarding or access number translation 111 services, usage of the "cause" URI parameter is only relevant within 112 the History-Info header field defined in [RFC7044]. Because this 113 relation has not been described in [RFC4458], this document provides 114 guidance for using the "cause" URI parameter in conjunction with the 115 History-Info header field. 117 This document also answers a need expressed by the 3rd-Generation 118 Partnership Project (3GPP) [TS.3GPP.24.229] to identify the service 119 access number. The procedures it defines are intended for networks 120 that use 3GPP defined services. Their use is undefined for other 121 networks. 123 2. Solution 125 A new value for the "cause" URI parameter of the 'sip:' or 'sips:' 126 URI schemes is defined for "Service number translation" use case. 127 This value may be used in a 'sip:' or 'sips:' URI inserted in the 128 Request-URI and in the History-Info header field [RFC7044] when the 129 URI is issued from a retargeting or a service access number 130 translation by a specific service similar to PSTN/ISDN IN services 131 that is not a call forwarding service. 133 As defined in [RFC4458], the cause URI parameter must be encoded in 134 the new target URI when generated by the service. 136 The ABNF grammar [RFC5234] for the cause-param and target-param 137 parameters is summarized below as it has been subject to Errata [ID: 138 1409] in [RFC4458]. The Status-Code is defined in [RFC3261]. 140 target-param = "target=" pvalue 142 cause-param = "cause=" Status-Code 143 The following value for this URI parameter is added to the existing 144 ones: 146 +---------------------------------+-------+ 147 | Cause | Value | 148 +---------------------------------+-------+ 149 | Service number translation | 380 | 150 +---------------------------------+-------+ 152 3. Guidelines 154 In order to help implementation of this solution for conveyance of 155 the service access number, this document proposes guidance for usage 156 of the "cause" URI parameter: a guidance for the "cause" URI 157 parameter usage in the request history information in section 3.1 and 158 a guidance for processing a service number translation service using 159 the new "cause" URI parameter value in section 3.2. 161 3.1. Interaction with Request History Information 163 The History-Info header field defined in [RFC7044] specifies a means 164 of providing the UAS and UAC with information about the retargeting 165 of a request. This information includes the initial Request-URI and 166 any retargeted URIs. This information is placed in History-Info 167 headers as the request is retargeted and, upon reaching the UAS, is 168 returned in certain responses. The History-Info header field enables 169 many enhanced services by providing the information as to how and why 170 a SIP request arrives at a specific application or user and to keep 171 this information throughout the signaling path even when successive 172 applications are involved. 174 When a proxy inserts a URI containing the "cause" URI parameter 175 defined in [RFC4458] into the Request-URI of a forwarded request, per 176 [RFC7044], the proxy must also copy this new Request-URI within a 177 History-Info header field entry into the forwarded request, and so 178 the URI in that entry includes the "cause" URI parameter. Therefore, 179 even if the Request-URI is replaced as a result of rerouting by a 180 downstream proxy, the History-Info header field will still contain 181 these parameters, which can be of use to the UAS. Note that if a 182 proxy does not support generation of the History-Info header field or 183 if a downstream proxy removes the History-Info header fields, an 184 application will only have access to the "cause" URI parameter if the 185 request is not subsequently retargeted (i.e., it will be contained 186 only in the Request-URI in the incoming request). The implications 187 of the solution are further discussed in section Section 3.2. 189 In order to be able to filter specific entries among the history 190 information, header field parameters have been defined in [RFC7044]. 192 In particular, the "mp" and "rc" header field parameters having the 193 following definitions: The "mp" header field parameter is added when 194 the new target was determined based on a mapping to a user other than 195 the target user associated with the Request-URI being retargeted. 196 This allows identifying retargets that are the result of a decision 197 made by a particular type of application or that an initial request 198 has been retargeted as a result of an application decision in a 199 general manner. The "rc" header field parameter is added when the 200 new target represents a change in Request-URI, while the target user 201 remains the same. These header field parameters can be used in 202 conjunction with the new "cause" URI parameter for certain 203 applications, an example of which is provided in section Section 4. 205 When using the History-Info header field in conjunction with the 206 "cause" URI parameter in a Request-URI, it is important to consider 207 that the "cause" URI parameter is not the same parameter as the 208 "cause" header field parameter included in the Reason header 209 [RFC3326]. The "cause" header field parameter of the Reason header 210 field should be added to a History-Info entry only when the 211 retargeting is due to a received SIP response. 213 3.2. Handling and Processing the Service Number Translation "cause" URI 214 parameter value 216 At the Application Server: 218 When an application receiving a request that is addressed to a 219 service access number changes the Request-URI into a routable 220 number, it should insert within this new Request-URI a "cause" URI 221 parameter value set to 380 "Service Number Translation". 222 Following the process described in [RFC7044], the application 223 server adds a new History-Info header field entry including the 224 new Request-URI value including the "cause" URI parameter. It is 225 also possible for an application server to add a "target" URI 226 parameter as defined in [RFC4458] with the initial value of the 227 Request-URI received by the application server. 229 Note that if the new Request-URI is further replaced by a downstream 230 proxy for any reason and if the History-Info header field is not 231 supported, the information of the service access number initially 232 requested would be lost. Thus, it is strongly recommended to support 233 the History-Info header field all along the signaling path. 235 At the UAS: 237 When the UAS receiving the request wants to retrieve the service 238 access number by which it has been reached, first it should look 239 for the "cause" URI parameter value 380 in the History-Info header 240 field. This History-Info entry should also contain an "mp" or 241 "rc" header field parameter and then the UAS can find the 242 requested service number in the History-Info entry having an index 243 parameter value that match this "mp" or "rc" header field 244 parameter value. If for any reason, there is no "mp" or "rc" 245 header field parameter in the identified History-Info entry, the 246 UAS can find the requested service number in the preceding 247 History-Info entry. 249 If the History-Info header is not supported or has been removed by a 250 proxy for any reason, the UAS might be able to find the requested 251 service access number before translation in either of the following 252 ways, but there is no guarantee: 254 o If the UAS is the direct target of the request coming from the 255 application, the UAS ought to be able to find the service access 256 number in the "target" URI parameter of the Request-URI if there 257 is also a "cause" URI parameter set to 380 in this Request-URI. 259 o If there is no "cause" URI parameter set to 380 in the Request-URI 260 and there is no History-Info header field, the UAS will not be 261 able to reliably retrieve the service access number before 262 translation. Some existing implementations are known to extract 263 the number from the "To" header field. While that approach may 264 work in some situations, it will not work in the general case 265 because the To header field value is sometimes changed by 266 intermediaries, and such a change is not always detectable. 268 4. Example 270 In this section an example is provided to illustrate the application 271 of the new cause-param value. 273 In this example, Alice calls her bank customer care. John is the 274 person at the call center that answers the call. John is in a call 275 center that manages several toll-free services and he needs to know 276 for which service Alice is calling to provide the appropriate welcome 277 speech. 279 Alice Toll-Free Service Atlanta.com John 280 | | | | 281 | INVITE F1 | | | 282 |--------------->| INVITE F2 | | 283 | |------------->| | 284 | | | INVITE F3 | 285 | | |------------------>| 287 * Rest of flow not shown * 289 Figure 1: Service Access Number Translation Example 291 Message Details 293 F1 INVITE [2001:db8:9::2] -> Toll-Free Service 295 In the initial request, the Request-URI contains the Toll-Free 296 number dialed by Alice. 298 INVITE sip:+18005551002@example.com;user=phone SIP/2.0 299 Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf 300 From: Alice ;tag=9fxced76sl 301 To: 302 Call-ID: c3x842276298220188511 303 CSeq: 1 INVITE 304 Max-Forwards: 70 305 Contact: 306 Content-Type: application/sdp 307 Content-Length: 309 [SDP Not Shown] 311 F2 INVITE Toll-Free Service -> Atlanta.com 313 The Toll-Free application receives the request and translates 314 the service number into a routable number toward the call center. 315 The Request-URI is changed and, in the new Request-URI, the 316 "cause" URI parameter set to 380 is added. As there was no 317 History-Info header field in the received request, 318 the application creates a History-Info header with two entries: 319 one for the received Request-URI and one for the new Request-URI. 321 INVITE sip:+15555551002@atlanta.com;cause=380;user=phone SIP/2.0 322 Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8 323 Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf 324 From: Alice ;tag=9fxced76sl 325 To: 326 Call-ID: c3x842276298220188511 327 CSeq: 1 INVITE 328 Max-Forwards: 69 329 Supported: histinfo 330 History-Info: ;index=1 331 History-Info: ; 332 index=1.1;mp=1 333 Contact: 334 Content-Type: application/sdp 335 Content-Length: 337 [SDP Not Shown] 339 F3 INVITE Atlanta.com -> John 341 The call center proxy routes the received request to John's 342 IP address by changing the Request-URI. When changing the 343 Request-URI, the proxy adds a new entry in the History-Info 344 header field. 346 INVITE sip:john@[2001:db8:b::2] SIP/2.0 347 Via: SIP/2.0/TCP [2001:db8:b::3]:5060;branch=z9hG4bKpxk7g 348 Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8 349 Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf 350 From: Alice ;tag=9fxced76sl 351 To: 352 Call-ID: c3x842276298220188511 353 CSeq: 1 INVITE 354 Max-Forwards: 68 355 Supported: histinfo 356 History-Info: ;index=1 357 History-Info: ; 358 index=1.1;mp=1 359 History-Info: ;index=1.1.1;rc=1.1 360 Contact: 361 Content-Type: application/sdp 362 Content-Length: 364 [SDP Not Shown] 366 NOTE: Line breaks for display purpose only 368 5. IANA Considerations 370 [RFC4458] defines a "cause" parameter specified as having predefined 371 values. This document defines a new value for the "cause" parameter: 372 380. 374 This document requests IANA to modify the existing row for the 375 "cause" parameter to add a reference to this document under the "SIP/ 376 SIPS URI Parameters" subregistry within the "Session Initiation 377 Protocols" registry: 379 Parameter Name Predefined Values References 380 -------------- ----------------- ------------------------- 381 cause Yes [RFC4458][TBD:thisdocument] 383 6. Security Considerations 385 The security considerations in [RFC4458] apply. 387 A privacy service that performs the "Privacy: header" Service 388 [RFC3323] must remove the cause URI parameter from the URI. Privacy 389 of the parameters, when they form part of a URI within the History- 390 Info header field, is covered in [RFC7044]. 392 7. Acknowledgements 394 The authors wish to thank the 3GPP community for providing guidance, 395 input, and comments on the document. Thanks also to Paul Kyzivat, 396 Dale Worley, Jean Mahoney, Robert Sparks, Joel Halpern and Lionel 397 Morand for their detail reviews of the document. Special thanks to 398 Ben Campbell for his help to make the work progress. 400 8. References 402 8.1. Normative References 404 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 405 A., Peterson, J., Sparks, R., Handley, M., and E. 406 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 407 DOI 10.17487/RFC3261, June 2002, 408 . 410 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 411 Initiation Protocol (SIP)", RFC 3323, 412 DOI 10.17487/RFC3323, November 2002, 413 . 415 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 416 Header Field for the Session Initiation Protocol (SIP)", 417 RFC 3326, DOI 10.17487/RFC3326, December 2002, 418 . 420 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 421 C. Holmberg, "An Extension to the Session Initiation 422 Protocol (SIP) for Request History Information", RFC 7044, 423 DOI 10.17487/RFC7044, February 2014, 424 . 426 [TS.3GPP.24.229] 427 3GPP TS 24.229 13.0.0, "IP multimedia call control 428 protocol based on Session Initiation Protocol (SIP) and 429 Session Description Protocol (SDP);Stage 3", December 430 2014. 432 8.2. Informative References 434 [ITU-T_I.312_Q.1201] 435 ITU-T Recommendation I312/Q.1201, "Principles of 436 Intelligent Network Architecture", October 1992. 438 [ITU-T_Q.1214] 439 ITU-T Recommendation Q.1214, "Distributed Functional Plane 440 For Intellignet Network CS-1", October 1995. 442 [ITU-T_Q.763] 443 ITU-T Recommendation Q.763, "Signalling System No. 7 - 444 ISDN User Part formats and codes.", December 1999. 446 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 447 Initiation Protocol (SIP) URIs for Applications such as 448 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 449 DOI 10.17487/RFC4458, April 2006, 450 . 452 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 453 Specifications: ABNF", STD 68, RFC 5234, 454 DOI 10.17487/RFC5234, January 2008, 455 . 457 Authors' Addresses 459 Marianne Mohali 460 Orange 461 44 Avenue de la Republique 462 Chatillon 92320 463 France 465 Email: marianne.mohali@orange.com 467 Mary Barnes 468 MLB@Realtime Communications 469 TX 470 US 472 Email: mary.ietf.barnes@gmail.com