Indication of features supported by proxy
EricssonHirsalantie 1102420JorvasFinlandchrister.holmberg@ericsson.comEricssonScheelevägen 19C22363LundSwedenivo.sedlacek@ericsson.comAcme Packet71 Third Ave.BurlingtonMA01803USAhkaplan@acmepacket.com
Transport
SIPCORE Working GroupSIPproxyfeaturefeature-tagcapabiltiy
This document defines a new SIP header field, 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.
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, using the Contact
header field.
This document defines a new SIP header field, 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. Such cases are:
- The SIP entity acts as a SIP proxy.
- The SIP entity acts as a SIP registrar.
- The SIP entity acts as a B2BUA, where the
Contact header field URI represents another SIP entity.
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 .
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.
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 Tags 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 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.
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 Tags 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 Tags 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.
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.
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,
within a target refresh SIP request, and within any 18x or 2xx response associated
with such requests.
If a Feature Tag is inserted in a Feature-Caps header field of such request or such
response, the feature associated with the Feature Tag MUST be supported for the dialog,
until the next time the dialog target is refreshed, or the dialog is terminated.
For a given dialog the entity MUST use the same Feature-Caps header field value
(if included) in all 18x and 2xx responses for the same transaction.
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 18x or 2xx response 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 duration of the
standalone transaction.
TBD
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 (";").
NOTE: 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.
The ABNF for the Feature-Caps header fields is:
Feature tags inserted in a Feature-Caps header field indicate that the
SIP entity that inserted the header field supports 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 the Feature-Caps 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, Feature Tags are listed in a non-priority
order, and for a given header field any order of listed Feature Tags 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 supports the features
associated with the "foo" and "bar" Feature Tags.
This section provides guidance on how to define an Feature Tag, and
what information needs to exist in an Feature Tag specification.
It is bad practice for Feature Tag specifications to repeat procedures
defined in this document, unless needed for clarification or emphasis
purpose.
Feature Tag specifications MUST NOT weaken any behavior designated
with "SHOULD" or "MUST" in this specification. However, Feature Tags
specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED"
requirements to "MUST" strength if features associated with the Feature
Tag require it.
Feature Tag specifications MUST address the issues defined in the
following subsections, or document why an issue is not applicable for
the specific Feature Tag.
The Feature Tag specification MUST contain an overall description of
the Feature Tag: a description of the feature associated with the
Feature Tag, and a description what information is carried in associated
Feature Tag values (if any).
The Feature Tag specification MUST describe why the support of the
feature can not be indicated in a SIP Contact header field , using the mechanism defined in RFC 3840. The reason
is either that the entity inserting the Feature Tag is acting as
a SIP proxy, or SIP registrar, or a B2BUA but is not represented by
the URI in the Contact header field.
The Feature Tag specification MUST define an Feature Tag name,
which entities use as a header field value to identify the Feature
Tag in the Feature-Caps header field. The Feature Tag name MUST
conform to the ABNF defined in .
The Feature Tag specification MAY define Feature Tag values,
associated with the Feature Tag. A Feature Tag value MUST
conform to the ABNF defined in .
The Feature Tag specification MUST define the syntax and semantics
of the values associated with the Feature Tag. In addition, the
specification MUST define whether there are restrictions regarding
the usage of specific values.
Feature Tags can share value defined for other Feature Tags,
but the value is Feature Tag specific, and the value semantics MUST
be defined for each Feature Tag tag uses the value.
The Feature Tag specification MAY define SIP option tags, which can
be used as describe in RFC 3261.
The registration requirements for option tags are defined in RFC 5727
.
If there are restrictions on how entities can insert a Feature
Tag, the Feature Tag specification MUST document such restrictions.
There can be restrictions related to whether entities are allowed
to insert Feature Tags in registration related messages, standalone
transaction messages, or dialog related messages, whether entities
are allowed to insert Feature Tags in requests or responses, whether
entities also need to support other features in order to insert a
Feature Tag, and whether entities are allowed to insert Feature
Tags togheter with other Feature Tags.
If the information carried in a Feature Tag requires a certain
level of security, the Feature Tag specification MUST describe
the mechanisms that entities need to use in order to provide the
required security.
If the Feature Tag specification does not require any additional
security, other than what the underlying SIP protocol provides, this
MUST be stated in the Feature Tag specification.
It is strongly RECOMMENDED that the Feature Tag specification defines
the procedure regarding how implementors shall implement and use the
Feature Tag, or refer to other locations where implementors can find
that information.
NOTE: Sometimes an Feature Tag designer might choose to not
reveal the details of an Feature Tag. However, in order to allow
multiple implementations to support the Feature Tag, Feature Tag
designers are strongly encouraged to provide the implementation
details.
It is RECOMMENDED that the Feature Tag 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.
This specification registers a new SIP header field, Feature-Caps, according
to the process of RFC 3261 .
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.
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-sipcore-proxy-feature-03
Hadriel Kaplan added as co-author.
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).
Clarification regarding the usage of the header field in 18x/2xx responses
(http://www.ietf.org/mail-archive/web/sipcore/current/msg04449.html).
Specifying that feature support can also be indicated in target
refresh requests
(http://www.ietf.org/mail-archive/web/sipcore/current/msg04454.html).
Feature Tag specification registration information added.
Changes from draft-holmberg-sipcore-proxy-feature-02
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
Requirement section addedUse-cases and examples updated based on work in 3GPP
Changes from draft-holmberg-sipcore-proxy-feature-00
Additional use-cases addedDirection section added