idnits 2.17.1 draft-holmberg-sipcore-proxy-feature-01.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 3 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 (December 7, 2010) is 4889 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: June 10, 2011 December 7, 2010 7 Indication of features supported by proxy 8 draft-holmberg-sipcore-proxy-feature-01.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 June 10, 2011. 37 Copyright Notice 39 Copyright (c) 2010 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 . . . . . . . . . . . . . 3 56 1.2. Use-case: IMS Enhanced Service Continuity . . . . . . . . . 3 57 1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 4 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. User Agent behavior . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Feature tag semantics . . . . . . . . . . . . . . . . . . . . . 5 63 7. Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Example: IMS Service Continuity . . . . . . . . . . . . . . 6 66 8.2. Example: IMS Enhanced Service Continuity . . . . . . . . . 7 67 8.3. Example: IMS Inter-UE Transfer . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 71 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 13.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The SIP "Caller Preferences" extension defined in RFC 3840 [RFC3840] 80 provides a mechanism that allows a SIP message to convey information, 81 using feature tags, relating to the originator's capabilities. 83 Feature information can be useful for other SIP entities, that might 84 trigger actions and enable functions based on features supported by 85 other SIP entities. 87 This document extends the rr-param rule defined in RFC 3261 88 [RFC3261], so that it can be used to convey feature tags indicating 89 support of features in SIP proxies. The rr-param rule is used in the 90 SIP Path, Route, Record-Route and Service-Route header fields. 92 1.1. Use-case: IMS Service Continuity 94 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 95 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 96 handover of Packet Switched (PS) sessions to Circuit Switched (CS) 97 calls. 99 The handover is controlled by a Service Centralization and Continuity 100 Application Server (SCC AS). When a session is established the User 101 Equipment (UE) needs to determine whether SCC AS is in signalling 102 path of the session or not. 104 When handover occurs, the UE and SCC AS perform handover for the 105 sessions which contain a SCC AS in the signaling path. Other 106 sessions are not affected. 108 Section 8.1 shows an example flow for this use-case. 110 1.2. Use-case: IMS Enhanced Service Continuity 112 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 113 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 114 handover of Packet Switched (PS) sessions to Circuit Switched (CS) 115 calls. The handover can be performed by a Service Centralization and 116 Continuity Application Server (SCC AS), or by a SCC AS together with 117 an Access Transfer Control Function (ATCF), that acts as a SIP proxy. 118 Delegating part of the session handover functionality to an ATCF 119 provides advantages related to voice interruption during session 120 handover etc, since it is located in the same network as the user. 122 In order for a SCC AS to delegate part of the session handover 123 functionality to an ATCF, when it receives a SIP REGISTER request, it 124 needs to be informed whether there is a proxy that provides ATCF 125 functionality in the registration path. 127 Section 8.2 shows an example flow for this use-case. 129 1.3. Use-case: IMS Inter-UE Transfer 131 The 3rd Generation Partnership Project (3GPP) defines inter-UE 132 transfer enhancements [3GPP.24.837] which enhance delivery of media 133 of a session to several User Equipments (UE). 135 The Service Centralization and Continuity Application Server (SCC AS) 136 serving one of the UEs acts as local hub for the session. The UE 137 controls the media of the session and is called controller UE. 139 Triggered by requests from the controller UE, the SCC AS serving the 140 controller UE transfers media of the session to other UEs, called 141 controlee UEs, by sending INVITE request offering the media to be 142 transferred. 144 When an INVITE request is routed to the UE, the SCC AS serving the UE 145 needs to determine whether another SCC AS (i.e. SCC AS of the 146 controller UE) is already in the signalling path. 148 If so, the SCC AS proxies the signalling without further handling as 149 there is already an existing local hub for the session. 151 If not, the SCC AS acts as local hub for the session. 153 Section 8.3 shows an example flow for this use-case. 155 2. Conventions 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in BCP 14, RFC 2119 160 [RFC2119]. 162 3. Definitions 164 The rr-param rule defined in RFC 3261 [RFC3261]: 166 rr-param = generic-param 168 is extended to: 170 rr-param = generic-param / feature-param 171 where feature-param is defined in Section 9 of RFC 3840 [RFC3840]. 173 4. User Agent behavior 175 This specification does not specify any new User Agent behavior. 177 5. Proxy behavior 179 When a proxy inserts a Path header field (during registration), a 180 Service-Route header field (during registration) or a Record-Route 181 header field (during a dialog establishment), it MAY insert a feature 182 tag in the header field. 184 If a feature tag is inserted in a Path or Service-Route header field 185 during registration, the resource identified by the URI in the header 186 field MUST provide support for the associated feature for all dialogs 187 associated with the registration, until the registration is 188 terminated or re-freshed. 190 If a feature tag is inserted in a Record-Route header field during a 191 dialog establishment, the resource identified by the URI in the 192 header field MUST provide support for the associated feature until 193 the dialog is terminated. 195 6. Feature tag semantics 197 The feature tag in a header field constructed using rr-param rule 198 indicates support of the feature in the resource identified by the 199 URI in the header field. 201 In order to insert a feature tag in a SIP header field constructed by 202 using rr-param rule, the feature specification MUST specify the 203 semantics of the feature tag when inserted in that specific header 204 field. Unless the feature specification defines such semantics, a 205 the feature tag MUST NOT be included in that specific header field. 207 NOTE: If a route set is built using Path, Record-Route or Service- 208 Route header fields, any inserted feature tag will be copied into the 209 associated Route header fields, together with other header field 210 parameters. This specification does not define any specific meaning 211 of the feature tags present in Route header fields in such cases. 213 7. Direction 215 When a proxy inserts a feature tag in order to indicate support of a 216 capability, the indicated capability might be indicated both towards 217 downstream and upstream SIP entities. 219 In order to indicate a capability only towards SIP entities in one 220 direction, either the feature tag semantics need to be defined in a 221 way so that SIP entities know whether the indicated capability 222 applies to them or not, or alternatively, the SIP entity that inserts 223 the feature tag needs to ensure that the feature tag is only sent 224 towards the direction for which the capability applies. 226 8. Examples 228 8.1. Example: IMS Service Continuity 230 Based on the presence of g.3gpp.access-transfer feature tag in a 231 Record-Route header field Alice determines that SCC AS serving Alice 232 is in signalling path of the session and when hand over occurs, this 233 specific session can be handed over. 235 NOTE: As P1 only wants to indicate the capability towards Alice, it 236 only inserts the feature tag in the Record-Route header field of the 237 response sent towards Alice. 239 NOTE: The Contact header field of the 200 OK response to the INVITE 240 request contains the GRUU of Bob, so it would be inappropriate to 241 indicate the SCC AS support of handover feature in the Contact header 242 field. 244 Alice P1 (SCC AS Bob 245 of Alice) 246 | | | 247 |--- INVITE---------------->| | 248 | | | 249 | |--- INVITE---------------->| 250 | | Record-Route: P1 | 251 | | | 252 | | | 253 | |<-- 200 OK ----------------| 254 | | Record-Route: P1 | 255 | | | 256 |<-- 200 OK ----------------| | 257 | Record-Route: P1;g.3gpp.access-transfer | 258 | | | 259 Figure 1: Example call flow 261 8.2. Example: IMS Enhanced Service Continuity 263 Based on the presence of g.3gpp.atcf feature tag in a Path header 264 field the REGISTRAR (and SCC AS invoked by REGISTRAR) determines that 265 ATCF is in the path for terminating requests sent to Alice. 267 NOTE: The Contact header field of the REGISTER request contains a URI 268 at which Alice can be directly reached, so it would be inappropriate 269 to indicate the ATCF support of handover feature in the Contact 270 header field. 272 Alice P1 (ATCF) REGISTRAR 273 | | | 274 |--- REGISTER-------------->| | 275 | | | 276 | |--- REGISTER-------------->| 277 | | Path: P1;+g.3gpp.atcf | 278 | | | 279 | | | 280 | |<-- 200 OK ----------------| 281 | | Path: P1;+g.3gpp.atcf | 282 | | Service-Route: REG | 283 |<-- 200 OK ----------------| | 284 | Path: P1;+g.3gpp.atcf | | 285 | Service-Route: REG | | 286 | | | 288 Figure 2: Example call flow 290 8.3. Example: IMS Inter-UE Transfer 292 Based on the presence of g.3gpp.iut-focus feature tag in a Record- 293 Route header field the SCC AS serving Cecil determines that the 294 session already has a local hub. 296 NOTE: The Contact header field of the INVITE request contains the 297 GRUU of Bob, so it would be inappropriate to indicate the SCC AS 298 support of the handover feature in the Contact header field. 300 Alice Cecil P1 (SCC AS P2 (SCC AS Bob 301 of Alice) of Cecil) 302 | | | | | 303 | Session of audio and video between Alice and Bob where | 304 | SCC AS of Alice is in signalling path | 305 |<======================+=================================>| 306 | | | | | 307 |--move audio to Cecil->| | | 308 | | | | | 309 | | |-INVITE----> | | 310 | | | Record-Route: P1;g.3gpp.iut-focus 311 | | | | | 312 | | | | | 313 | | | | | 314 | |<-INVITE-----------------------| | 315 | | Record-Route: P2 | | 316 | | Record-Route: P1;g.3gpp.iut-focus | 317 | | | | | 318 | | | | | 319 | | | | | 320 | | | | | 321 | | | | | 322 | | | | | 323 | | | | | 325 Figure 3: Example call flow 327 9. IANA Considerations 329 TBD 331 10. Security Considerations 333 Feature tags can provide sensitive information about a SIP entity. 334 RFC 3840 cautions against providing sensitive information to another 335 party. Once this information is given out, any use may be made of 336 it. 338 11. Acknowledgements 340 Thanks to Paul Kyzivat for his comments and guidance on the mailing 341 list. 343 12. Change Log 345 [RFC EDITOR NOTE: Please remove this section when publishing] 347 Changes from draft-holmberg-sipcore-proxy-feature-00 348 o Additional use-cases added 349 o Direction section added 351 13. References 353 13.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 359 A., Peterson, J., Sparks, R., Handley, M., and E. 360 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 361 June 2002. 363 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 364 "Indicating User Agent Capabilities in the Session 365 Initiation Protocol (SIP)", RFC 3840, August 2004. 367 13.2. Informative References 369 [3GPP.23.237] 370 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 371 Stage 2", 3GPP TS 23.237 10.3.0, September 2010. 373 [3GPP.24.837] 374 3GPP, "IP Multimedia Subsystem (IMS) SCC Inter UE Transfer 375 Extensions; Stage 3", 3GPP TR 24.837 0.4.0, October 2010. 377 Authors' Addresses 379 Christer Holmberg 380 Ericsson 381 Hirsalantie 11 382 Jorvas 02420 383 Finland 385 Email: christer.holmberg@ericsson.com 386 Ivo Sedlacek 387 Ericsson 388 Scheelevaegen 19C 389 Lund 22363 390 Sweden 392 Email: ivo.sedlacek@ericsson.com