SIPCORE Working Group C. Holmberg Internet-Draft I. Sedlacek Intended status: Standards Track Ericsson Expires: October 19, 2012 H. Kaplan Acme Packet April 17, 2012 Indication of features supported by proxy draft-ietf-sipcore-proxy-feature-01.txt Abstract This specification creates a new IANA registry, "SIP Feature Cap Registry", which is used to register indicators, "SIP feature caps", used by SIP entities to indicate support of features and capabilities, in cases where the Contact header field contains a URI that does not represent the SIP entity that wants to indicate support of its features and capabilities. This specification also defines a new SIP header field, Feature-Caps, that can be used by SIP entities to convey information about supported features and capabilities, using SIP feature caps. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 19, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Holmberg, et al. Expires October 19, 2012 [Page 1] Internet-Draft proxy feature April 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Holmberg, et al. Expires October 19, 2012 [Page 2] Internet-Draft proxy feature April 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. SIP Feature Caps . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Registration Trees . . . . . . . . . . . . . . . . . . . . 6 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 4.3.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 6 4.3.3. SIP Feature Cap Registration Tree . . . . . . . . . . 7 4.4. Registration Template . . . . . . . . . . . . . . . . . . 7 4.5. SIP Feature Cap Specification Requirements . . . . . . . . 9 4.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 4.5.2. Overall Description . . . . . . . . . . . . . . . . . 9 4.5.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 9 4.5.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 10 4.5.5. Implementation Details . . . . . . . . . . . . . . . . 10 4.5.6. Examples . . . . . . . . . . . . . . . . . . . . . . . 10 5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 10 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 11 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 12 5.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 12 5.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 12 5.3. SIP Message Type and Response Code Semantics . . . . . . . 13 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 5.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 13 5.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 14 5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 14 5.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. Registration of the Feature-Caps header field . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Holmberg, et al. Expires October 19, 2012 [Page 3] Internet-Draft proxy feature April 2012 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" extension, defined in RFC 3840 [RFC3840], provides a mechanism that allows a SIP message to convey information relating to the originator's features and capabilities, using the Contact header field. This specification creates a new IANA registry, "SIP Feature Cap Registry", which is used to register indicators, "SIP feature caps", that can be used by SIP entities to indicate support of features and capabilities, in cases where the Contact header field contains a URI that does not represent the SIP entity that wants to indicate support of its features and capabilities, and media feature tags cannot be used to indicate the support. Such cases are: o - The SIP entity acts as a SIP proxy. o - The SIP entity acts as a SIP registrar. o - The SIP entity acts as a B2BUA, where the Contact header field URI represents another SIP entity. This specification also defines a new SIP header field, Feature-Caps, that can be used by SIP entities to convey information about supported features and capabilities, using SIP feature caps. Unlike media feature tags, SIP feature caps are intended to only be used with the SIP protocol. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Definitions Downstream SIP entity: SIP entity in the direction towards which a SIP request is sent. Upstream SIP entity: SIP entity in the direction from which a SIP request is received. Holmberg, et al. Expires October 19, 2012 [Page 4] Internet-Draft proxy feature April 2012 4. SIP Feature Caps 4.1. Introduction A SIP feature cap can be used by SIP entities to indicate support of features and capabilities, in cases where media feature tags cannot be used, ie if the Contact header field contains a URI that does not represent the SIP entity that wants to indicate support of its features and capabilities. A value, or a list of values, can be associated with a SIP feature cap. [ref-to-section] defines how SIP feature caps are conveyed using the SIP Feature-Caps header field. 4.2. Syntax 4.2.1. General In a SIP feature cap name (ABNF: fcap-name), dots can be used to implement a SIP feature cap tree hierarchy (e.g. tree.feature.subfeature). The description of usage of such tree hierarchy must be described when registered. 4.2.2. ABNF The ABNF for the Feature-Caps header field is: feature-cap = ["+"] fcap-name [EQUAL LDQUOT (fcap-value-list / string-value ) RDQUOT] fcap-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / "." / "-" / "%" ) fcap-value-list = fcap-value *("," fcap-value) fcap-value = ["!"] (token-nobang / boolean / numeric) token-nobang = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) boolean = "TRUE" / "FALSE" numeric = "#" numeric-relation number numeric-relation = ">=" / "<=" / "=" / (number ":") number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">" qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D / %x3F-5B / %x5D-7E / UTF8-NONASCII ;;gdtext as defined in RFC 3261 Holmberg, et al. Expires October 19, 2012 [Page 5] Internet-Draft proxy feature April 2012 Figure 1: ABNF 4.3. Registration Trees 4.3.1. General The following subsections define registration "trees", distinguished by the use of faceted names (e.g., names of the form "tree.feature- name"). The tree definitions are based on the global tree and sip tree defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841 [RFC3841]. Additional feature caps trees can be created by IANA, following the same rules and procedures as defined for media feature tags in section 3.1.4 of RFC 2506 [RFC2506]. The acceptance of the proposed designation is at the discretion of IANA. If IANA believes that additional information, or clarification, is needed, it can request an updated proposal from the proposing organization. When a SIP feature cap is registered in any registration tree, no leading "+" is used in the registration. 4.3.2. Global Tree The SIP feature cap global tree is based on the media feature tag global tree defined in RFC 2506 [RFC2506]. A SIP feature cap for the global tree will be registered by the IANA after review by a designated expert. That review will serve to ensure that the SIP feature cap meets the technical requirements of this specification. A SIP feature cap in the global tree will be distinguished by the leading facet "g.". An organization can propose either a designation indicative of the feature, (e.g., "g.blinktags") or a faceted designation including the organization name (e.g., "g.organization.blinktags"). When a SIP feature cap is registered in the global tree, it needs to meet the "Expert Review" policies defined in RFC 5226 [RFC5226]. A designated area expert will review the proposed SIP feature cap, and consult with members of related mailing lists. Holmberg, et al. Expires October 19, 2012 [Page 6] Internet-Draft proxy feature April 2012 4.3.3. SIP Feature Cap Registration Tree The SIP feature cap sip tree is based on the media feature tag sip tree defined in RFC 3840 [RFC3840]. A SIP feature cap in the sip tree will be distinguished by the leading facet "sip.". When a SIP feature cap is registered in the sip tree, it needs to meet the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An RFC, which contains the registration of the SIP feature cap, must be published. 4.4. Registration Template To: sip-feature-caps@apps.ietf.org (SIP feature caps mailing list) Subject: Registration of SIP feature cap XXXX | Instructions are preceded by `|'. Some fields are optional. SIP feature cap name: Summary of feature indicated by this SIP feature cap: | The summary should be no longer than 4 lines. More | detailed information can be provided in the SIP feature | cap specification SIP feature cap specification reference: | The reference MUST contain the information listed in | section XX of XXXX (IANA: Replace XXXX with assigned | RFC number of this specification Values appropriate for use with this SIP feature cap: | If no values are defined for the SIP feature cap, | indicate "N/A". Details about SIP feature cap values | MUST be defined in the SIP feature cap specification. The SIP feature cap is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: [optional] | For applications, also specify the number of the | first version which will use the SIP feature cap, Holmberg, et al. Expires October 19, 2012 [Page 7] Internet-Draft proxy feature April 2012 | if applicable. Examples of typical use: [optional] Related standards or documents: [optional] Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms: [optional] Interoperability considerations: [optional] Security considerations: Privacy concerns, related to exposure of personal information: Denial of service concerns related to consequences of specifying incorrect values: Other: Additional information: [optional] Keywords: [optional] Related SIP feature caps: [optional] Name(s) & email address(es) of person(s) to contact for further information: Intended usage: | one of COMMON, LIMITED USE or OBSOLETE Author/Change controller: Requested IANA publication delay: [optional] | A delay may only be requested for final placement | in the global or IETF trees, with a maximum of two | months. Organizations requesting a registration | with a publication delay should note that this | delays only the official publication of the SIP | feature cap and does not prevent information on | it from being disseminated by the members of the | relevant mailing list. Holmberg, et al. Expires October 19, 2012 [Page 8] Internet-Draft proxy feature April 2012 Other information: [optional] | Any other information that the author deems | interesting may be added here. Figure 2: Registration Template 4.5. SIP Feature Cap Specification Requirements 4.5.1. General A SIP feature cap specification MUST address the issues defined in the following subsections, or document why an issue is not applicable for the specific SIP feature cap. A reference to the specification MUST be provided when the SIP feature cap is registered with IANA (see [ref-to-temp]). It is bad practice for SIP feature cap specifications to repeat procedures defined in this specification, unless needed for clarification or emphasis purpose. A SIP feature cap specification MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, a specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if features associated with the SIP feature cap require it. 4.5.2. Overall Description The SIP feature cap specification MUST contain an overall description of the SIP feature cap: how it is used to indicate support of a feature, a description of the feature associated with the SIP feature cap, and a description of any additional information (conveyed using one or more SIP feature cap values) that can be conveyed together with the SIP feature cap. 4.5.3. Feature Cap Values A SIP feature cap can have an associated value, or a list of values. A SIP feature cap value MUST conform to the ABNF defined in Section 4.2.2. The SIP feature cap specification MUST define the syntax and semantics of any value defined for the SIP feature cap, including possible restrictions related to the usage of a specific value. A SIP feature cap value can share the name with a value defined for Holmberg, et al. Expires October 19, 2012 [Page 9] Internet-Draft proxy feature April 2012 another SIP feature cap. However, a value defined for a SIP feature cap is feature cap specific, and can only be used with a SIP feature cap for which the value has explicitly been defined. It is STRONLY RECOMMENDED to not re-use a value name that already has been defined for another SIP feature cap, unless the semantics of the values are the same. 4.5.4. Usage Restrictions If there are restrictions on how SIP entities can insert a SIP feature cap, the SIP feature cap specification MUST document such restrictions. There might be restrictions related to whether entities are allowed to insert a SIP feature cap in registration related messages, standalone transaction messages, or dialog related messages, whether entities are allowed to insert a SIP feature cap in requests or responses, whether entities also need to support other features in order to insert a SIP feature cap, and whether entities are allowed to indicate support of a feature in conjunction with another feature. 4.5.5. Implementation Details The SIP feature cap specification SHOULD define the procedure regarding how implementers shall implement and use the Feature Cap, or refer to other locations where implementers can find that information. NOTE: Sometimes a SIP feature cap designer might choose to not reveal the implementation details of a SIP feature cap. However, in order to allow multiple implementations to support the SIP feature cap, designers are strongly encouraged to provide the implementation details. 4.5.6. Examples It is RECOMMENDED that the SIP feature cap specification provide demonstrative message flow diagrams, paired with complete messages and message descriptions. Note that example flows are by definition informative, and do not replace normative text. 5. Feature-Caps Header Field Holmberg, et al. Expires October 19, 2012 [Page 10] Internet-Draft proxy feature April 2012 5.1. Introduction The Feature-Caps header field is used by SIP entities to convey support of features and capabilities, using SIP feature caps. SIP feature caps inserted in a Feature-Caps header field indicate that the SIP entity that inserted the header field supports the associated features. NOTE: It is not possible to convey the address of the SIP entity as a Feature-Caps header field parameter. Each feature that requires address information to be conveyed need to define a way to convey that information as part of the associated SIP feature cap value. The SIP feature cap specification MUST specify for which SIP methods and message types, and the associated semantics, the SIP feature cap is applicable. See section [ref-to-reg-temp} for more information. No semantics is defined for SIP feature caps present in SIP methods and message types not covered by the associated SIP feature cap specification. Within a given Feature-Caps header field, SIP feature caps are listed in a non-priority order, and for a given header field any order of listed SIP feature caps have the same meaning. For example, "foo;bar" and "bar;foo" have the same meaning(i.e. that the SIP entity that inserted the feature caps supports the features associated with the "foo" and "bar" SIP feature caps. 5.2. User Agent and Proxy Behavior 5.2.1. General If the URI in a Contact header field of a request or response represents a UA, the UA MUST NOT indicate supported features and capabilities using a Feature-Caps header field within that request or response. When a UA receives a SIP request, or response, that contains one or more Feature-Caps header fields, the Feature Caps in the header field inform the UA is about the features supported by the entities that inserted the header fields. Procedures how features are invoked are outside the scope of this specification, and MUST be described by individual Feature Cap specifications. When the UA receives the SIP request or the response, the SIP feature caps in the topmost Feature-Caps header field will represent the supported features "closest" to the UA. Holmberg, et al. Expires October 19, 2012 [Page 11] Internet-Draft proxy feature April 2012 5.2.2. B2BUA Behavior The procedures in this section applies to UAs that are part of B2BUAs, but where the URI in the Contact header field does not represent the UA, because the B2BUA is also acting as a proxy and inserts its URI e.g. in a Record-Route header field. When a UA sends a SIP request, if the UA wants to indicate support of features towards its downstream SIP entities, it adds a Feature-Caps header field to the request, together with one or more Feature Caps associated with the supported features, before it forwards the request. If the SIP request is triggered by another SIP request that the B2BUA has received, the UA MAY forward those Feature-Caps header field by copying them to the outgoing SIP request, similar to a SIP proxy, before it adds its own Feature-Caps header field to the SIP request. When a UA receives a SIP response, if the UA wants to indicate support of features towards its upstream SIP entities, it adds a Feature-Caps header field to the response, together with one or more Feature Caps associated with the supported features, before it forwards the response. If the SIP response is triggered by another SIP response that the B2BUA has received, the UA MAY forward those Feature-Caps header field by copying them to the outgoing SIP response, similar to a SIP proxy, before it adds its own Feature-Caps header field to the SIP response. 5.2.3. Registrar Behavior If a SIP registrar wants to indicate support of features towards its upstream SIP entities, it can insert a Feature-Caps header field, together with Feature Caps associated with the supported features, in a REGISTER response. 5.2.4. Proxy behavior When a SIP proxy receives a SIP request, if the proxy wants to indicate support of features towards its downstream SIP entities, it adds a Feature-Caps header field to the request, together with one or more SIP feature caps associated with the supported features, before it forwards the request. When a proxy adds a Feature-Caps header field to a SIP message, it MUST place the header field before any existing Feature-Caps header fields in the request. Holmberg, et al. Expires October 19, 2012 [Page 12] Internet-Draft proxy feature April 2012 When a proxy receives a SIP response, if the proxy wants to indicate support of features towards its upstream SIP entities, it adds a Feature-Caps header field to the response, together with one or more SIP feature caps associated with the supported features, before it forwards the response. When a proxy adds a Feature-Caps header field to a SIP response, it MUST place the header field before any existing Feature-Caps header field in the response. 5.3. SIP Message Type and Response Code Semantics 5.3.1. General This section describes the general usage and semantics of the Feature-Caps header field for different SIP message types and response codes. The usage and semantics of a specific SIP feature cap MUST be described in the associated SIP feature cap specification. NOTE: Future specifications can define usage and semantics of the Feature-Caps header field for SIP methods, response codes and request types not specified in this specification. 5.3.2. SIP Dialog The Feature-Caps header field can be used within an initial SIP request for a dialog, within a target refresh SIP request, and within any 18x or 2xx response associated with such requests. If a SIP feature cap is inserted in a Feature-Caps header field of an initial request for a dialog, or within a response of such request, it indicates to the receivers of the request (or response) that the feature associated with the SIP feature cap is supported for the duration of the dialog, until a target refresh request is sent for the dialog, or the dialog is terminated. Unless a SIP feature cap is inserted in a Feature-Caps header field or a target refresh request, or within a response of such request, it indicates to the receivers of the request (or response) that the feature is no long supported for the dialog. For a given dialog a SIP entity MUST insert the same SIP feature caps in all 18x and 2xx responses associated with a given transaction. Holmberg, et al. Expires October 19, 2012 [Page 13] Internet-Draft proxy feature April 2012 5.3.3. SIP Registration (REGISTER) The Feature-Caps header field can be used within a SIP REGISTER request, and within the 200 (OK) response associated with such request. If a SIP feature cap is inserted in a Feature-Caps header field of a SIP REGISTER request, or within a response of such request, it indicates to the receivers of the request (or response) that the feature associated with the SIP feature cap is supported for the duration of the registration, and for all SIP transactions associated with the registration, until the registration is re-freshed or terminated. Unless a SIP feature cap is inserted in a Feature-Caps header field or a re-registration, or within a response of such request, it indicates to the receivers of the request (or response) that the feature is no long supported for the registration. 5.3.4. SIP Stand-Alone Transactions The Feature-Caps header field can be used within a standalone SIP request, and within any 18x or 2xx response associated with such request. If a SIP feature cap is inserted in a Feature-Caps header field of a standalone request, or within a response of such request, it indicates to the receivers of the request (or response) that the feature associated with the SIP feature cap is supported for the duration of the standalone transaction. 5.4. Syntax 5.4.1. ABNF The ABNF for the Feature-Caps header fields is: Feature-Caps = ("Feature-Caps" / "fc") HCOLON fc-value *(COMMA fc-value) fc-value = "*" *(SEMI feature-cap) Figure 3: ABNF NOTE: A "*" value means that no information regarding which SIP entity, or domain, that indicate support of features is provided. Holmberg, et al. Expires October 19, 2012 [Page 14] Internet-Draft proxy feature April 2012 6. IANA Considerations 6.1. Registration of the Feature-Caps header field This specification registers a new SIP header field, Feature-Caps, according to the process of RFC 3261 [RFC3261]. The following is the registration for the Feature-Caps header field: RFC Number: RFC XXX Header Field Name: Feature-Caps Header Field Name: Feature-Caps Compact Form: fc 7. Security Considerations SIP feature caps can provide sensitive information about a SIP entity. RFC 3840 cautions against providing sensitive information to another party. Once this information is given out, any use may be made of it. 8. Acknowledgements 9. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-sipcore-proxy-feature-04/ draft-ietf-sipcore-proxy-feature-00 o Media feature tags replaced with SIP feature caps, based on SIPCORE consensus at IETF#83 (Paris). o Editorial corrections and modifications. Changes from draft-holmberg-sipcore-proxy-feature-03 o Hadriel Kaplan added as co-author. o Terminology change: instead of talking of proxies, talk about entities which are not represented by the URI in a Contact header field (http://www.ietf.org/mail-archive/web/sipcore/current/ msg04449.html). o Clarification regarding the usage of the header field in 18x/2xx responses (http://www.ietf.org/mail-archive/web/sipcore/current/ msg04449.html). Holmberg, et al. Expires October 19, 2012 [Page 15] Internet-Draft proxy feature April 2012 o Specifying that feature support can also be indicated in target refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ current/msg04454.html). o Feature Cap specification registration information added. Changes from draft-holmberg-sipcore-proxy-feature-02 o Definition, and usage of, a new header field, instead of Path, Record-Route, Route and Service-Route. Changes from draft-holmberg-sipcore-proxy-feature-01 o Requirement section added o Use-cases and examples updated based on work in 3GPP Changes from draft-holmberg-sipcore-proxy-feature-00 o Additional use-cases added o Direction section added 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 10.2. Informative References [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999. [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [3GPP.23.237] Holmberg, et al. Expires October 19, 2012 [Page 16] Internet-Draft proxy feature April 2012 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; Stage 2", 3GPP TS 23.237 10.9.0, March 2012. [3GPP.24.837] 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 10.0.0, April 2011. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Ivo Sedlacek Ericsson Scheelevaegen 19C Lund 22363 Sweden Email: ivo.sedlacek@ericsson.com Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA Email: hkaplan@acmepacket.com Holmberg, et al. Expires October 19, 2012 [Page 17]