idnits 2.17.1 draft-holmberg-sipcore-proxy-feature-00.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 24, 2010) is 4962 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 28, 2011 September 24, 2010 7 Indication of features supported by proxy 8 draft-holmberg-sipcore-proxy-feature-00.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 March 28, 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 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. User Agent behavior . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Feature tag semantics . . . . . . . . . . . . . . . . . . . . . 4 61 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.1. Example name . . . . . . . . . . . . . . . . . . . . . . . 5 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 66 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 12.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 12.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The SIP "Caller Preferences" extension defined in RFC 3840 [RFC3840] 75 provides a mechanism that allows a SIP message to convey information, 76 using feature tags, relating to the originator's capabilities. 78 Feature information can be useful for other SIP entities, that might 79 trigger actions and enable functions based on features supported by 80 other SIP entities. 82 This document extends the rr-param rule defined in RFC 3261 83 [RFC3261], so that it can be used to convey feature tags indicating 84 support of features in SIP proxies. The rr-param rule is used in the 85 SIP Path, Route, Record-Route and Service-Route header fields. 87 1.1. Use-case: IMS Service Continuity 89 The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia 90 Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for 91 handover of Packet Switched (PS) sessions to Circuit Switched (CS). 92 The handover can be performed by a Service Centralization and 93 Continuity Application Server (SCC AS), or by a SCC AS together with 94 an Access Transfer Control Function (ATCF), that acts as a SIP proxy. 95 Delegating part of the session handover functionality to an ATCF 96 provides advantages related to voice interruption during session 97 handover etc, since it is located in the same network as the user. 99 In order for a SCC AS to delegate part of the session handover 100 functionality to an ATCF, when it receives a SIP REGISTER request, it 101 needs to be informed whether there is a proxy that provides ATCF 102 functionality in the registration path. 104 2. Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in BCP 14, RFC 2119 109 [RFC2119]. 111 3. Definitions 113 The rr-param rule defined in RFC 3261 [RFC3261]: 115 rr-param = generic-param 117 is extended to: 119 rr-param = generic-param / feature-param 121 where feature-param is defined in Section 9 of RFC 3840 [RFC3840]. 123 4. User Agent behavior 125 This specification does not specify any new User Agent behavior. 127 5. Proxy behavior 129 When a proxy inserts a Path header field (during registration), a 130 Service-Route header field (during registration) or a Record-Route 131 header field (during a dialog establishment), it MAY insert a feature 132 tag in the header field. 134 If a feature tag is inserted in a Path or Service-Route header field 135 during registration, the resource identified by the URI in the header 136 field MUST provide support for the associated feature for all dialogs 137 associated with the registration, until the registration is 138 terminated or re-freshed. 140 If a feature tag is inserted in a Record-Route header field during a 141 dialog establishment, the resource identified by the URI in the 142 header field MUST provide support for the associated feature until 143 the dialog is terminated. 145 6. Feature tag semantics 147 The feature tag in a header field constructed using rr-param rule 148 indicates support of the feature in the resource identified by the 149 URI in the header field. 151 In order to insert a feature tag in a SIP header field constructed by 152 using rr-param rule, the feature specification MUST specify the 153 semantics of the feature tag when inserted in that specific header 154 field. Unless the feature specification defines such semantics, a 155 the feature tag MUST NOT be included in that specific header field. 157 NOTE: If a route set is built using Path, Record-Route or Service- 158 Route header fields, any inserted feature tag will be copied into the 159 associated Route header fields, together with other header field 160 parameters. This specification does not define any specific meaning 161 of the feature tags present in Route header fields in such cases. 163 7. Examples 165 7.1. Example name 167 TBD 169 Alice P1 REGISTRAR 170 | | | 171 |--- REGISTER-------------->| | 172 | | | 173 | |--- REGISTER-------------->| 174 | | Path: P1;+g.3gpp.srvcc | 175 | | | 176 | | | 177 | |<-- 200 OK ----------------| 178 | | Path: P1;+g.3gpp.srvcc | 179 | | Service-Route: REG | 180 |<-- 200 OK ----------------| | 181 | Path: P1;+g.3gpp.srvcc | | 182 | Service-Route: REG | | 183 | | | 185 Figure 1: Example call flow 187 8. IANA Considerations 189 TBD 191 9. Security Considerations 193 Feature tags can provide sensitive information about a SIP entity. 194 RFC 3840 cautions against providing sensitive information to another 195 party. Once this information is given out, any use may be made of 196 it. 198 10. Acknowledgements 200 Thanks to Paul Kyzivat for his comments and guidance on the mailing 201 list. 203 11. Change Log 205 [RFC EDITOR NOTE: Please remove this section when publishing] 206 Changes from draft-holmberg-sipcore-proxy-feature-00 207 o To be added when the -01 version is submitted 209 12. References 211 12.1. Normative References 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 217 A., Peterson, J., Sparks, R., Handley, M., and E. 218 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 219 June 2002. 221 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 222 "Indicating User Agent Capabilities in the Session 223 Initiation Protocol (SIP)", RFC 3840, August 2004. 225 12.2. Informative References 227 [3GPP.23.237] 228 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 229 Stage 2", 3GPP TS 23.237 10.2.0, June 2010. 231 Authors' Addresses 233 Christer Holmberg 234 Ericsson 235 Hirsalantie 11 236 Jorvas 02420 237 Finland 239 Email: christer.holmberg@ericsson.com 241 Ivo Sedlacek 242 Ericsson 243 Scheelevaegen 19C 244 Lund 22363 245 Sweden 247 Email: ivo.sedlacek@ericsson.com