idnits 2.17.1 draft-ietf-sipcore-proxy-feature-reqs-03.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 -- The document date (December 5, 2011) is 4497 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 (~~), 1 warning (==), 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 7, 2012 December 5, 2011 7 Requirements for indication of features supported by a SIP proxy 8 draft-ietf-sipcore-proxy-feature-reqs-03.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 supported features/ 15 capabilities. This document defines requirements for a mechanism 16 that would allow SIP proxies to convey information relating to the 17 proxy's supported features/capabilities. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 7, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Use-case: IMS Service Continuity, handover of session 55 in alerting state . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Use-case: IMS Enhanced Service Continuity . . . . . . . . . 3 57 1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF 58 discovery . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2.2. Use-case: IMS Enhanced Service Continuity, 60 identifying sessions subject to handover . . . . . . . 4 61 1.2.3. Use-case: IMS Enhanced Service Continuity, 62 indicating handover subfeature support . . . . . . . . 4 63 1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 5 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The Session Initiation Protocol (SIP) "Caller Preferences" extension 78 defined in RFC 3840 [RFC3840] provides a mechanism that allows a SIP 79 message to convey information relating to the originator's supported 80 features/capabilities. 82 It can be useful for SIP proxies to indicate supported feature/ 83 capabilities, that might trigger actions and enable functions in 84 other SIP entities. 86 This document defines requirements for a mechanism that would allow 87 SIP proxies to convey information related to the proxy's supported 88 features/capabilities. 90 1.1. Use-case: IMS Service Continuity, handover of session in alerting 91 state 93 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 94 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 95 handover of Packet Switched (PS) sessions to Circuit Switched (CS) 96 calls. 98 The handover is controlled by a Service Centralization and Continuity 99 Application Server (SCC AS). When a session is established the User 100 Equipment (UE) needs to determine whether SCC AS in signalling path 101 of the session supports handover of session in alerting state (i.e. 102 180 Ringing response has already been sent or received but the dialog 103 is not confirmed dialog yet) or not. 105 When handover occurs and a session in alerting state exists and both 106 UE and SCC AS indicated support of the handover of session in 107 alerting state, then the UE and SCC AS perform handover for the 108 session in alerting state. 110 NOTE: The UE indicates the support of the handover of session in 111 alerting state by the feature tag included in Contact header field. 113 1.2. Use-case: IMS Enhanced Service Continuity 115 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 116 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 117 handover of Packet Switched (PS) sessions to Circuit Switched (CS) 118 calls. The handover can be performed by a Service Centralization and 119 Continuity Application Server (SCC AS), or by a SCC AS together with 120 an Access Transfer Control Function (ATCF), that acts as a SIP proxy. 121 Delegating part of the session handover functionality to an ATCF 122 provides advantages related to voice interruption during session 123 handover etc, since the ATCF is located in the same network as the 124 user. 126 1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF discovery 128 In order for an SCC AS to delegate part of the session handover 129 functionality to an ATCF, when the SCC AS is informed by the 130 registrar about an accepted REGISTER transaction, the SCC AS needs to 131 determine whether a proxy supporting the ATCF functionality is in the 132 registration path. 134 1.2.2. Use-case: IMS Enhanced Service Continuity, identifying sessions 135 subject to handover 137 In order for ATCF to perform the delegated part of the session 138 handover functionality, when a session is set up, the ATCF needs to 139 determine whether a SIP proxy supporting the SCC AS functionality is 140 in the signalling path of the session. 142 1.2.3. Use-case: IMS Enhanced Service Continuity, indicating handover 143 subfeature support 145 As the session handover functionality has been specified over several 146 3GPP releases, some subfeatures of the handover functionality are 147 optional. Examples are: 149 - The handover of sessions with audio on hold (called the MSC server 150 assisted mid-call feature); and 152 - The handover of sessions where a 180 Ringing response to the 153 initial SIP INVITE request has already been sent or received but a 154 final response has not been sent or received yet (called the SRVCC 155 for calls in alerting phase). 157 The SCC AS needs to be aware of support of those subfeatures in ATCF, 158 in order for the UE and the SCC AS to execute the correct handling 159 when the handover occurs. 161 When ATCF receives a SIP REGISTER request, the ATCF indicates the 162 support of those subfeatures along the indication of ATCF 163 functionality. 165 When SCC AS is informed about the new/updated binding where a proxy 166 indicated support of ATCF functionality along with support of those 167 subfeatures, the SCC AS discovers the support of those subfeatures in 168 the ATCF. 170 1.3. Use-case: IMS Inter-UE Transfer 172 The 3rd Generation Partnership Project (3GPP) defines inter-UE 173 transfer enhancements [3GPP.24.837] which enhance delivery of media 174 of a session to several User Equipments (UE). 176 The Service Centralization and Continuity Application Server (SCC AS) 177 serving one of the UEs acts as local hub for the session. The UE 178 controls the media of the session and is called controller UE. 180 Triggered by requests from the controller UE, the SCC AS serving the 181 controller UE transfers media of the session to other UEs, called 182 controlee UEs, by sending INVITE request offering the media to be 183 transferred. 185 When an INVITE request is routed to the UE, the SCC AS serving the UE 186 needs to determine whether a SIP proxy supporting the inter-UE 187 transfer enhancements functionality (i.e. SCC AS of the controller 188 UE) is already in the signalling path. 190 If so, the SCC AS proxies the signalling without further handling as 191 there is already an existing local hub for the session. 193 If not, the SCC AS acts as local hub for the session. 195 2. Conventions 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in BCP 14, RFC 2119 200 [RFC2119]. 202 3. Requirements 204 REQ-1: It MUST be possible for a SIP proxy to indicate, and convey to 205 other SIP entities in the signalling path of a registration request, 206 support of a particular feature/capability. 208 REQ-2: It MUST be possible for a SIP proxy to indicate, and convey to 209 other SIP entities in the signalling path of a dialog-forming 210 request, support of a particular feature/capability. 212 REQ-3: It MUST be possible for a SIP proxy to indicate that the 213 indicated support of a feature/capability only applies to other SIP 214 entities in the direction towards one of the SIP endpoints in the 215 signalling path. 217 REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/ 218 capability, make any assumptions that SIP entities in the signalling 219 path that receive the indicator will support, or understand the 220 meaning of, the feature/capability, or even support the proxy 221 feature/capability indication mechanism as a whole. 223 REQ-5: A SIP proxy MUST be able to indicate support of a feature/ 224 capability to other SIP entities in the signaling path, even if some 225 SIP entities in the signaling path (possibly including the UAC and/or 226 UAS) do not support, or understand the meaning of, the feature/ 227 capability, or even support the proxy feature/capability indication 228 mechanism as a whole. 230 REQ-6: It MUST be possible to indicate whether indicated support of a 231 feature/capability applies to specific registration, to a specific 232 dialog, or to all dialogs created as part of INVITE transaction. 234 NOTE: This requirement might be fully implemented as part of the 235 protocol mechanism, or parts might be left to be specified in a 236 feature/capability specification, or it might be left to be specified 237 in a feature/capability specification completely. 239 REQ-7: It MUST be possible to assign additional parameters (either as 240 a single value, or a list of values) to a feature/capability 241 indicator, in order to provide additional information about the 242 feature/capability. 244 REQ-8: If a SIP entity that supports the proxy feature/capability 245 indication mechanism receives a feature support indication that it 246 does not understand, it MUST act as if it hadn't received the 247 indication. 249 REQ-9: If a SIP entity that does not support the proxy feature/ 250 capability indication mechanism receives a feature support 251 indication, it MUST act as if it hadn't received the indication. 253 REQ-10: SIP entities on the path of the SIP message MUST be able to 254 inspect the feature/capability support indicators introduced by other 255 entities. 257 REQ-11: A feature/capability support indicator MUST only be used to 258 indicate support of a feature/capability, and MUST NOT be used to 259 indicate whether procedures associated with the feature/capability 260 have been applied or not. 262 REQ-12: It MUST be possible to determine which features/capabilities 263 are supported by the same proxy. 265 REQ-13: A SIP proxy that indicates support of a feature/capability 266 associated with a dialog MUST take the necessary steps to ensure it 267 is part of the signaling path of the remainder that dialog, by 268 indicating the support of the feature/capability as part of a dialog 269 forming transaction, or as part of a target refresh request within a 270 dialog. 272 REQ-14: A procedure for registering feature/capability indication 273 values, which prevents name collisions of indicators, with IANA MUST 274 be defined. 276 4. Security Considerations 278 Feature/capability support indications can provide sensitive 279 information about a SIP entity. RFC 3840 cautions against providing 280 sensitive information to another party. Once this information is 281 given out, any use may be made of it. 283 5. IANA Considerations 285 None identified. 287 6. Acknowledgements 289 Thanks to Paul Kyzivat and Robert Sparks for their comments and 290 guidance on the mailing list. Thanks to Andrew Allen and Dale Worley 291 for providing text on additional use-cases. Thanks to Cullen 292 Jennings for providing text on additional requirements. Thanks to 293 Dale Worley for providing comments and text improvement suggestions. 294 Thanks to Hadriel Kaplan for telling us how SBCs mess up the 295 mechanisms we try to specify. 297 Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving 298 working procedure guidance. 300 7. Change Log 302 [RFC EDITOR NOTE: Please remove this section when publishing] 304 Changes from draft-ietf-sipcore-proxy-feature-reqs-02 305 o Changes based on comments from Robert Sparks at IETF#82 (http:// 306 www.ietf.org/mail-archive/web/sipcore/current/msg04473.html). 308 o REQ-10: now talks about having access to the information, rather 309 than talking specifically about making routing decisions. 310 o REQ-8: editorial modification, to better distinguish it from 311 REQ-9. 312 o New REQ-13 (old REQ-13 becomes REQ-14) added. 313 o REQ-14: indication that the IANA registration procedure will 314 prevent name collision between feature indications. 315 Changes from draft-ietf-sipcore-proxy-feature-reqs-01 316 o New REQ-12 added (old REQ-12 becomes REQ-13). 317 o New use-case added (section 1.2.3). 318 Changes from draft-ietf-sipcore-proxy-feature-reqs-00 319 o New REQ-5 added (IETF#81). 320 o New REQ-9 added (Dale Worley). 321 o Text added to REQ-4 and REQ-5, indicating that the requirement 322 applies also in cases where an entity does not support the 323 mechanism as a whole (Dale Worley). 324 o Usage of "session establishment transactions" terminology in 325 REQ-6, in order to avoid misunderstanding of "session" (Dale 326 Worley). 327 o Editorial correction in REQ-7: "additional parameter"->"additional 328 parameters" 329 o Editorial clarifications to use-cases. 331 8. References 333 8.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 8.2. Informative References 340 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 341 "Indicating User Agent Capabilities in the Session 342 Initiation Protocol (SIP)", RFC 3840, August 2004. 344 [3GPP.23.237] 345 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 346 Stage 2", 3GPP TS 23.237 10.7.0, September 2011. 348 [3GPP.24.837] 349 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 350 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 351 10.0.0, April 2011. 353 Authors' Addresses 355 Christer Holmberg 356 Ericsson 357 Hirsalantie 11 358 Jorvas 02420 359 Finland 361 Email: christer.holmberg@ericsson.com 363 Ivo Sedlacek 364 Ericsson 365 Scheelevaegen 19C 366 Lund 22363 367 Sweden 369 Email: ivo.sedlacek@ericsson.com