draft-ietf-sipcore-proxy-feature-02.txt   draft-ietf-sipcore-proxy-feature-03.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft I. Sedlacek Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: November 10, 2012 H. Kaplan Expires: December 13, 2012 H. Kaplan
Acme Packet Acme Packet
May 9, 2012 June 11, 2012
Indication of features supported by proxy Mechanism to indicate support of features and capabilities in the
draft-ietf-sipcore-proxy-feature-02.txt Session Initiation Protocol (SIP)
draft-ietf-sipcore-proxy-feature-03.txt
Abstract Abstract
This specification creates a new IANA registry, "SIP Feature Cap This specification creates a new IANA registry, "Feature Cap
Registry", which is used to register indicators, "SIP feature caps", Registry", for registering "feature caps", which are used by SIP
used by SIP entities to indicate support of features and entities not represented by the URI of the Contact header field to
capabilities, in cases where the Contact header field contains a URI indicate support of features and capabilities, where media feature
that does not represent the SIP entity that wants to indicate support tags cannot be used to indicate the support.
of its features and capabilities.
This specification also defines a new SIP header field, Feature-Caps, This specification also defines a new SIP header field, Feature-Caps,
that can be used by SIP entities to convey information about to convey feature caps in SIP messages.
supported features and capabilities, using SIP feature caps.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2012. This Internet-Draft will expire on December 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. SIP Feature Caps . . . . . . . . . . . . . . . . . . . . . . . 5 4. Feature Caps . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 5 4.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 5
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 5
4.2.3. SIP Feature Cap Registration Tree . . . . . . . . . . 6 4.2.3. Feature Cap Registration Tree . . . . . . . . . . . . 6
4.3. Registration Template . . . . . . . . . . . . . . . . . . 6 4.3. Registration Template . . . . . . . . . . . . . . . . . . 6
4.4. SIP Feature Cap Specification Requirements . . . . . . . . 8 4.4. Feature Cap Specification Requirements . . . . . . . . . . 8
4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Overall Description . . . . . . . . . . . . . . . . . 8 4.4.2. Overall Description . . . . . . . . . . . . . . . . . 8
4.4.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 8 4.4.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 8
4.4.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 9 4.4.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 9
4.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 9
5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 9 5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 9
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 10 5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 10
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 10 5.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 11 5.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 11
5.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 11 5.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 11
5.3. SIP Message Type and Response Code Semantics . . . . . . . 11 5.3. SIP Message Type and Response Code Semantics . . . . . . . 11
5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 12 5.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 12
5.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 12 5.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 12
5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 13 5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 13
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Syntax: SIP feature cap . . . . . . . . . . . . . . . . . 13 6.2. Syntax: feature cap . . . . . . . . . . . . . . . . . . . 13
6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Syntax: Feature-Caps header field . . . . . . . . . . . . 14 6.3. Syntax: Feature-Caps header field . . . . . . . . . . . . 14
6.3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Registration of the Feature-Caps header field . . . . . . 14 7.1. Registration of the Feature-Caps header field . . . . . . 14
7.2. Global Feature Cap Registration Tree . . . . . . . . . . . 14 7.2. Global Feature Cap Registration Tree . . . . . . . . . . . 15
7.3. SIP Feature Cap Registration Tree . . . . . . . . . . . . 15 7.3. Feature Cap Registration Tree . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences"
extension, defined in RFC 3840 [RFC3840], provides a mechanism that extension, defined in RFC 3840 [RFC3840], provides a mechanism that
allows a SIP message to convey information relating to the allows a SIP message to convey information relating to the
originator's features and capabilities, using the Contact header originator's features and capabilities, using the Contact header
field. field.
This specification creates a new IANA registry, "SIP Feature Cap This specification creates a new IANA registry, "Feature Cap
Registry", which is used to register indicators, "SIP feature caps", Registry", for registering "feature caps", which are used by SIP
that can be used by SIP entities to indicate support of features and entities not represented by the URI of the Contact header field to
capabilities, in cases where the Contact header field contains a URI indicate support of features and capabilities, where media feature
that does not represent the SIP entity that wants to indicate support tags cannot be used to indicate the support. Such cases are:
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 proxy.
o - The SIP entity acts as a SIP registrar. o - The SIP entity acts as a SIP registrar.
o - The SIP entity acts as a B2BUA, where the Contact header field o - The SIP entity acts as a B2BUA, where the Contact header field
URI represents another SIP entity. URI represents another SIP entity.
This specification also defines a new SIP header field, Feature-Caps, This specification also defines a new SIP header field, Feature-Caps,
that can be used by SIP entities to convey information about to convey feature caps in SIP messages.
supported features and capabilities, using SIP feature caps.
Unlike media feature tags, SIP feature caps are intended to only be NOTE: Unlike media feature tags, feature caps are intended to only be
used with the SIP protocol. used with the SIP protocol.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
Downstream SIP entity: SIP entity in the direction towards which a Downstream SIP entity: SIP entity in the direction towards which a
SIP request is sent. SIP request is sent.
Upstream SIP entity: SIP entity in the direction from which a SIP Upstream SIP entity: SIP entity in the direction from which a SIP
request is received. request is received.
4. SIP Feature Caps 4. Feature Caps
4.1. Introduction 4.1. Introduction
A SIP feature cap can be used by SIP entities to indicate support of Feature caps are used by SIP entities not represented by the URI of
features and capabilities, in cases where media feature tags cannot the Contact header field to indicate support of features and
be used, ie if the Contact header field contains a URI that does not capabilities, where media feature tags cannot be used to indicate the
represent the SIP entity that wants to indicate support of its support.
features and capabilities.
A value, or a list of values, can be associated with a SIP feature A value, or a list of values, that provides additional information
cap. about the supported feature or capability, can be associated with a
feature cap.
Section 5 defines how SIP feature caps are conveyed using the SIP Section 5 defines how feature caps are conveyed using the Feature-
Feature-Caps header field. Caps header field.
The SIP feature cap ABNF is defined in Section 6.2.2. The feature cap ABNF is defined in Section 6.2.2.
4.2. Registration Trees 4.2. Registration Trees
4.2.1. General 4.2.1. General
The following subsections define registration "trees", distinguished The following subsections define registration "trees", distinguished
by the use of faceted names (e.g., names of the form "tree.feature- by the use of faceted names (e.g., names of the form "tree.feature-
name"). name").
The trees defined herein are similar to the global tree and sip tree The trees defined herein are similar to the global tree and sip tree
defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840
[RFC3841]. Other registration trees are outside the scope of this [RFC3840]. Other registration trees are outside the scope of this
specification. specification.
NOTE: Compared to RFC 2506, this specification only defines a global NOTE: In contrast to RFC 2506 and RFC 3840, this specification only
tree and a sip tree, as they are the only tree defined in RFC 2506 defines a global tree and a sip tree, as they are the only trees
that have been used for defining media feature tags for SIP. defined in those RFCs that have been used for defining SIP-specific
media feature tags.
When a SIP feature cap is registered in any registration tree, no When a feature cap is registered in any registration tree, no leading
leading "+" is used in the registration. "+" is used in the registration.
4.2.2. Global Tree 4.2.2. Global Tree
The SIP feature cap global tree is similar to the media feature tag The feature cap global tree is similar to the media feature tag
global tree defined in RFC 2506 [RFC2506]. global tree defined in RFC 2506 [RFC2506].
A SIP feature cap for the global tree will be registered by the IANA A feature cap for the global tree will be registered by the IANA
after review by a designated expert. That review will serve to after review by a designated expert. That review will serve to
ensure that the SIP feature cap meets the technical requirements of ensure that the feature cap meets the technical requirements of this
this specification. specification.
A SIP feature cap in the global tree will be distinguished by the A feature cap in the global tree will be distinguished by the leading
leading facet "g.". An organization can propose either a designation facet "g.". An organization can propose either a designation
indicative of the feature, (e.g., "g.blinktags") or a faceted indicative of the feature, (e.g., "g.blinktags") or a faceted
designation including the organization name (e.g., designation including the organization name (e.g.,
"g.organization.blinktags"). "g.organization.blinktags").
When a SIP feature cap is registered in the global tree, it needs to When a feature cap is registered in the global tree, it needs to meet
meet the "Expert Review" policies defined in RFC 5226 [RFC5226]. A the "Expert Review" policies defined in RFC 5226 [RFC5226]. A
designated area expert will review the proposed SIP feature cap, and designated area expert will review the proposed feature cap, and
consult with members of related mailing lists. consult with members of related mailing lists.
4.2.3. SIP Feature Cap Registration Tree 4.2.3. Feature Cap Registration Tree
The SIP feature cap sip tree is similar to the media feature tag sip The feature cap sip tree is similar to the media feature tag sip tree
tree defined in RFC 3840 [RFC3840]. defined in RFC 3840 [RFC3840].
A SIP feature cap in the sip tree will be distinguished by the A feature cap in the sip tree will be distinguished by the leading
leading facet "sip.". facet "sip.".
When a SIP feature cap is registered in the sip tree, it needs to When a feature cap is registered in the sip tree, it needs to meet
meet the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An RFC,
RFC, which contains the registration of the SIP feature cap, must be which contains the registration of the feature cap, MUST be
published. published.
4.3. Registration Template 4.3. Registration Template
To: sip-feature-caps@apps.ietf.org (SIP feature caps mailing list) To: sip-feature-caps@apps.ietf.org (feature caps mailing list)
Subject: Registration of SIP feature cap XXXX Subject: Registration of feature cap XXXX
| Instructions are preceded by `|'. Some fields are optional. | Instructions are preceded by '|'. Some fields are optional.
SIP feature cap name: Feature cap name:
Summary of feature indicated by this SIP feature cap: Summary of feature indicated by this feature cap:
| The summary should be no longer than 4 lines. More | The summary should be no longer than 4 lines. More
| detailed information can be provided in the SIP feature | detailed information can be provided in the SIP feature
| cap specification. | cap specification.
SIP feature cap specification reference: Feature cap specification reference:
| The referenced specification MUST contain the information | The referenced specification MUST contain the information
| listed in section XX of XXXX (IANA: Replace XXXX with | listed in section XX of XXXX (IANA: Replace XXXX with
| assigned RFC number of this specification. | assigned RFC number of this specification.
Values appropriate for use with this SIP feature cap: Values appropriate for use with this feature cap:
| If no values are defined for the SIP feature cap, | If no values are defined for the feature cap,
| indicate "N/A". Details about SIP feature cap values | indicate "N/A". Details about feature cap values
| MUST be defined in the SIP feature cap specification. | MUST be defined in the feature cap specification.
The SIP feature cap is intended primarily for The feature cap is intended primarily for
use in the following applications, protocols, use in the following applications, protocols,
services, or negotiation mechanisms: [optional] services, or negotiation mechanisms: [optional]
| For applications, also specify the number of the | For applications, also specify the number of the
| first version which will use the SIP feature cap, | first version which will use the feature cap,
| if applicable. | if applicable.
Examples of typical use: [optional] Examples of typical use: [optional]
Considerations particular to use in individual Considerations particular to use in individual
applications, protocols, services, or negotiation applications, protocols, services, or negotiation
mechanisms: [optional] mechanisms: [optional]
Interoperability considerations: [optional] Interoperability considerations: [optional]
skipping to change at page 7, line 39 skipping to change at page 7, line 39
Denial of service concerns related to consequences Denial of service concerns related to consequences
of specifying incorrect values: of specifying incorrect values:
Other: Other:
Additional information: [optional] Additional information: [optional]
Keywords: [optional] Keywords: [optional]
Related SIP feature caps: [optional] Related feature caps: [optional]
Name(s) & email address(es) of person(s) to Name(s) & email address(es) of person(s) to
contact for further information: contact for further information:
Intended usage: Intended usage:
| one of COMMON, LIMITED USE or OBSOLETE | one of COMMON, LIMITED USE or OBSOLETE
Author/Change controller: Author/Change controller:
Other information: [optional] Other information: [optional]
| Any other information that the author deems | Any other information that the author deems
| interesting may be added here. | interesting may be added here.
Figure 1: Registration Template Figure 1: Registration Template
4.4. SIP Feature Cap Specification Requirements 4.4. Feature Cap Specification Requirements
4.4.1. General 4.4.1. General
A SIP feature cap specification MUST address the issues defined in A feature cap specification MUST address the issues defined in the
the following subsections, or document why an issue is not applicable following subsections, or document why an issue is not applicable for
for the specific SIP feature cap. A reference to the specification the specific feature cap. A reference to the specification MUST be
MUST be provided when the SIP feature cap is registered with IANA provided when the feature cap is registered with IANA (see
(see Section 4.3). Section 4.3).
It is bad practice for SIP feature cap specifications to repeat It is bad practice for feature cap specifications to repeat
procedures defined in this specification, unless needed for procedures (e.g. general procedures on the usage of the Feature-Caps
clarification or emphasis purpose. header field and feature caps) defined in this specification, unless
needed for clarification or emphasis purpose.
A SIP feature cap specification MUST NOT weaken any behavior A feature cap specification MUST NOT weaken any behavior designated
designated with "SHOULD" or "MUST" in this specification. However, a with "SHOULD" or "MUST" in this specification. However, a
specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED"
requirements to "MUST" strength if features associated with the SIP requirements to "MUST" strength if features and capabilities
feature cap require it. associated with the SIP feature cap require it.
4.4.2. Overall Description 4.4.2. Overall Description
The SIP feature cap specification MUST contain an overall description The feature cap specification MUST contain an overall description of
of the SIP feature cap: how it is used to indicate support of a the feature cap: how it is used to indicate support of a feature, a
feature, a description of the feature associated with the SIP feature description of the feature associated with the SIP feature cap, a
cap, a description of any additional information (conveyed using one description of any additional information (conveyed using one or more
or more SIP feature cap values) that can be conveyed together with feature cap values) that can be conveyed together with the feature
the SIP feature cap, and a description of how the associated feature cap, and a description of how the associated feature may be
may be exercised/invoked. exercised/invoked.
4.4.3. Feature Cap Values 4.4.3. Feature Cap Values
A SIP feature cap can have an associated value, or a list of values. A 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
6.2.2.
The SIP feature cap specification MUST define the syntax and The feature cap specification MUST define the syntax and semantics of
semantics of any value defined for the SIP feature cap, including any value defined for the feature cap, including possible
possible restrictions related to the usage of a specific value. restrictions related to the usage of a specific value. The feature
cap specification MUST define the value(s) in accordance with the
syntax defined in section 6.2.2.
A SIP feature cap value is only applicable for the SIP feature cap A feature cap value is only applicable for the feature cap for which
for which it has been defined. For other SIP feature caps, the value it has been defined. For other feature caps, the value has to be
has to be defined explicitly, even if the name or the semantics are defined explicitly, even if the semantics are identical.
identical.
It is STRONLY RECOMMENDED to not re-use a value name that already has It is STRONGLY RECOMMENDED to not re-use a value that already has
been defined for another SIP feature cap, unless the semantics of the been defined for another feature cap, unless the semantics of the
values are the same. values are the same.
4.4.4. Usage Restrictions 4.4.4. Usage Restrictions
If there are restrictions on how SIP entities can insert a SIP If there are restrictions on how SIP entities can insert a SIP
feature cap, the SIP feature cap specification MUST document such feature cap, the feature cap specification MUST document such
restrictions. restrictions.
There might be restrictions related to whether entities are allowed There might be restrictions related to whether entities are allowed
to insert a SIP feature cap in registration related messages, to insert a feature cap in registration related messages, standalone
standalone transaction messages, or dialog related messages, whether transaction messages, or dialog related messages, whether entities
entities are allowed to insert a SIP feature cap in requests or are allowed to insert a feature cap in requests or responses, whether
responses, whether entities also need to support other features in entities also need to support other features and capabilities in
order to insert a SIP feature cap, and whether entities are allowed order to insert a feature cap, and whether entities are allowed to
to indicate support of a feature in conjunction with another feature. indicate support of a feature in conjunction with another feature.
4.4.5. Examples 4.4.5. Examples
It is RECOMMENDED that the SIP feature cap specification provide It is RECOMMENDED that the feature cap specification provide
demonstrative message flow diagrams, paired with complete messages demonstrative message flow diagrams, paired with complete messages
and message descriptions. and message descriptions.
Note that example flows are by definition informative, and do not Note that example message flows are by definition informative, and do
replace normative text. not replace normative text.
5. Feature-Caps Header Field 5. Feature-Caps Header Field
5.1. Introduction 5.1. Introduction
The Feature-Caps header field is used by SIP entities to convey The Feature-Caps header field is used by SIP entities to convey
support of features and capabilities, using SIP feature caps. SIP support of features and capabilities, by setting feature caps.
feature caps conveyed in a Feature-Caps header field indicate that Feature caps conveyed in a Feature-Caps header field indicate that
the SIP entity that inserted the header field supports the associated the SIP entity that inserted the header field supports the associated
features. features and capabilities.
NOTE: It is not possible to convey the address of the SIP entity as a NOTE: It is not possible to, as a Feature-Caps header field value,
Feature-Caps header field parameter. Each feature that requires convey the address of the SIP entity that inserted the Feature-Caps
address information to be conveyed need to define a way to convey header field. If additional data about a supported feature needs to
that information as part of the associated SIP feature cap value. be conveyed, such as the address of the SIP entity that indicated
support of the feature, then the feature definition needs to define a
way to convey that information as a value of the associated feature
cap.
The SIP feature cap specification MUST specify for which SIP methods The feature cap specification MUST specify for which SIP methods and
and message types, and the associated semantics, the SIP feature cap message types, and the associated semantics, the feature cap is
is applicable. See Section 4 for more information. No semantics is applicable. See Section 4 for more information. No semantics is
defined for SIP feature caps present in SIP methods and message types defined for feature caps present in SIP methods and message types not
not covered by the associated SIP feature cap specification. covered by the associated feature cap specification.
Within a given Feature-Caps header field, SIP feature caps are listed Within a given Feature-Caps header field, feature caps are listed in
in a non-priority order, and for a given header field any order of a non-priority order, and for a given header field any order of
listed SIP feature caps have the same meaning. For example, listed SIP feature caps have the same meaning. For example,
"foo;bar" and "bar;foo" have the same meaning(i.e. that the SIP "foo;bar" and "bar;foo" have the same meaning (i.e. that the SIP
entity that inserted the feature caps supports the features entity that inserted the feature caps supports the features and
associated with the "foo" and "bar" SIP feature caps. capabilities associated with the "foo" and "bar" feature caps.
5.2. User Agent and Proxy Behavior 5.2. User Agent and Proxy Behavior
5.2.1. General 5.2.1. General
If the URI in a Contact header field of a request or response If the URI in a Contact header field of a request or response
represents a SIP entity, the entity MUST NOT indicate supported represents a SIP entity, the entity MUST NOT indicate supported
features and capabilities using a Feature-Caps header field within features and capabilities using a Feature-Caps header field within
that request or response. that request or response.
When a SIP entity receives a SIP request, or response, that contains When a SIP entity receives a SIP request, or response, that contains
one or more Feature-Caps header fields, the SIP feature caps in the one or more Feature-Caps header fields, the feature caps in the
header field inform the entity about the features supported by the header field inform the entity about the features and capabilities
entities that inserted the header fields. Procedures how features supported by the entities that inserted the header fields.
are invoked are outside the scope of this specification, and MUST be Procedures how features and capabilities are invoked are outside the
described by individual SIP feature cap specifications. scope of this specification, and MUST be described by individual
feature cap specifications.
When a SIP entity adds a Feature-Caps header field to a SIP message, When a SIP entity adds a Feature-Caps header field to a SIP message,
it MUST place the header field before any existing Feature-Caps it MUST place the header field before any existing Feature-Caps
header field in the message to be forwarded, so that the added header header field in the message to be forwarded, so that the added header
field becomes the top-most one. Then, when another SIP entity field becomes the top-most one. Then, when another SIP entity
receives a SIP request or the response, the SIP feature caps in the receives a SIP request or the response, the SIP feature caps in the
top-most Feature-Caps header field will represent the supported top-most Feature-Caps header field will represent the supported
features "closest" to the entity. features and capabilities "closest" to the entity.
5.2.2. B2BUA Behavior 5.2.2. B2BUA Behavior
The procedures in this Section applies to UAs that are part of B2BUAs The procedures in this Section applies to UAs that are part of B2BUAs
that are referenced in the message by a Record-Route header field that are referenced in the message by a Record-Route header field
rather than by the URI of the Contact header field. rather than by the URI of the Contact header field.
When a UA sends a SIP request, if the UA wants to indicate support of When a UA sends a SIP request, if the UA wants to indicate support of
features towards its downstream SIP entities, it inserts a Feature- features and capabilities towards its downstream SIP entities, it
Caps header field to the request, containing one or more SIP feature inserts a Feature-Caps header field to the request, containing one or
caps associated with the supported features, before it forwards the more feature caps associated with the supported features and
request. capabilities, before it forwards the request.
If the SIP request is triggered by another SIP request that the B2BUA If the SIP request is triggered by another SIP request that the B2BUA
has received, the UA MAY forward received Feature-Caps header fields has received, the UA MAY forward received Feature-Caps header fields
by copying them to the outgoing SIP request, similar to a SIP proxy, by copying them to the outgoing SIP request, similar to a SIP proxy,
before it inserts its own Feature-Caps header field to the SIP before it inserts its own Feature-Caps header field to the SIP
request. request.
When a UA receives a SIP response, if the UA wants to indicate When a UA receives a SIP response, if the UA wants to indicate
support of features towards its upstream SIP entities, it inserts a support of features and capabilities towards its upstream SIP
Feature-Caps header field to the response, containing one or more SIP entities, it inserts a Feature-Caps header field to the response,
feature caps associated with the supported features, before it containing one or more feature caps associated with the supported
forwards the response. features and capabilities, before it forwards the response.
If the SIP response is triggered by another SIP response that the If the SIP response is triggered by another SIP response that the
B2BUA has received, the UA MAY forward received Feature-Caps header B2BUA has received, the UA MAY forward received Feature-Caps header
field by copying them to the outgoing SIP response, similar to a SIP field by copying them to the outgoing SIP response, similar to a SIP
proxy, before it inserts its own Feature-Caps header field to the SIP proxy, before it inserts its own Feature-Caps header field to the SIP
response. response.
5.2.3. Registrar Behavior 5.2.3. Registrar Behavior
If a SIP registrar wants to indicate support of features towards its If a SIP registrar wants to indicate support of features and
upstream SIP entities, it inserts a Feature-Caps header field, capabilities towards its upstream SIP entities, it inserts a Feature-
containing one or more SIP feature caps associated with the supported Caps header field, containing one or more feature caps associated
features, to a REGISTER response. with the supported features and capabilities, to a REGISTER response.
5.2.4. Proxy behavior 5.2.4. Proxy behavior
When a SIP proxy receives a SIP request, if the proxy wants to When a SIP proxy receives a SIP request, if the proxy wants to
indicate support of features towards its downstream SIP entities, it indicate support of features and capabilities towards its downstream
inserts a Feature-Caps header field to the request, containing one or SIP entities, it inserts a Feature-Caps header field to the request,
more SIP feature caps associated with the supported features, before containing one or more SIP feature caps associated with the supported
it forwards the request. features and capabilities, before it forwards the request.
When a proxy receives a SIP response, if the proxy wants to indicate When a proxy receives a SIP response, if the proxy wants to indicate
support of features towards its upstream SIP entities, it inserts a support of features and capabilities towards its upstream SIP
Feature-Caps header field to the response, containing one or more SIP entities, it inserts a Feature-Caps header field to the response,
feature caps associated with the supported features, before it containing one or more SIP feature caps associated with the supported
forwards the response. features and capabilities, before it forwards the response.
5.3. SIP Message Type and Response Code Semantics 5.3. SIP Message Type and Response Code Semantics
5.3.1. General 5.3.1. General
This Section describes the general usage and semantics of the This Section describes the general usage and semantics of the
Feature-Caps header field for different SIP message types and Feature-Caps header field for different SIP message types and
response codes. The usage and semantics of a specific SIP feature response codes. The usage and semantics of a specific feature cap
cap MUST be described in the associated SIP feature cap MUST be described in the associated feature cap specification.
specification.
NOTE: Future specifications can define usage and semantics of the NOTE: Future specifications can define usage and semantics of the
Feature-Caps header field for SIP methods, response codes and request Feature-Caps header field for SIP methods, response codes and request
types not specified in this specification. types not specified in this specification.
The Feature-Caps header field ABNF is defined in Section 6.3.1. The Feature-Caps header field ABNF is defined in Section 6.3.1.
5.3.2. SIP Dialog 5.3.2. SIP Dialog
The Feature-Caps header field can be used within an initial SIP The Feature-Caps header field can be used within an initial SIP
request for a dialog, within a target refresh SIP request, and within request for a dialog, within a target refresh SIP request, and within
any 18x or 2xx response associated with such requests. any 18x or 2xx response associated with such requests.
If a SIP feature cap is inserted in a Feature-Caps header field of an If a feature cap is inserted in a Feature-Caps header field of an
initial request for a dialog, or within a response of such request, initial request for a dialog, or within a response of such request,
it indicates to the receivers of the request (or response) that the it indicates to the receivers of the request (or response) that the
feature associated with the SIP feature cap is supported for the feature associated with the feature cap is supported for the duration
duration of the dialog, until a target refresh request is sent for of the dialog, until a target refresh request is sent for the dialog,
the dialog, or the dialog is terminated. or the dialog is terminated.
Unless a SIP feature cap is inserted in a Feature-Caps header field Unless a feature cap is inserted in a Feature-Caps header field or a
or a target refresh request, or within a response of such request, it target refresh request, or within a response of such request, it
indicates to the receivers of the request (or response) that the indicates to the receivers of the request (or response) that the
feature is no long supported for the dialog. feature is no long supported for the dialog.
For a given dialog a SIP entity MUST insert the same SIP feature caps For a given dialog a SIP entity MUST insert the same feature caps in
in all 18x and 2xx responses associated with a given transaction. all 18x and 2xx responses associated with a given transaction.
5.3.3. SIP Registration (REGISTER) 5.3.3. SIP Registration (REGISTER)
The Feature-Caps header field can be used within a SIP REGISTER The Feature-Caps header field can be used within a SIP REGISTER
request, and within the 200 (OK) response associated with such request, and within the 200 (OK) response associated with such
request. request.
If a SIP feature cap is conveyed in a Feature-Caps header field of a If a feature cap is conveyed in a Feature-Caps header field of a
REGISTER request, or within an associated response, it indicates to REGISTER request, or within an associated response, it indicates to
the receivers of the message that the feature associated with the SIP the receivers of the message that the feature associated with the
feature cap is supported for the registration, until the registration feature cap is supported for the registration, until the registration
of the contact that was explicitly conveyed in the REGISTER request of the contact that was explicitly conveyed in the REGISTER request
expires, or until the registered contact is explicitly refreshed and expires, or until the registered contact is explicitly refreshed and
the refresh REGISTER request does not contain the SIP feature cap the refresh REGISTER request does not contain the feature cap
associated with the feature. associated with the feature.
NOTE: While a REGISTER response can contain contacts that have been NOTE: While a REGISTER response can contain contacts that have been
registered as part of other registration transactions, support of any registered as part of other registration transactions, support of any
indicated feature only applies to the contact(s) that were explicitly indicated feature only applies to the contact(s) that were explicitly
conveyed in the associated REGISTER request. conveyed in the associated REGISTER request.
This specification does not define any semantics for usage of the This specification does not define any semantics for usage of the
Feature-Caps header field in pure registration binding fetching Feature-Caps header field in pure registration binding fetching
messages (see Section 10.2.3 of RFC 3261), where the REGISTER request messages (see Section 10.2.3 of RFC 3261), where the REGISTER request
does not contain a Contact header field. Unless such semantics is does not contain a Contact header field. Unless such semantics is
defined in a future extension, fetching messages will not have any defined in a future extension, fetching messages will not have any
impact on previously indicated support of features, and SIP entities impact on previously indicated support of features and capabilities,
MUST NOT insert a Feature-Caps header field to such messages. and SIP entities MUST NOT insert a Feature-Caps header field to such
messages.
If SIP Outbound [RFC5626] is used, the rules above apply. However, If SIP Outbound [RFC5626] is used, the rules above apply. However,
supported features only apply for the registration flow on which supported features and capabilities only apply for the registration
support has been explicitly indicated. flow on which support has been explicitly indicated.
5.3.4. SIP Stand-Alone Transactions 5.3.4. SIP Stand-Alone Transactions
The Feature-Caps header field can be used within a standalone SIP The Feature-Caps header field can be used within a standalone SIP
request, and within any 18x or 2xx response associated with such request, and within any 18x or 2xx response associated with such
request. request.
If a SIP feature cap is inserted in a Feature-Caps header field of a If a feature cap is inserted in a Feature-Caps header field of a
standalone request, or within a response of such request, it standalone request, or within a response of such request, it
indicates to the receivers of the request (or response) that the indicates to the receivers of the request (or response) that the
feature associated with the SIP feature cap is supported for the feature associated with the feature cap is supported for the duration
duration of the standalone transaction. of the standalone transaction.
6. Syntax 6. Syntax
6.1. General 6.1. General
This Section defines the ABNF for Feature-Caps, and for the Feature- This Section defines the ABNF for Feature-Caps, and for the Feature-
Cap header field. Cap header field.
6.2. Syntax: SIP feature cap 6.2. Syntax: feature cap
6.2.1. General 6.2.1. General
In a SIP feature cap name (ABNF: fcap-name), dots can be used to In a feature cap name (ABNF: fcap-name), dots can be used to
implement a SIP feature cap tree hierarchy (e.g. implement a SIP feature cap tree hierarchy (e.g.
tree.feature.subfeature). The description of usage of such tree tree.feature.subfeature). The description of usage of such tree
hierarchy must be described when registered. hierarchy must be described when registered.
6.2.2. ABNF 6.2.2. ABNF
The ABNF for the SIP feature cap: The ABNF for the feature cap:
feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list
/ fcap-string-value ) RDQUOT] / fcap-string-value ) RDQUOT]
fcap-name = ftag-name fcap-name = ftag-name
fcap-value-list = tag-value-list fcap-value-list = tag-value-list
fcap-string-value = string-value fcap-string-value = string-value
;; ftag-name, tag-value-list, string-value defined in RFC3840 ;; ftag-name, tag-value-list, string-value defined in RFC 3840
NOTE: In comparison with media feature tags, the "+" sign in front NOTE: In comparison with media feature tags, the "+" sign in front
of the feature cap name is mandatory. of the feature cap name is mandatory.
Figure 2: ABNF Figure 2: ABNF
6.3. Syntax: Feature-Caps header field 6.3. Syntax: Feature-Caps header field
6.3.1. ABNF 6.3.1. ABNF
The ABNF for the Feature-Caps header fields is: The ABNF for the Feature-Caps header fields is:
Feature-Caps = "Feature-Caps" HCOLON fc-value Feature-Caps = "Feature-Caps" HCOLON fc-value
*(COMMA fc-value) *(COMMA fc-value)
fc-value = "*" *(SEMI feature-cap) fc-value = "*" *(SEMI feature-cap)
Figure 3: ABNF Figure 3: ABNF
NOTE: A "*" value means that no information regarding which SIP NOTE: A "*" value means that no information regarding which SIP
entity, or domain, that indicate support of features is provided. entity, or domain, that indicate support of features and capabilities
is provided.
7. IANA Considerations 7. IANA Considerations
7.1. Registration of the Feature-Caps header field 7.1. Registration of the Feature-Caps header field
This specification registers a new SIP header field, Feature-Caps, This specification registers a new SIP header field, Feature-Caps,
according to the process of RFC 3261 [RFC3261]. according to the process of RFC 3261 [RFC3261].
The following is the registration for the Feature-Caps header field: The following is the registration for the Feature-Caps header field:
RFC Number: RFC XXX RFC Number: RFC XXX
Header Field Name: Feature-Caps Header Field Name: Feature-Caps
7.2. Global Feature Cap Registration Tree 7.2. Global Feature Cap Registration Tree
This specification creates a new SIP feature cap tree. The name of This specification creates a new feature cap tree. The name of the
the tree is "Global Feature Cap Registration Tree", and its leading tree is "Global Feature Cap Registration Tree", and its leading facet
facet is "g.". It is used for the registration of SIP feature caps. is "g.". It is used for the registration of feature caps.
The addition of entries into this registry occurs through the Expert The addition of entries into this registry occurs through the Expert
Review policies, as defined in RFC 5226 [RFC5226]. A designated area Review policies, as defined in RFC 5226 [RFC5226]. A designated area
expert will review the proposed SIP feature cap, and consult with expert will review the proposed SIP feature cap, and consult with
members of related mailing lists. The information required in the members of related mailing lists. The information required in the
registration is defined in Section 4.3 of RFC XXX. registration is defined in Section 4.3 of RFC XXX.
Note that all SIP feature caps registered in the SIP tree will have Note that all feature caps registered in the SIP tree will have names
names with a leading facet "g.". No leading "+" is used in the with a leading facet "g.". No leading "+" is used in the
registrations in any of the media feature tag trees. registrations in any of the media feature tag trees.
7.3. SIP Feature Cap Registration Tree 7.3. Feature Cap Registration Tree
This specification creates a new SIP feature cap tree, per the This specification creates a new feature cap tree, per the guidelines
guidelines... The name of the tree is "SIP Feature Cap Registration in RFC 5226 [RFC5226]. The name of the tree is "Feature Cap
Tree", and its leading facet is "sip.". It is used for the Registration Tree", and its leading facet is "sip.". It is used for
registration of SIP feature caps. the registration of feature caps.
The addition of entries into this registry occurs through the IETF The addition of entries into this registry occurs through the IETF
Consensus, as defined in RFC 5226 [RFC5226]. This requires the Consensus, as defined in RFC 5226. This requires the publication of
publication of an RFC that contains the registration. The an RFC that contains the registration. The information required in
information required in the registration is defined in Section 4.3 of the registration is defined in Section 4.3 of RFC XXX.
RFC XXX.
Note that all SIP feature caps registered in the SIP tree will have Note that all feature caps registered in the SIP tree will have names
names with a leading facet "sip.". No leading "+" is used in the with a leading facet "sip.". No leading "+" is used in the
registrations in any of the media feature tag trees. registrations in any of the media feature tag trees.
8. Security Considerations 8. Security Considerations
SIP feature caps can provide sensitive information about a SIP Feature caps can provide sensitive information about a SIP entity.
entity. RFC 3840 cautions against providing sensitive information to RFC 3840 cautions against providing sensitive information to another
another party. Once this information is given out, any use may be party. Once this information is given out, any use may be made of
made of it. it.
9. Acknowledgements 9. Acknowledgements
10. Change Log 10. Change Log
[RFC EDITOR NOTE: Please remove this Section when publishing] [RFC EDITOR NOTE: Please remove this Section when publishing]
Changes from draft-ietf-sipcore-proxy-feature-02
o Changes based on WGLC comments from Shida Schubert.
o - Document title changed
o - Terminology alignment
o - Note text clarifications
o Changes based on WGLC comments from Lili Yang.
Changes from draft-ietf-sipcore-proxy-feature-01 Changes from draft-ietf-sipcore-proxy-feature-01
o Changes based on comments from Paul Kyzivat. o Changes based on comments from Paul Kyzivat.
o IANA Considerations text added. o IANA Considerations text added.
Changes from draft-holmberg-sipcore-proxy-feature-04/ Changes from draft-holmberg-sipcore-proxy-feature-04/
draft-ietf-sipcore-proxy-feature-00 draft-ietf-sipcore-proxy-feature-00
o Media feature tags replaced with SIP feature caps, based on o Media feature tags replaced with feature caps, based on SIPCORE
SIPCORE consensus at IETF#83 (Paris). consensus at IETF#83 (Paris).
o Editorial corrections and modifications. o Editorial corrections and modifications.
Changes from draft-holmberg-sipcore-proxy-feature-03 Changes from draft-holmberg-sipcore-proxy-feature-03
o Hadriel Kaplan added as co-author. o Hadriel Kaplan added as co-author.
o Terminology change: instead of talking of proxies, talk about o Terminology change: instead of talking of proxies, talk about
entities which are not represented by the URI in a Contact header entities which are not represented by the URI in a Contact header
field (http://www.ietf.org/mail-archive/web/sipcore/current/ field (http://www.ietf.org/mail-archive/web/sipcore/current/
msg04449.html). msg04449.html).
o Clarification regarding the usage of the header field in 18x/2xx o Clarification regarding the usage of the header field in 18x/2xx
responses (http://www.ietf.org/mail-archive/web/sipcore/current/ responses (http://www.ietf.org/mail-archive/web/sipcore/current/
skipping to change at page 17, line 14 skipping to change at page 17, line 23
11.2. Informative References 11.2. Informative References
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. 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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[3GPP.23.237] [3GPP.23.237]
3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
 End of changes. 96 change blocks. 
217 lines changed or deleted 219 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/