idnits 2.17.1 draft-holmberg-sipcore-proxy-feature-02.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 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2011) is 4704 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft I. Sedlacek 4 Intended status: Standards Track Ericsson 5 Expires: December 11, 2011 June 9, 2011 7 Indication of features supported by proxy 8 draft-holmberg-sipcore-proxy-feature-02.txt 10 Abstract 12 The Session Initiation Protocol (SIP) "Caller Preferences" extension 13 defined in RFC 3840 provides a mechanism that allows a SIP message to 14 convey information relating to the originator's capabilities. This 15 document makes it possible for SIP proxies to convey similar 16 information, by extending the rr-param rule defined in RFC 3261, so 17 that the header field parameter can be used to convey feature tags 18 that indicate features supported by the proxy. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 11, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Use-case: IMS Service Continuity, handover of session 56 in alerting state . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Use-case: IMS Enhanced Service Continuity . . . . . . . . 3 58 1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF 59 discovery . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2.2. Use-case: IMS Enhanced Service Continuity, 61 identifying sessions subject to handover . . . . . . . 4 62 1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . 4 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. User Agent behavior . . . . . . . . . . . . . . . . . . . . . 5 67 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Feature tag semantics . . . . . . . . . . . . . . . . . . . . 6 69 8. Direction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Example: IMS Service Continuity, handover session in 72 alerting state . . . . . . . . . . . . . . . . . . . . . . 6 73 9.2. Example: IMS Enhanced Service Continuity, ATCF 74 discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 75 9.3. Example: IMS Enhanced Service Continuity, identifying 76 sessions subject to handover . . . . . . . . . . . . . . . 8 77 9.4. Example: IMS Inter-UE Transfer . . . . . . . . . . . . . . 9 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 14.1. Normative References . . . . . . . . . . . . . . . . . . . 10 84 14.2. Informative References . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 The SIP "Caller Preferences" extension defined in RFC 3840 [RFC3840] 90 provides a mechanism that allows a SIP message to convey information, 91 using feature tags, relating to the originator's capabilities. 93 Feature information can be useful for other SIP entities, that might 94 trigger actions and enable functions based on features supported by 95 other SIP entities. 97 This document extends the rr-param rule defined in RFC 3261 98 [RFC3261], so that it can be used to convey feature tags indicating 99 support of features in SIP proxies. The rr-param rule is used in the 100 SIP Path, Route, Record-Route and Service-Route header fields. 102 1.1. Use-case: IMS Service Continuity, handover of session in alerting 103 state 105 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 106 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 107 handover of Packet Switched (PS) sessions to Circuit Switched (CS) 108 calls. 110 The handover is controlled by a Service Centralization and Continuity 111 Application Server (SCC AS). When a session is established the User 112 Equipment (UE) needs to determine whether SCC AS in signalling path 113 of the session supports handover of session in alerting state (i.e. 114 180 Ringing response has already been sent or received but the dialog 115 is not confirmed dialog yet) or not. 117 When handover occurs and a session in alerting state exists and both 118 UE and SCC AS indicated support of the handover of session in 119 alerting state, then the UE and SCC AS perform handover for the 120 session in alerting state. 122 NOTE: The UE indicates the support of the handover of session in 123 alerting state by the feature tag included in Contact header field. 125 Section 9.1 shows an example flow for this use-case. 127 1.2. Use-case: IMS Enhanced Service Continuity 129 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 130 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 131 handover of Packet Switched (PS) sessions to Circuit Switched (CS) 132 calls. The handover can be performed by a Service Centralization and 133 Continuity Application Server (SCC AS), or by a SCC AS together with 134 an Access Transfer Control Function (ATCF), that acts as a SIP proxy. 136 Delegating part of the session handover functionality to an ATCF 137 provides advantages related to voice interruption during session 138 handover etc, since it is located in the same network as the user. 140 1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF discovery 142 In order for a SCC AS to delegate part of the session handover 143 functionality to an ATCF, when it receives a SIP REGISTER request, it 144 needs to be informed whether there is a proxy that provides ATCF 145 functionality in the registration path. 147 Section 9.2 shows an example flow for this use-case. 149 1.2.2. Use-case: IMS Enhanced Service Continuity, identifying sessions 150 subject to handover 152 In order for ATCF to perform the delegated part of the session 153 handover functionality, ATCF needs to know which sessions are subject 154 to handover as decided by SCC AS. 156 Section 9.3 shows an example flow for this use-case. 158 1.3. Use-case: IMS Inter-UE Transfer 160 The 3rd Generation Partnership Project (3GPP) defines inter-UE 161 transfer enhancements [3GPP.24.837] which enhance delivery of media 162 of a session to several User Equipments (UE). 164 The Service Centralization and Continuity Application Server (SCC AS) 165 serving one of the UEs acts as local hub for the session. The UE 166 controls the media of the session and is called controller UE. 168 Triggered by requests from the controller UE, the SCC AS serving the 169 controller UE transfers media of the session to other UEs, called 170 controlee UEs, by sending INVITE request offering the media to be 171 transferred. 173 When an INVITE request is routed to the UE, the SCC AS serving the UE 174 needs to determine whether another SCC AS (i.e. SCC AS of the 175 controller UE) is already in the signalling path. 177 If so, the SCC AS proxies the signalling without further handling as 178 there is already an existing local hub for the session. 180 If not, the SCC AS acts as local hub for the session. 182 Section 9.4 shows an example flow for this use-case. 184 2. Conventions 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in BCP 14, RFC 2119 189 [RFC2119]. 191 3. Definitions 193 The rr-param rule defined in RFC 3261 [RFC3261]: 195 rr-param = generic-param 197 is extended to: 199 rr-param = generic-param / feature-param 201 where feature-param is defined in Section 9 of RFC 3840 [RFC3840]. 203 4. Requirements 205 1. It SHALL be possible for a SIP intermediary to indicate, in a SIP 206 routing header field (e.g Record-Route, Service-Route, Path), support 207 (for a session or registration) for a particular feature/capability. 209 2. It SHALL be possible to indicate whether indicated support of a 210 feature/capability is only applicable in a certain direction of the 211 signalling path associated with the SIP routing header field, in 212 which the feature/capability support is indicated. 214 5. User Agent behavior 216 This specification does not specify any new User Agent behavior. 218 6. Proxy behavior 220 When a proxy inserts a Path header field (during registration), a 221 Service-Route header field (during registration) or a Record-Route 222 header field (during a dialog establishment), it MAY insert a feature 223 tag in the header field. 225 If a feature tag is inserted in a Path or Service-Route header field 226 during registration, the resource identified by the URI in the header 227 field MUST provide support for the associated feature for all dialogs 228 associated with the registration, until the registration is 229 terminated or re-freshed. 231 If a feature tag is inserted in a Record-Route header field during a 232 dialog establishment, the resource identified by the URI in the 233 header field MUST provide support for the associated feature until 234 the dialog is terminated. 236 7. Feature tag semantics 238 The feature tag in a header field constructed using rr-param rule 239 indicates support of the feature in the resource identified by the 240 URI in the header field. 242 In order to insert a feature tag in a SIP header field constructed by 243 using rr-param rule, the feature specification MUST specify the 244 semantics of the feature tag when inserted in that specific header 245 field. Unless the feature specification defines such semantics, a 246 the feature tag MUST NOT be included in that specific header field. 248 NOTE: If a route set is built using Path, Record-Route or Service- 249 Route header fields, any inserted feature tag will be copied into the 250 associated Route header fields, together with other header field 251 parameters. This specification does not define any specific meaning 252 of the feature tags present in Route header fields in such cases. 254 8. Direction 256 When a proxy inserts a feature tag in order to indicate support of a 257 capability, the indicated capability might be indicated both towards 258 downstream and upstream SIP entities. 260 In order to indicate a capability only towards SIP entities in one 261 direction, either the feature tag semantics need to be defined in a 262 way so that SIP entities know whether the indicated capability 263 applies to them or not, or alternatively, the SIP entity that inserts 264 the feature tag needs to ensure that the feature tag is only sent 265 towards the direction for which the capability applies. 267 9. Examples 269 9.1. Example: IMS Service Continuity, handover session in alerting 270 state 272 Based on the presence of g.3gpp.srvcc-alerting feature tag in a 273 Record-Route header field Alice determines that SCC AS serving Alice 274 in signalling path of the session supports the handover of session in 275 alerting state and when hand over occurs and session in alerting 276 state exists, this specific session can be handed over. 278 NOTE: As P1 only wants to indicate the capability towards Alice, it 279 only inserts the feature tag in the Record-Route header field of the 280 response sent towards Alice. 282 NOTE: The Contact header field of the 200 OK response to the INVITE 283 request contains the GRUU of Bob, so it would be inappropriate to 284 indicate the SCC AS support of handover feature in the Contact header 285 field. 287 Alice P1 (SCC AS Bob 288 of Alice) 289 | | | 290 |--- INVITE---------------->| | 291 | | | 292 | |--- INVITE---------------->| 293 | | Record-Route: P1 | 294 | | | 295 | | | 296 | |<-- 200 OK ----------------| 297 | | Record-Route: P1 | 298 | | | 299 |<-- 200 OK ----------------| | 300 | Record-Route: P1;g.3gpp.srvcc-alerting | 301 | | | 303 Figure 1: Example call flow 305 9.2. Example: IMS Enhanced Service Continuity, ATCF discovery 307 Based on the presence of g.3gpp.atcf feature tag in a Path header 308 field the REGISTRAR (and SCC AS invoked by REGISTRAR) determines that 309 ATCF is in the path for terminating requests sent to Alice. 311 NOTE: The Contact header field of the REGISTER request contains a URI 312 at which Alice can be directly reached, so it would be inappropriate 313 to indicate the ATCF support of handover feature in the Contact 314 header field. 316 Alice P1 (ATCF) REGISTRAR 317 | | | 318 |--- REGISTER-------------->| | 319 | | | 320 | |--- REGISTER-------------->| 321 | | Path: P1;+g.3gpp.atcf | 322 | | | 323 | | | 324 | |<-- 200 OK ----------------| 325 | | Path: P1;+g.3gpp.atcf | 326 | | Service-Route: REG | 327 |<-- 200 OK ----------------| | 328 | Path: P1;+g.3gpp.atcf | | 329 | Service-Route: REG | | 330 | | | 332 Figure 2: Example call flow 334 9.3. Example: IMS Enhanced Service Continuity, identifying sessions 335 subject to handover 337 Based on the presence of g.3gpp.srvcc feature tag in a Record-Route 338 header field the ATCF determines that the session is subject to the 339 handover. 341 Alice P2 (ATCF) P1 (SCC AS Bob 342 of Alice) 343 | | | | 344 |--- INVITE->| | | 345 | |--- INVITE---->| | 346 | | Record-Route: P2 | 347 | | |--- INVITE---------------->| 348 | | | Record-Route: P1, P2 | 349 | | | | 350 | | | | 351 | | |<-- 200 OK ----------------| 352 | | | Record-Route: P1, P2 | 353 | | | | 354 | |<--- 200 OK----| | 355 | | Record-Route: P1;g.3gpp.srvcc, P2 | 356 |<-- 200 OK--| | | 357 | Record-Route: P1;g.3gpp.srvcc, P2 | 358 | | | | 360 Figure 3: Example call flow 362 9.4. Example: IMS Inter-UE Transfer 364 Based on the presence of g.3gpp.iut-focus feature tag in a Record- 365 Route header field the SCC AS serving Cecil determines that the 366 session already has a local hub. 368 NOTE: The Contact header field of the INVITE request contains the 369 GRUU of Bob, so it would be inappropriate to indicate the SCC AS 370 support of the handover feature in the Contact header field. 372 Alice Cecil P1 (SCC AS P2 (SCC AS Bob 373 of Alice) of Cecil) 374 | | | | | 375 | Session of audio and video between Alice and Bob where | 376 | SCC AS of Alice is in signalling path | 377 |<======================+=================================>| 378 | | | | | 379 |--move audio to Cecil->| | | 380 | | | | | 381 | | |-INVITE----> | | 382 | | | Record-Route: P1;g.3gpp.iut-focus 383 | | | | | 384 | | | | | 385 | | | | | 386 | |<-INVITE-----------------------| | 387 | | Record-Route: P2 | | 388 | | Record-Route: P1;g.3gpp.iut-focus | 389 | | | | | 390 | | | | | 391 | | | | | 392 | | | | | 393 | | | | | 394 | | | | | 395 | | | | | 397 Figure 4: Example call flow 399 10. IANA Considerations 401 TBD 403 11. Security Considerations 405 Feature tags can provide sensitive information about a SIP entity. 406 RFC 3840 cautions against providing sensitive information to another 407 party. Once this information is given out, any use may be made of 408 it. 410 12. Acknowledgements 412 Thanks to Paul Kyzivat for his comments and guidance on the mailing 413 list. 415 13. Change Log 417 [RFC EDITOR NOTE: Please remove this section when publishing] 419 Changes from draft-holmberg-sipcore-proxy-feature-01 420 o Requirement section added 421 o Use-cases and examples updated based on work in 3GPP 423 Changes from draft-holmberg-sipcore-proxy-feature-00 424 o Additional use-cases added 425 o Direction section added 427 14. References 429 14.1. Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 435 A., Peterson, J., Sparks, R., Handley, M., and E. 436 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 437 June 2002. 439 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 440 "Indicating User Agent Capabilities in the Session 441 Initiation Protocol (SIP)", RFC 3840, August 2004. 443 14.2. Informative References 445 [3GPP.23.237] 446 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 447 Stage 2", 3GPP TS 23.237 8.7.0, March 2010. 449 [3GPP.24.837] 450 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 451 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 452 10.0.0, April 2011. 454 Authors' Addresses 456 Christer Holmberg 457 Ericsson 458 Hirsalantie 11 459 Jorvas 02420 460 Finland 462 Email: christer.holmberg@ericsson.com 464 Ivo Sedlacek 465 Ericsson 466 Scheelevaegen 19C 467 Lund 22363 468 Sweden 470 Email: ivo.sedlacek@ericsson.com