idnits 2.17.1 draft-ietf-sipcore-proxy-feature-reqs-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 : ---------------------------------------------------------------------------- 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 (October 21, 2011) is 4571 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: April 23, 2012 October 21, 2011 7 Requirements for indication of features supported by a SIP proxy 8 draft-ietf-sipcore-proxy-feature-reqs-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 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 April 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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 receives a feature support indication that it 245 does not understand, it MUST act as if it hadn't received the 246 indication. 248 REQ-9: If a SIP entity that does not support the proxy feature/ 249 capability indication mechanism receives a feature support 250 indication, it MUST act as if it hadn't received the indication. 252 REQ-10: Other SIP entities MUST be able to make routing decisions 253 based on received feature/capability support indications. 255 REQ-11: A feature/capability support indicator MUST only be used to 256 indicate support of a feature/capability, and MUST NOT be used to 257 indicate whether procedures associated with the feature/capability 258 have been applied or not. 260 REQ-12: It MUST be possible to determine which features/capabilities 261 are supported by the same proxy 263 REQ-13: A procedure for registering feature/capability indication 264 values with IANA MUST be defined. 266 4. Security Considerations 268 Feature/capability support indications can provide sensitive 269 information about a SIP entity. RFC 3840 cautions against providing 270 sensitive information to another party. Once this information is 271 given out, any use may be made of it. 273 5. IANA Considerations 275 None identified. 277 6. Acknowledgements 279 Thanks to Paul Kyzivat and Robert Sparks for their comments and 280 guidance on the mailing list. Thanks to Andrew Allen and Dale Worley 281 for providing text on additional use-cases. Thanks to Cullen 282 Jennings for providing text on additional requirements. Thanks to 283 Dale Worley for providing comments and text improvement suggestions. 284 Thanks to Hadriel Kaplan for telling us how SBCs mess up the 285 mechanisms we try to specify. 287 Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving 288 working procedure guidance. 290 7. Change Log 292 [RFC EDITOR NOTE: Please remove this section when publishing] 294 Changes from draft-ietf-sipcore-proxy-feature-reqs-01 295 o New REQ-12 added (old REQ-12 becomes REQ-13). 296 o New use-case added (section 1.2.3). 297 Changes from draft-ietf-sipcore-proxy-feature-reqs-00 298 o New REQ-5 added (IETF#81). 299 o New REQ-9 added (Dale Worley). 300 o Text added to REQ-4 and REQ-5, indicating that the requirement 301 applies also in cases where an entity does not support the 302 mechanism as a whole (Dale Worley). 303 o Usage of "session establishment transactions" terminology in 304 REQ-6, in order to avoid misunderstanding of "session" (Dale 305 Worley). 306 o Editorial correction in REQ-7: "additional parameter"->"additional 307 parameters" 308 o Editorial clarifications to use-cases. 310 8. References 312 8.1. Normative References 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 8.2. Informative References 319 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 320 "Indicating User Agent Capabilities in the Session 321 Initiation Protocol (SIP)", RFC 3840, August 2004. 323 [3GPP.23.237] 324 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 325 Stage 2", 3GPP TS 23.237 10.7.0, September 2011. 327 [3GPP.24.837] 328 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 329 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 330 10.0.0, April 2011. 332 Authors' Addresses 334 Christer Holmberg 335 Ericsson 336 Hirsalantie 11 337 Jorvas 02420 338 Finland 340 Email: christer.holmberg@ericsson.com 342 Ivo Sedlacek 343 Ericsson 344 Scheelevaegen 19C 345 Lund 22363 346 Sweden 348 Email: ivo.sedlacek@ericsson.com