idnits 2.17.1 draft-mohali-sipcore-originating-cdiv-parameter-00.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 211: '... [RFC5502] to clearly state that P-Served-User header field MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o This header is forbidden to be repeated within a request for a particular session at a particular time for the reason that session cases are mutually exclusive. This document updates [RFC5502] to clearly state that P-Served-User header field MUST not contain different values either comma-separated or header-separated. This documents also updates the syntax of the header as defined in [RFC5502] to reflect this uniqueness of parameters values. (Using the creation date from RFC5502, updated by this document, for RFC5378 checks: 2007-04-18) -- 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 (March 10, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 307, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 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: 5502 (if approved) March 10, 2017 5 Intended status: Informational 6 Expires: September 11, 2017 8 A P-Served-User Header Field Parameter for Originating CDIV session case 9 in Session Initiation Protocol (SIP) 10 draft-mohali-sipcore-originating-cdiv-parameter-00 12 Abstract 14 This specification defines a new parameter of the P-Served-User 15 header field in the Session Initiation Protocol (SIP). This new 16 "orig-cdiv" parameter defines the session case used by a proxy when 17 handling an originating session after Call Diversion (CDIV) services 18 has been invoked for the served user. The P-Served-User header field 19 is defined in RFC5502 to convey the identity of the served user and 20 the session case that applies to this particular communication 21 session and application invocation. This document updates RFC5502 to 22 add the "originating after CDIV" session case and to provide more 23 guidance for using the P-Served-User header field in IP networks that 24 were missing in RFC5502. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 11, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Proxy behavior and parameter handling . . . . . . . . . . . . 4 64 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 1.1. General 80 The P-Served-User header field was defined in [RFC5502] to address an 81 issue that was found in the 3rd Generation Partnership Project (3GPP) 82 IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session 83 Control Function) and an AS (Application Server) on the ISC (IMS 84 Service Control) interface. For more information on the IMS, a 85 detailed description can be found in [TS.3GPP.24.229]. 87 This header field conveys the identity of the served user, his/her 88 registration state and the session case that applies to this 89 particular communication session and application invocation. 91 [RFC5502] defines the originating and terminating session cases for a 92 registered or unregistered user. This document extends the P-Served- 93 User header field to include the session case for a forwarded leg 94 when a call diversion service (CDIV) has been invoked and if an 95 originating service of the diverting user has to be triggered. 97 The sessioncase-param parameter of the P-Served-User header field is 98 extended with the "orig-cdiv" parameter for this "originating after 99 CDIV" session case. 101 The following section defines usage of the "orig-cdiv" parameter of 102 P-Served-User header field, Section 2 specifies the proxy behavior 103 for handling the new header field parameter, and Section 3 discusses 104 the applicability and scope of this new header field parameter. 105 Section 4 describes the syntax and correct the syntax of [RFC5502], 106 Section 5 registers the P-Served-User header field parameters with 107 IANA, and Section 6 discusses the security properties of the 108 environment where this new header field parameter is intended to be 109 used. 111 1.2. Use Case 113 In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 114 is a SIP proxy that serves as a registrar and handles originating and 115 terminating session states for users allocated to it. This means 116 that any call that is originated by a specific user or any call that 117 is terminated to that specific user will pass through the S-CSCF that 118 is allocated to that user. 120 At the moment that an S-CSCF is allocated for a specific user, the 121 user profile is downloaded to the S-CSCF from the HSS (Home 122 Subscriber Server), see [TS.3GPP.29.228]. 124 To be able to determine which responsibilities the S-CSCF and the 125 Application Server have to perform and on which user's behalf, it is 126 necessary to know who is the current served user, what is his/her 127 "registration state" and on which "session case" is the session. 128 [RFC5502] defines all those parameters and in particular the 129 originating and terminating session cases. 131 In the case of a call diversion service, the received request is 132 first considered as a terminating session case and the terminating 133 filter criteria configured in the S-CSCF are performed. Receiving 134 the call initiation request, the Application Server is able to 135 determine the served user and the session case (here "term") from the 136 received P-Served-User header field content and to execute 137 terminating services. When the call diversion service is executed 138 (as a terminating service), the Application Server changes the target 139 (Request-URI) of the session and a new call leg is created. This new 140 call leg could be considered as an originating call leg from the 141 diverting user but this is not the case. Indeed, the originating 142 user remains the same and some of the diverting user's originating 143 services should not be triggered as if it was an originating call. 144 For instance, the originating user identity should not be restricted 145 because the diverting user has a privacy service for his/her own 146 identity. The privacy of the diverting user should apply to 147 information related to this user (eg. in the Histroy-Info header 148 field). In the same manner, some specific services will need to be 149 specifically triggered on the outgoing leg after a call diversion. 150 Without a dedicated session case for originating after CDIV, there is 151 no possiblity for a proxy to trigger an originating service for the 152 diverting user or for an Application Server to execute the procedures 153 for this particular session case. 155 For this use case, this document creates a new parameter for the 156 originating after CDIV session case to be embedded in the P-Served- 157 User header field. 159 2. Proxy behavior and parameter handling 161 The "orig-cdiv" header field parameter can be used inside a trust 162 domain of the P-Served-User header field by proxies that are 163 processing call diversion services. The following section 164 illustrates how this header field parameter can be used in a 3GPP 165 network. 167 For a terminating call, when receiving the initial INVITE request, 168 the S-CSCF will determine that the session case is for a terminating 169 user as described in [RFC5502], then it determines the served user by 170 looking at the Request-URI and saves this Request-URI. After that, 171 the S-CSCF starts the analysis of filter criteria and triggers the 172 served user Application Server for the terminating services to be 173 executed including in the INVITE request the P-Served-User header 174 field with the "sescase" parameter set to "term" and the regstate to 175 the corresponding value. 177 Based on some criteria, the Application Server concludes that the 178 request has to be diverted to another target user or application. 179 The received Request-URI is then replaced with the new diverted-to 180 address. The Application Server stores the successive Request-URI(s) 181 values by adding one or two History-Info header field entry(ies) 182 [RFC7044] in the outgoing INVITE. In the History-Info header field, 183 the served user address is tagged thanks to the mp-param header field 184 parameter added in entry associated to the diverted-to address 185 created. 187 In the next step, the Application Server forwards the INVITE request 188 back to the S-CSCF. When receiving back the INVITE request, the 189 S-CSCF can see that the topmost Route header field contains its own 190 hostname but the Request-URI does not match the saved Request-URI. 191 In this case, the S-CSCF updates the P-Served-User header field 192 content by replacing the "sescase" parameter by the "orig-cdiv" 193 parameter. The PServedUser-value remains unchanged. 195 Then the procedure continues by forwarding the INVITE request over to 196 an AS that hosts the originating services of the served user 197 (diverting user) that specifically need to be executed on the 198 forwarded leg after a call diversion service. 200 When the Application Server receives the INVITE request, it 201 determines that the session case is for "orig-cdiv" session case and 202 will perform the originating services to be executed after 203 retargeting for the diverting user (i.e. served user). 205 This document also provides the following guidance that reminds or 206 clarifies the P-Served-User handling that are missing in [RFC5502]: 208 o This header is forbidden to be repeated within a request for a 209 particular session at a particular time for the reason that 210 session cases are mutually exclusive. This document updates 211 [RFC5502] to clearly state that P-Served-User header field MUST 212 not contain different values either comma-separated or header- 213 separated. This documents also updates the syntax of the header 214 as defined in [RFC5502] to reflect this uniqueness of parameters 215 values. 217 o Whether the "regstate" parameter is removed or not by the S-CSCF 218 when processing the orginating after CDIV session case is out of 219 the scope of this document. In one hand, it can either be 220 considered that the S-CSCF is able to store the previous regstate 221 value and that the same value applies or that the "regstate" is 222 not relevant after a diverting service. On the other hand, the 223 regstate can be combined to the orig-cdiv session case to provide 224 different services if the served user is registered or 225 unregistered. These choices are implementation dependent. 227 3. Applicability 229 The use of the P-Served-User header field extensions is only 230 applicable inside a Trust Domain for P-Served-User. Nodes in such a 231 Trust Domain explicitly trust each other to convey the served user 232 and to be responsible for withholding that information outside of the 233 Trust Domain. The means by which the network determines the served 234 user and the policies that are executed for a specific served user is 235 outside the scope of this document. 237 4. Syntax 239 4.1. General 241 [RFC5502] defines the P-Served-User header field with the 242 sessioncase-param parameter "sescase" which is specified as having 243 "orig" and "term" predefined values. This document defines an 244 additional parameter for the sessioncase-param: "orig-cdiv". 246 Because this document extends the existing sessioncase-param 247 parameter in a special way and that it has been identified errors in 248 the syntax of the P-Served-User header field as defined in [RFC5502], 249 this document corrects and extends the header at the same time. 251 The extension of the sessioncase-param parameter to add the "orig- 252 cdiv" session case is done in a way to fit the parameter format 253 introduced in release 11 of the 3GPP [TS.3GPP.24.229] and keep a 254 backward compatibility. 256 "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- 257 param" are defined in [RFC3261]. 259 4.2. ABNF 261 The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- 262 Served-User header field is described in [RFC5502]. 264 This document updates [RFC5502] to correct the P-Served-User header 265 field ABNF syntax and extend it as following: 267 P-Served-User = "P-Served-User" HCOLON PServedUser-value 268 *(SEMI served-user-param) 269 served-user-param = sessioncase-param 270 / registration-state-param 271 / generic-param 272 PServedUser-value = name-addr / addr-spec 273 sessioncase-param = 1("sescase" EQUAL 1("orig" / "term")/ orig-cdiv) 274 registration-state-param = "regstate" EQUAL 1("unreg" / "reg") 275 orig-cdiv = "orig-cdiv" 277 Examples of possible P-Served-User header field: 279 P-Served-User: ; orig-cdiv; regstate=reg 280 or 281 P-Served-User: ; orig-cdiv 282 or 283 P-Served-User: ; sescase=term; regstate=unreg 285 5. IANA Considerations 287 The syntax of the P-Served-User header field is defined in [RFC5502] 288 and updated in Section 4 of this document. 290 This document requests IANA to update the existing row for the P- 291 Served-User header field in the "Header Fields" sub-registry: 293 Header Name Compact Form Reference 294 ------------- ------------ ---------------- 295 P-Served-User none [RFC5502][RFCXXXX] 297 Note to RFC Editor: Please replace XXXX with the RFC number of this document. 299 This document requests IANA to add new rows for the P-Served-User 300 header field parameters in the "Header Field Parameters and Parameter 301 Values" sub-registry as per the registry created by [RFC3968]: 303 Header Field Parameter Name Predefined Values Reference 304 -------------- ---------------- ----------------- ----------------- 305 P-Served-User sescase Yes [RFC5502][RFCXXXX] 306 P-Served-User regstate Yes [RFC5502][RFCXXXX] 307 P-Served-User orig-cdiv No [RFCXXXX] 309 Note to RFC Editor: Please replace XXXX with the RFC number of this document. 311 6. Security Considerations 313 The security considerations in [RFC5502] apply. 315 As the "orig-cdiv" parameter of P-Served-User header field can be 316 used to trigger applications, it is important to ensure that the 317 parameter has not been added to the SIP message by an unauthorized 318 SIP entity. 320 7. Acknowledgments 322 The author wishes to thank the 3GPP community for providing guidance, 323 input, and comments on the document. Thanks also to Dale Worley for 324 his careful review of the document. 326 8. References 328 8.1. Normative References 330 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 331 A., Peterson, J., Sparks, R., Handley, M., and E. 332 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 333 DOI 10.17487/RFC3261, June 2002, 334 . 336 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 337 (IANA) Header Field Parameter Registry for the Session 338 Initiation Protocol (SIP)", BCP 98, RFC 3968, 339 DOI 10.17487/RFC3968, December 2004, 340 . 342 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 343 Specifications: ABNF", STD 68, RFC 5234, 344 DOI 10.17487/RFC5234, January 2008, 345 . 347 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 348 C. Holmberg, "An Extension to the Session Initiation 349 Protocol (SIP) for Request History Information", RFC 7044, 350 DOI 10.17487/RFC7044, February 2014, 351 . 353 8.2. Informative References 355 [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header 356 (P-Header) for the 3GPP IP Multimedia (IM) Core Network 357 (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 358 2009, . 360 [TS.3GPP.24.229] 361 3GPP, "IP multimedia call control protocol based on 362 Session Initiation Protocol (SIP) and Session Description 363 Protocol (SDP);Stage 3", 3GPP TS 24.229 v11. 365 [TS.3GPP.29.228] 366 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 367 Signalling flows and message contents", 3GPP TS 29.228 368 v11. 370 Author's Address 372 Marianne Mohali 373 Orange 374 Orange Gardens, 44 avenue de la Republique 375 Chatillon 92326 376 France 378 Email: marianne.mohali@orange.com