idnits 2.17.1 draft-ietf-sipcore-proxy-feature-reqs-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 : ---------------------------------------------------------------------------- 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 (September 9, 2011) is 4605 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: March 12, 2012 September 9, 2011 7 Requirements for indication of features supported by a SIP proxy 8 draft-ietf-sipcore-proxy-feature-reqs-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 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 March 12, 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.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 4 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The Session Initiation Protocol (SIP) "Caller Preferences" extension 76 defined in RFC 3840 [RFC3840] provides a mechanism that allows a SIP 77 message to convey information relating to the originator's supported 78 features/capabilities. 80 It can be useful for SIP proxies to indicate supported feature/ 81 capabilities, that might trigger actions and enable functions in 82 other SIP entities. 84 This document defines requirements for a mechanism that would allow 85 SIP proxies to convey information related to the proxy's supported 86 features/capabilities. 88 1.1. Use-case: IMS Service Continuity, handover of session in alerting 89 state 91 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 92 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 93 handover of Packet Switched (PS) sessions to Circuit Switched (CS) 94 calls. 96 The handover is controlled by a Service Centralization and Continuity 97 Application Server (SCC AS). When a session is established the User 98 Equipment (UE) needs to determine whether SCC AS in signalling path 99 of the session supports handover of session in alerting state (i.e. 100 180 Ringing response has already been sent or received but the dialog 101 is not confirmed dialog yet) or not. 103 When handover occurs and a session in alerting state exists and both 104 UE and SCC AS indicated support of the handover of session in 105 alerting state, then the UE and SCC AS perform handover for the 106 session in alerting state. 108 NOTE: The UE indicates the support of the handover of session in 109 alerting state by the feature tag included in Contact header field. 111 1.2. Use-case: IMS Enhanced Service Continuity 113 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 114 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 115 handover of Packet Switched (PS) sessions to Circuit Switched (CS) 116 calls. The handover can be performed by a Service Centralization and 117 Continuity Application Server (SCC AS), or by a SCC AS together with 118 an Access Transfer Control Function (ATCF), that acts as a SIP proxy. 119 Delegating part of the session handover functionality to an ATCF 120 provides advantages related to voice interruption during session 121 handover etc, since the ATCF is located in the same network as the 122 user. 124 1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF discovery 126 In order for an SCC AS to delegate part of the session handover 127 functionality to an ATCF, when the SCC AS is informed by the 128 registrar about an accepted REGISTER transaction, the SCC AS needs to 129 determine whether a proxy supporting the ATCF functionality is in the 130 registration path. 132 1.2.2. Use-case: IMS Enhanced Service Continuity, identifying sessions 133 subject to handover 135 In order for ATCF to perform the delegated part of the session 136 handover functionality, when a session is set up, the ATCF needs to 137 determine whether a SIP proxy supporting the SCC AS functionality is 138 in the signalling path of the session. 140 1.3. Use-case: IMS Inter-UE Transfer 142 The 3rd Generation Partnership Project (3GPP) defines inter-UE 143 transfer enhancements [3GPP.24.837] which enhance delivery of media 144 of a session to several User Equipments (UE). 146 The Service Centralization and Continuity Application Server (SCC AS) 147 serving one of the UEs acts as local hub for the session. The UE 148 controls the media of the session and is called controller UE. 150 Triggered by requests from the controller UE, the SCC AS serving the 151 controller UE transfers media of the session to other UEs, called 152 controlee UEs, by sending INVITE request offering the media to be 153 transferred. 155 When an INVITE request is routed to the UE, the SCC AS serving the UE 156 needs to determine whether a SIP proxy supporting the inter-UE 157 transfer enhancements functionality (i.e. SCC AS of the controller 158 UE) is already in the signalling path. 160 If so, the SCC AS proxies the signalling without further handling as 161 there is already an existing local hub for the session. 163 If not, the SCC AS acts as local hub for the session. 165 2. Conventions 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in BCP 14, RFC 2119 170 [RFC2119]. 172 3. Requirements 174 REQ-1: It MUST be possible for a SIP proxy to indicate, and convey to 175 other SIP entities in the signalling path of a registration request, 176 support of a particular feature/capability. 178 REQ-2: It MUST be possible for a SIP proxy to indicate, and convey to 179 other SIP entities in the signalling path of a dialog-forming 180 request, support of a particular feature/capability. 182 REQ-3: It MUST be possible for a SIP proxy to indicate that the 183 indicated support of a feature/capability only applies to other SIP 184 entities in the direction towards one of the SIP endpoints in the 185 signalling path. 187 REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/ 188 capability, make any assumptions that SIP entities in the signalling 189 path that receive the indicator will support, or understand the 190 meaning of, the feature/capability, or even support the proxy 191 feature/capability indication mechanism as a whole. 193 REQ-5: A SIP proxy MUST be able to indicate support of a feature/ 194 capability to other SIP entities in the signaling path, even if some 195 SIP entities in the signaling path (possibly including the UAC and/or 196 UAS) do not support, or understand the meaning of, the feature/ 197 capability, or even support the proxy feature/capability indication 198 mechanism as a whole. 200 REQ-6: It MUST be possible to indicate whether indicated support of a 201 feature/capability applies to specific registration, to a specific 202 dialog, or to all dialogs created as part of INVITE transaction. 204 NOTE: This requirement might be fully implemented as part of the 205 protocol mechanism, or parts might be left to be specified in a 206 feature/capability specification, or it might be left to be specified 207 in a feature/capability specification completely. 209 REQ-7: It MUST be possible to assign additional parameters (either as 210 a single value, or a list of values) to a feature/capability 211 indicator, in order to provide additional information about the 212 feature/capability. 214 REQ-8: If a SIP entity receives a feature support indication that it 215 does not understand, it MUST act as if it hadn't received the 216 indication. 218 REQ-9: If a SIP entity that does not support the proxy feature/ 219 capability indication mechanism receives a feature support 220 indication, it MUST act as if it hadn't received the indication. 222 REQ-10: Other SIP entities MUST be able to make routing decisions 223 based on received feature/capability support indications. 225 REQ-11: A feature/capability support indicator MUST only be used to 226 indicate support of a feature/capability, and MUST NOT be used to 227 indicate whether procedures associated with the feature/capability 228 have been applied or not. 230 REQ-12: A procedure for registering feature/capability indication 231 values with IANA MUST be defined. 233 4. Security Considerations 235 Feature/capability support indications can provide sensitive 236 information about a SIP entity. RFC 3840 cautions against providing 237 sensitive information to another party. Once this information is 238 given out, any use may be made of it. 240 5. IANA Considerations 242 None identified. 244 6. Acknowledgements 246 Thanks to Paul Kyzivat and Robert Sparks for their comments and 247 guidance on the mailing list. Thanks to Andrew Allen and Dale Worley 248 for providing text on additional use-cases. Thanks to Cullen 249 Jennings for providing text on additional requirements. Thanks to 250 Dale Worley for providing comments and text improvement suggestions. 252 Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving 253 working procedure guidance. 255 7. Change Log 257 [RFC EDITOR NOTE: Please remove this section when publishing] 258 Changes from draft-ietf-sipcore-proxy-feature-reqs-xx 259 o Add text 260 Changes from draft-ietf-sipcore-proxy-feature-reqs-00 261 o New REQ-5 added (IETF#81). 262 o New REQ-9 added (Dale Worley). 263 o Text added to REQ-4 and REQ-5, indicating that the requirement 264 applies also in cases where an entity does not support the 265 mechanism as a whole (Dale Worley). 266 o Usage of "session establishment transactions" terminology in 267 REQ-6, in order to avoid misunderstanding of "session" (Dale 268 Worley). 269 o Editorial correction in REQ-7: "additional parameter"->"additional 270 parameters" 271 o Editorial clarifications to use-cases. 273 8. References 275 8.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 8.2. Informative References 282 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 283 "Indicating User Agent Capabilities in the Session 284 Initiation Protocol (SIP)", RFC 3840, August 2004. 286 [3GPP.23.237] 287 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 288 Stage 2", 3GPP TS 23.237 10.6.0, June 2011. 290 [3GPP.24.837] 291 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 292 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 293 10.0.0, April 2011. 295 Authors' Addresses 297 Christer Holmberg 298 Ericsson 299 Hirsalantie 11 300 Jorvas 02420 301 Finland 303 Email: christer.holmberg@ericsson.com 305 Ivo Sedlacek 306 Ericsson 307 Scheelevaegen 19C 308 Lund 22363 309 Sweden 311 Email: ivo.sedlacek@ericsson.com