| SIPCORE Working Group | C.H. Holmberg |
| Internet-Draft | I.S. Sedlacek |
| Intended status: Standards Track | Ericsson |
| Expires: April 30, 2012 | October 28, 2011 |
Indication of features supported by proxy
draft-holmberg-sipcore-proxy-feature-03.txt
The Session Initiation Protocol (SIP) "Caller Preferences" extension, defined in RFC 3840, provides a mechanism that allows a SIP message to convey information relating to the originator's features and capabilities. This document defines a new SIP header field, Feature-Caps, that can be used by entities to indicate support of features and capabilities, in case they cannot use the Contact header field for that purpose.
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 April 30, 2012.
Copyright (c) 2011 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 (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.
The Session Initiation Protocol (SIP) "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.
This document defines a new SIP header field, Feature-Caps, that can be used by entities to indicate support of features and capabilities, in case they cannot use the Contact header field for that purpose.
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].
Proxy: Within this specification, a "proxy" refers to an entity that does not indicate supported features using the Contact header field. Normally, however, entities that indicate support of features do not act as pure proxies, as defined by RFC 3261, but rather contain different levels of B2BUAs functionality.
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.
A UA MUST NOT, except when it acts as a SIP registrar, insert a Feature-Caps header field in a SIP request or response.
NOTE: Feature-caps header field values of a request are not copied to the associated responses.
When a UA receives a SIP request, or response, that contains one or more Feature-Caps header fields, the feature tags in the header field inform the UA is about the features supported by the proxies that inserted the header fields. Procedures how features are invoked are outside the scope of this specification, and MUST be described by individual feature tag specifications.
When the UA receives the SIP request or the response, the feature tags in the topmost Feature-Caps header field will represent the supported features "closest" to the UA.
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 tags associated with the supported features, in a REGISTER response.
When a 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 feature tags associated with the supported features, before it forwards the request.
When a proxy adds a Feature-Caps header field to a SIP request, it MUST place the header field before any existing Feature-Caps header field in the request.
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 feature tags 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.
Each value of a Feature-Caps header field MUST contain a "*" value, followed by one or more feature tags, associated with the supported features, separated by semicolon (";").
A "*" value means that no information regarding which proxy, or domain, that support the features associated with the feature tags, is provided.
NOTE: When used in a Contact header field, a "*" value has an "any URI" meaning. When used in a Feature-Caps header field, it simply means that no URI information is provided.
This section describes how the Feature-Caps header field is used, and the associated semantics, with different SIP methods and response codes.
NOTE: Future specification can define usage semantics of the Feature-Caps header fields for SIP methods, response codes and request types not specified in this specification.
The Feature-Caps header field can be used within an initial SIP request for a dialog, and within any provisional or successful final response (18x and 2xx) associated with such request.
If a feature tag is inserted in a Feature-Caps header field of an initial SIP request or response for a dialog, the feature associated with the feature tag MUST be supported for the dialog, until the dialog is terminated.
The Feature-Caps header field can be used within a SIP REGISTER request, and within the 200 (OK) response of such request.
If a feature tag is inserted in a Feature-Caps header field of a SIP REGISTER request or response, the feature associated with the feature tag MUST be supported for the registration, and all SIP transactions associated with the registration, until the registration is re-freshed or terminated.
The Feature-Caps header field can be used within an request for standalone SIP transaction, and within any provisional or successful final response (18x and 2xx) associated with such request.
If a feature tag is inserted in a Feature-Caps header field of an request or response for a standalone transaction, the feature associated with the feature tag MUST be supported for the standalone transaction.
The ABNF for the Feature-Caps header fields is:
Feature-Caps = ("Feature-Caps" / "fc") HCOLON fc-value
*(COMMA fc-value)
fc-value = "*" *(SEMI feature-param)
;;feature-param from RFC 3840
Feature tags inserted in a Feature-Caps header field indicate that the SIP entity that inserted the header field support of the associated features.
In order to use a feature tag in a Feature-Caps header field, the feature tag specification MUST specify the semantics of the feature tag when inserted in that specific header field. Unless the feature specification defines such semantics, a the feature tag MUST NOT be used in a Feature-Caps header field.
Within a given Feature-Caps header field, features are listed in a non-priority order, and for a given header field the the order of listed features have the same meaning. For example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the entity that inserted the feature tags support the features associated with the "foo" and "bar" feature tags.
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
Compact Form: fc
Feature tags 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.
Thanks to Paul Kyzivat and Dale Worley for their comments and guidance on the mailing list.
The usage of a new header field, and the header field name, were suggested by Hadriel Kaplan.
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-sipcore-proxy-feature-02
Changes from draft-holmberg-sipcore-proxy-feature-01
Changes from draft-holmberg-sipcore-proxy-feature-00
| [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. |
| [RFC3840] | Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. |
| [3GPP.23.237] | 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; Stage 2", 3GPP TS 23.237 10.7.0, September 2011. |
| [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. |