From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3840.txt | 2019 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2019 insertions(+) create mode 100644 doc/rfc/rfc3840.txt (limited to 'doc/rfc/rfc3840.txt') diff --git a/doc/rfc/rfc3840.txt b/doc/rfc/rfc3840.txt new file mode 100644 index 0000000..f7b42b5 --- /dev/null +++ b/doc/rfc/rfc3840.txt @@ -0,0 +1,2019 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 3840 dynamicsoft +Category: Standards Track H. Schulzrinne + Columbia University + P. Kyzivat + Cisco Systems + August 2004 + + + Indicating User Agent Capabilities in + the Session Initiation Protocol (SIP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This specification defines mechanisms by which a Session Initiation + Protocol (SIP) user agent can convey its capabilities and + characteristics to other user agents and to the registrar for its + domain. This information is conveyed as parameters of the Contact + header field. + + + + + + + + + + + + + + + + + + + + +Rosenberg, et al. Standards Track [Page 1] + +RFC 3840 SIP Capabilities August 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Usage of the Content Negotiation Framework . . . . . . . . . . 6 + 5. Computing Capabilities . . . . . . . . . . . . . . . . . . . . 7 + 6. Expressing Capabilities in a Registration . . . . . . . . . . 10 + 7. Indicating Feature Sets in Remote Target URIs . . . . . . . . 12 + 8. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . . 13 + 9. Contact Header Field . . . . . . . . . . . . . . . . . . . . . 13 + 10. Media Feature Tag Definitions . . . . . . . . . . . . . . . . 14 + 10.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.2. Application . . . . . . . . . . . . . . . . . . . . . . 16 + 10.3. Data. . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.4. Control . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.5. Video . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.6. Text. . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.7. Automata. . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.8. Class . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10.9. Duplex. . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.10. Mobility. . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.11. Description . . . . . . . . . . . . . . . . . . . . . . 21 + 10.12. Event Packages. . . . . . . . . . . . . . . . . . . . . 22 + 10.13. Priority. . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.14. Methods . . . . . . . . . . . . . . . . . . . . . . . . 23 + 10.15. Extensions. . . . . . . . . . . . . . . . . . . . . . . 24 + 10.16. Schemes . . . . . . . . . . . . . . . . . . . . . . . . 24 + 10.17. Actor . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 10.18. Is Focus. . . . . . . . . . . . . . . . . . . . . . . . 26 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 11.1. Considerations for Media Feature Tags . . . . . . . . . 26 + 11.2. Considerations for Registrations. . . . . . . . . . . . 27 + 11.3. Considerations for OPTIONS Responses. . . . . . . . . . 28 + 11.4. Considerations for Dialog Initiating Messages . . . . . 28 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 12.1. SIP Media Feature Tag Registration Tree . . . . . . . . 28 + 12.2. Media Feature Tags. . . . . . . . . . . . . . . . . . . 29 + 12.3. SIP Option Tag. . . . . . . . . . . . . . . . . . . . . 30 + 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 14.1. Normative References. . . . . . . . . . . . . . . . . . 31 + 14.2. Informative References. . . . . . . . . . . . . . . . . 31 + Appendix. Overview of RFC 2533. . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36 + + + + + +Rosenberg, et al. Standards Track [Page 2] + +RFC 3840 SIP Capabilities August 2004 + + +1. Introduction + + Session Initiation Protocol (SIP) [1] user agents vary widely in + their capabilities and in the types of devices they represent. + Frequently, it is important for another SIP element to learn the + capabilities and characteristics of a SIP UA. Some of the + applications of this information include: + + o One user agent, a PC-based application, is communicating with + another that is embedded in a limited-function device. The PC + would like to be able to "grey out" those components of the user + interface that represent features or capabilities not supported by + its peer. To do that, there needs to be a way to exchange + capability information within a dialog. + + o A user has two devices at their disposal. One is a videophone, + and the other, a voice-only wireless phone. A caller wants to + interact with the user using video. As such, they would like + their call preferentially routed to the device which supports + video. To do this, the INVITE request can contain parameters that + express a preference for routing to a device with the specified + capabilities [11]. + + o A network application would like to asynchronously send + information to a user agent in a MESSAGE [16] request. However, + before sending it, they would like to know if the UA has the + capabilities necessary to receive the message. To do that, they + would ideally query a user database managed by the domain which + holds such information. Population of such a database would + require that a UA convey its capabilities as part of its + registration. Thus, there is a need for conveying capabilities in + REGISTER requests. + + SIP has some support for expression of capabilities. The Allow, + Accept, Accept-Language, and Supported header fields convey some + information about the capabilities of a user agent. However, these + header fields convey only a small part of the information that is + needed. They do not provide a general framework for expression of + capabilities. Furthermore, they only specify capabilities + indirectly; the header fields really indicate the capabilities of the + UA as they apply to this request. SIP also has no ability to convey + characteristics, that is, information that describes a UA. + + As a result, this specification provides a more general framework for + an indication of capabilities and characteristics in SIP. Capability + and characteristic information about a UA is carried as parameters of + + + + + +Rosenberg, et al. Standards Track [Page 3] + +RFC 3840 SIP Capabilities August 2004 + + + the Contact header field. These parameters can be used within + REGISTER requests and responses, OPTIONS responses, and requests and + responses that create dialogs (such as INVITE). + +2. Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 + [2] and indicate requirement levels for compliant implementations. + +3. Definitions + + Feature: As defined in RFC 2703 [17], a piece of information about + the media handling properties of a message passing system + component or of a data resource. For example, the SIP methods + supported by a UA represent a feature. + + Feature Tag: As defined in RFC 2703 [17], a feature tag is a name + that identifies a feature. An example is "sip.methods". + + Media Feature: As defined in RFC 2703, [17], a media feature is + information that indicates facilities assumed to be available for + the message content to be properly rendered or otherwise + presented. Media features are not intended to include information + that affects message transmission. + + In the context of this specification, a media feature is + information that indicates facilities for handling SIP requests, + rather than specifically for content. In that sense, it is used + synonymously with feature. + + Feature Collection: As defined in RFC 2533 [4], a feature collection + is a collection of different media features and associated values. + This might be viewed as describing a specific rendering of a + specific instance of a document or resource by a specific + recipient. + + Feature Set: As defined in RFC 2703 [17], a feature set is + information about a sender, recipient, or other participant in a + message transfer which describes the set of features that it can + handle. Where a 'feature' describes a single identified attribute + of a resource, a 'feature set' describes a full set of possible + attributes. + + + + + + + +Rosenberg, et al. Standards Track [Page 4] + +RFC 3840 SIP Capabilities August 2004 + + + Feature Parameters: A set of SIP header field parameters that can + appear in the Contact header field. The feature parameters + represent an encoding of a feature set. Each set of feature + parameters maps to a feature set predicate. + + Capability: As defined in RFC 2703 [17], a capability is an attribute + of a sender or receiver (often the receiver) which indicates an + ability to generate or process a particular type of message + content. A capability is distinct from a characteristic in that a + capability may or may not be utilized in any particular call, + whereas a characteristic is a non-negotiable property of a UA. + SIP itself will often negotiate whether or not capabilities are + used in a call. + + Characteristic: A characteristic is like a capability, but describes + an aspect of a UA which is not negotiable. As an example, whether + or not a UA is a mobile phone is a characteristic, not a + capability. The semantics of this specification do not + differentiate between capability and characteristic, but the + distinction is useful for illustrative purposes. Indeed, in the + text below, when we say "capability", it refers to both + capabilities and characteristics, unless the text explicitly says + otherwise. + + Filter: A single expression in a feature set predicate. + + Simple Filter: An expression in a feature set predicate which is a + comparison (equality or inequality) of a feature tag against a + feature value. + + Disjunction: A boolean OR operation across some number of terms. + + Conjunction: A boolean AND operation across some number of terms. + + Predicate: A boolean expression. + + Feature Set Predicate: From RFC 2533 [4], a feature set predicate is + a function of an arbitrary feature collection value which returns + a Boolean result. A TRUE result is taken to mean that the + corresponding feature collection belongs to some set of media + feature handling capabilities defined by this predicate. + + Contact Predicate: The feature set predicate associated with a URI + registered in the Contact header field of a REGISTER request. The + contact predicate is derived from the feature parameters in the + Contact header field. + + + + + +Rosenberg, et al. Standards Track [Page 5] + +RFC 3840 SIP Capabilities August 2004 + + +4. Usage of the Content Negotiation Framework + + This specification makes heavy use of the terminology and concepts in + the content negotiation work carried out within the IETF, and + documented in several RFCs. The ones relevant to this specification + are RFC 2506 [3], which provides a template for registering media + feature tags, RFC 2533 [4], which presents a syntax and matching + algorithm for media feature sets, RFC 2738 [5], which provides a + minor update to RFC 2533, and RFC 2703 [17], which provides a general + framework for content negotiation. + + In case the reader does not have the time to read those + specifications, Appendix A provides a brief overview of the concepts + and terminology in those documents that is critical for understanding + this specification. + + Since the content negotiation work was primarily meant to apply to + documents or other resources with a set of possible renderings, it is + not immediately apparent how it is used to model SIP user agents. A + feature set is composed of a set of feature collections, each of + which represents a specific rendering supported by the entity + described by the feature set. In the context of a SIP user agent, a + feature collection represents an instantaneous modality. That is, if + you look at the run time processing of a SIP UA and take a snapshot + in time, the feature collection describes what it is doing at that + very instant. + + This model is important, since it provides guidance on how to + determine whether something is a value for a particular feature tag, + or a feature tag by itself. If two properties can be exhibited by a + UA simultaneously so that both are present in an instantaneous + modality, they need to be represented by separate media feature tags. + For example, a UA may be able to support some number of media types - + audio, video, and control. Should each of these be different values + for a single "media-types" feature tag, or should each of them be a + separate boolean feature tag? The model provides the answer. Since, + at any instance in time, a UA could be handling both audio and video, + they need to be separate media feature tags. However, the SIP + methods supported by a UA can each be represented as different values + for the same media feature tag (the "sip.methods" tag), because + fundamentally, a UA processes a single request at a time. It may be + multi-threading, so that it appears that this is not so, but at a + purely functional level, it is true. + + Clearly, there are weaknesses in this model, but it serves as a + useful guideline for applying the concepts of RFC 2533 to the problem + at hand. + + + + +Rosenberg, et al. Standards Track [Page 6] + +RFC 3840 SIP Capabilities August 2004 + + +5. Computing Capabilities + + To construct a set of Contact header field parameters that indicate + capabilities, a UA constructs a feature predicate for that contact. + This process is described in terms of RFC 2533 [4] (and its minor + update, RFC 2738 [5]) syntax and constructs, followed by a conversion + to the syntax used in this specification. However, this represents a + logical flow of processing. There is no requirement that an + implementation actually use RFC 2533 syntax as an intermediate step. + + A UA MAY use any feature tags that are registered through IANA in the + SIP tree (Established in Section 12.1), IETF, or global trees [3]; + this document registers several into the SIP tree. The feature tags + discussed in this specification are referred to as base tags. While + other tags can be used, in order to identify them as feature + parameters (as opposed to parameters for another SIP extension), they + are encoded with a leading "+" sign in the Contact header field. It + is also permissible to use the URI tree [3] for expressing vendor- + specific feature tags. Feature tags in any other trees created + through IANA MAY also be used. + + When using the "sip.methods" feature tag, a UA MUST NOT include + values that correspond to methods not standardized in IETF standards + track RFCs. When using the "sip.events" feature tag, a UA MUST NOT + include values that correspond to event packages not standardized in + IETF standards track RFCs. When using the "sip.schemes" feature tag, + a UA MUST NOT include values that correspond to schemes not + standardized in IETF standards track RFCs. When using the + "sip.extensions" feature tag, a UA MUST NOT include values that + correspond to option tags not standardized in IETF standards track + RFCs. + + Note that the "sip.schemes" feature tag does not indicate the scheme + of the registered URI. Rather, it indicates schemes that a UA is + capable of sending requests to, should such a URI be received in a + web page or Contact header field of a redirect response. + + It is RECOMMENDED that a UA provide complete information in its + contact predicate. That is, it SHOULD provide information on as many + feature tags as possible. The mechanisms in this specification work + best when user agents register complete feature sets. Furthermore, + when a UA registers values for a particular feature tag, it MUST list + all values that it supports. For example, when including the + "sip.methods" feature tag, a UA MUST list all methods it supports. + + The contact predicate constructed by a UA MUST be an AND of terms + (called a conjunction). Each term is either an OR (called a + disjunction) of simple filters or negations of simple filters, or a + + + +Rosenberg, et al. Standards Track [Page 7] + +RFC 3840 SIP Capabilities August 2004 + + + single simple filter or negation of a single filter. In the case of + a disjunction, each filter in the disjunction MUST indicate feature + values for the same feature tag (i.e., the disjunction represents a + set of values for a particular feature tag), while each element of + the conjunction MUST be for a different feature tag. Each simple + filter can be an equality, or in the case of numeric feature tags, an + inequality or range. If a string (as defined in RFC 2533 [4]) is + used as the value of a simple filter, that value MUST NOT include the + "<" or ">" characters, the simple filter MUST NOT be negated, and it + MUST be the only simple filter for that particular feature tag. This + contact predicate is then converted to a list of feature parameters, + following the procedure outlined below. + + The contact predicate is a conjunction of terms. Each term indicates + constraints on a single feature tag, and each term is represented by + a separate feature parameter that will be present in the Contact + header field. The syntax of this parameter depends on the feature + tag. Each forward slash in the feature tag is converted to a single + quote, and each colon are converted to an exclamation point. For the + base tags - that is, those feature tags documented in this + specification (sip.audio, sip.automata, sip.class, sip.duplex, + sip.data, sip.control, sip.mobility, sip.description, sip.events, + sip.priority, sip.methods, sip.extensions, sip.schemes, + sip.application, sip.video, language, type, sip.isfocus, sip.actor + and sip.text), the leading "sip.", if present, is stripped. For + feature tags not in this list, the leading "sip." MUST NOT be + stripped if present, and indeed, a plus sign ("+") MUST be added as + the first character of the Contact header field parameter. The + result is the feature parameter name. As a result of these rules, + the base tags appear "naked" in the Contact header field - they have + neither a "+" nor a "sip." prefix. All other tags will always have a + leading "+" when present in the Contact header field, and will + additionally have a "sip." if the tag is in the SIP tree. + + The value of the feature parameter depends on the term of the + conjunction. If the term is a boolean expression with a value of + true, i.e., (sip.audio=TRUE), the contact parameter has no value. If + the term of the conjunction is a disjunction, the value of the + contact parameter is a quoted string. The quoted string is a comma + separated list of strings, each one derived from one of the terms in + the disjunction. If the term of the conjunction is a negation, the + value of the contact parameter is a quoted string. The quoted string + begins with an exclamation point (!), and the remainder is + constructed from the expression being negated. + + The remaining operation is to compute a string from a primitive + filter. If the filter is a simple filter that is performing a numeric + comparison, the string starts with an octothorpe (#), followed by the + + + +Rosenberg, et al. Standards Track [Page 8] + +RFC 3840 SIP Capabilities August 2004 + + + comparator in the filter (=, >=, or <=), followed by the value from + the filter. If the value from the filter is expressed in rational + form (X / Y), then X and Y are divided, yielding a decimal number, + and this decimal number is output to the string. + + RFC 2533 uses a fractional notation to describe rational numbers. + This specification uses a decimal form. The above text merely + converts between the two representations. Practically speaking, + this conversion is not needed since the numbers are the same in + either case. However, it is described in case implementations + wish to directly plug the predicates generated by the rules in + this section into an RFC 2533 implementation. + + If the filter is a range (foo=X..Y), the string is equal to X:Y, + where X and Y have been converted from fractional numbers (A / B) to + their decimal equivalent. + + If the filter is an equality over a token or boolean, then that token + or boolean value ("TRUE" or "FALSE") is output to the string. + + If the filter is an equality over a quoted string, the output is a + less than (<), followed by the quoted string, followed by a greater + than (>). + + As an example, this feature predicate: + + (& (sip.mobility=fixed) + (| (! (sip.events=presence)) (sip.events=message-summary)) + (| (language=en) (language=de)) + (sip.description="PC") + (sip.newparam=TRUE) + (rangeparam=-4..5125/1000)) + + would be converted into the following feature parameters: + + mobility="fixed";events="!presence,message-summary";language="en,de" + ;description="";+sip.newparam;+rangeparam="#-4:+5.125" + + These feature tags would then appear as part of the Contact header + field: + + Contact: + ;mobility="fixed";events="!presence,message-summary" + ;language="en,de";description="" + ;+sip.newparam;+rangeparam="#-4:+5.125" + + Notice how the leading "sip." was stripped from the sip.mobility, + sip.events and sip.description feature tags before encoding them in + + + +Rosenberg, et al. Standards Track [Page 9] + +RFC 3840 SIP Capabilities August 2004 + + + the Contact header field. This is because these feature tags are + amongst the base tags listed above. It is for this reason that these + feature tags were not encoded with a leading "+" either. However, + the sip.newparam feature tag was encoded with both the "+" and its + leading "sip.", and the rangeparam was also encoded with a leading + "+". This is because neither of these feature tags are defined in + this specification. As such, the leading "sip." is not stripped off, + and a "+" is added. + +6. Expressing Capabilities in a Registration + + When a UA registers, it can choose to indicate a feature set + associated with a registered contact. Whether or not a UA does so + depends on what the registered URI represents. If the registered URI + represents a UA instance (the common case in registrations), a UA + compliant to this specification SHOULD indicate a feature set using + the mechanisms described here. If, however, the registered URI + represents an address-of-record, or some other resource that is not + representable by a single feature set, it SHOULD NOT include a + feature set. As an example, if a user wishes to forward calls from + sip:user1@example.com to sip:user2@example.org, it could generate a + registration that looks like, in part: + + REGISTER sip:example.com SIP/2.0 + To: sip:user1@example.com + Contact: sip:user2@example.org + + In this case, the registered contact is not identifying a UA, but + rather, another address-of-record. In such a case, the registered + contact would not indicate a feature set. + + However, in some cases, a UA may wish to express feature parameters + for an address-of-record. One example is an AOR which represents a + multiplicity of devices in a home network, and routes to a proxy + server in the user's home. Since all devices in the home are for + personal use, the AOR itself can be described with the + ;class="personal" feature parameter. A registration that forwards + calls to this home AOR could make use of that feature parameter. + Generally speaking, a feature parameter can only be associated with + an address-of-record if all devices bound to that address-of-record + share the exact same set of values for that feature parameter. + + Similarly, in some cases, a UA can exhibit one characteristic or + another, but the characteristic is not known in advance. For + example, a UA could represent a device that is a phone with an + embedded answering machine. The ideal way to treat such devices is + to model them as if they were actually a proxy fronting two devices - + a phone (which is never an answering machine), and an answering + + + +Rosenberg, et al. Standards Track [Page 10] + +RFC 3840 SIP Capabilities August 2004 + + + machine (which is never a phone). The registration from this device + would be constructed as if it were an AOR, as per the procedures + above. Generally, this means that, unless the characteristic is + identical between the logical devices, that characteristic will not + be present in any registration generated by the actual device. + + The remainder of this section assumes that a UA would like to + associate a feature set with a contact that it is registering. This + feature set is constructed and converted to a series of Contact + header field parameters, as described in Section 5, and those feature + parameters are added to the Contact header field value containing the + URI to which the parameters apply. The Allow, Accept, Accept- + Language and Allow-Events [9] header fields are allowed in REGISTER + requests, and also indicate capabilities. However, their semantic in + REGISTER is different, indicating capabilities, used by the + registrar, for generation of the response. As such, they are not a + substitute or an alternate for the Contact feature parameters, which + indicate the capabilities of the UA generally speaking. + + The REGISTER request MAY contain a Require header field with the + value "pref" if the client wants to be sure that the registrar + understands the extensions defined in this specification. This means + that the registrar will store the feature parameters, and make them + available to elements accessing the location service within the + domain. In the absence of the Require header field, a registrar that + does not understand this extension will simply ignore the Contact + header field parameters. + + If a UA registers against multiple separate addresses-of-record, and + the contacts registered for each have different capabilities, a UA + MUST use different URIs in each registration. This allows the UA to + uniquely determine the feature set that is associated with the + request URI of an incoming request. + + As an example, a voicemail server that is a UA that supports audio + and video media types and is not mobile would construct a feature + predicate like this: + + (& (sip.audio=TRUE) + (sip.video=TRUE) + (sip.actor=msg-taker) + (sip.automata=TRUE) + (sip.mobility=fixed) + (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) + (sip.methods=ACK) (sip.methods=CANCEL))) + + + + + + +Rosenberg, et al. Standards Track [Page 11] + +RFC 3840 SIP Capabilities August 2004 + + + These would be converted into feature parameters and included in the + REGISTER request: + + REGISTER sip:example.com SIP/2.0 + From: sip:user@example.com;tag=asd98 + To: sip:user@example.com + Call-ID: hh89as0d-asd88jkk@host.example.com + CSeq: 9987 REGISTER + Max-Forwards: 70 + Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 + Contact: ;audio;video + ;actor="msg-taker";automata;mobility="fixed" + ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" + Content-Length: 0 + + Note that a voicemail server is usually an automata and a message + taker. + + When a UAC refreshes its registration, it MUST include its feature + parameters in that refresh if it wishes for them to remain active. + Furthermore, when a registrar returns a 200 OK response to a REGISTER + request, each Contact header field value MUST include all of the + feature parameters associated with that URI. + +7. Indicating Feature Sets in Remote Target URIs + + Target refresh requests and responses are used to establish and + modify the remote target URI in a dialog. The remote target URI is + conveyed in the Contact header field. A UAC or UAS MAY add feature + parameters to the Contact header field value in target refresh + requests and responses for the purpose of indicating the capabilities + of the UA. To do that, it constructs a set of feature parameters + according to Section 5. These are then added as Contact header field + parameters in the request or response. + + The feature parameters can be included in both initial requests and + mid-dialog requests, and MAY change mid-dialog to signal a change in + UA capabilities. + + There is overlap in the callee capabilities mechanism with the Allow, + Accept, Accept-Language, and Allow-Events [9] header fields, which + can also be used in target refresh requests. Specifically, the Allow + header field and "sip.methods" feature tag indicate the same + information. The Accept header field and the "type" feature tag + indicate the same information. The Accept-Language header field and + the "language" feature tag indicate the same information. The + Allow-Events header field and the "sip.events" feature tag indicate + the same information. It is possible that other header fields and + + + +Rosenberg, et al. Standards Track [Page 12] + +RFC 3840 SIP Capabilities August 2004 + + + feature tags defined in the future may also overlap. When there + exists a feature tag that describes a capability that can also be + represented with a SIP header field, a UA MUST use the header field + to describe the capability. A UA receiving a message that contains + both the header field and the feature tag MUST use the header field, + and not the feature tag. + +8. OPTIONS Processing + + When a UAS compliant to this specification receives an OPTIONS + request, it MAY add feature parameters to the Contact header field in + the OPTIONS response for the purpose of indicating the capabilities + of the UA. To do that, it constructs a set of feature parameters + according to Section 5. These are then added as Contact header field + parameters in OPTIONS response. Indeed, if feature parameters were + included in the registration generated by that UA, those same + parameters SHOULD be used in the OPTIONS response. + + The guidelines in Section 7 regarding the overlap of the various + callee capabilities feature tags with SIP header fields applies to + the generation of OPTIONS responses as well. In particular, they + apply when a Contact header field is describing the UA which + generated the OPTIONS response. When a Contact header field in the + OPTIONS response is identifying a different UA, there is no overlap. + +9. Contact Header Field + + This specification extends the Contact header field. In particular, + it allows for the Contact header field parameters to include + feature-param. Feature-param is a feature parameter that describes a + feature of the UA associated with the URI in the Contact header + field. Feature parameters are identifiable because they either + belong to the well known set of base feature tags, or they begin with + a plus sign. + + feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list + / string-value ) RDQUOT] + enc-feature-tag = base-tags / other-tags + base-tags = "audio" / "automata" / + "class" / "duplex" / "data" / + "control" / "mobility" / "description" / + "events" / "priority" / "methods" / + "schemes" / "application" / "video" / + "language" / "type" / "isfocus" / + "actor" / "text" / "extensions" + other-tags = "+" ftag-name + ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / + "." / "-" / "%" ) + + + +Rosenberg, et al. Standards Track [Page 13] + +RFC 3840 SIP Capabilities August 2004 + + + tag-value-list = tag-value *("," tag-value) + tag-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 + + Note that the tag-value-list uses an actual comma instead of the + COMMA construction because it appears within a quoted string, where + line folding cannot take place. + + The production for qdtext can be found in RFC 3261 [1]. + + There are additional constraints on the usage of feature-param that + cannot be represented in a BNF. There MUST only be one instance of + any feature tag in feature-param. Any numbers present in a feature + parameter MUST be representable using an ANSI C double. + + The following production updates the one in RFC 3261 [1] for + contact-params: + + contact-params = c-p-q / c-p-expires / feature-param + / contact-extension + +10. Media Feature Tag Definitions + + This specification defines an initial set of media feature tags for + use with this specification. This section serves as the IANA + registration for these feature tags, which are made into the SIP + media feature tag tree. New media feature tags are registered in the + IETF or global trees based on the process defined for feature tag + registrations [3], or in the SIP tree based on the process defined in + Section 12.1. + + Any registered feature tags MAY be used with this specification. + However, several existing ones appear to be particularly applicable. + These include the language feature tag [6], which can be used to + specify the language of the human or automata represented by the UA, + and the type feature tag [7], which can be used to specify the MIME + types that a SIP UA can receive in a SIP message. The audio, video, + application, data, and control feature tags in the SIP tree (each of + which indicate a media type, as defined in RFC 2327 [8]) are + different. They do not indicate top level MIME types which can be + + + +Rosenberg, et al. Standards Track [Page 14] + +RFC 3840 SIP Capabilities August 2004 + + + received in SIP requests. Rather, they indicate media types that can + be used in media streams, and as a result, match up with the types + defined in RFC 2327 [8]. + + If a new SDP media type were to be defined, such as "message", a new + feature tag registration SHOULD be created for it in the SIP tree. + The name of the feature tag MUST equal "sip." concatenated with the + name of the media type, unless there is an unlikely naming collision + between the new media type and an existing feature tag registration. + As a result, implementations can safely construct caller preferences + and callee capabilities for the new media type before it is + registered, as long as there is no naming conflict. + + If a new media feature tag is registered with the intent of using + that tag with this specification, the registration is done for the + unencoded form of the tag (see Section 5). In other words, if a new + feature tag "foo" is registered in the IETF tree, the IANA + registration would be for the tag "foo" and not "+foo". Similarly, + if a new feature tag "sip.gruu" is registered in the SIP tree, the + IANA registration would be for the tag "sip.gruu" and not "+sip.gruu" + or "gruu". As such, all registrations into the SIP tree will have + the "sip." prefix. + + The feature tags in this section are all registered in the SIP media + feature tag tree created by Section 12.1. + +10.1. Audio + + Media feature tag name: sip.audio + + ASN.1 Identifier: 1.3.6.1.8.4.1 + + Summary of the media feature indicated by this tag: This feature tag + indicates that the device supports audio as a streaming media + type. + + Values appropriate for use with this feature tag: Boolean. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Routing a call to a phone that can support + audio. + + Related standards or documents: RFC 3840 + + + + +Rosenberg, et al. Standards Track [Page 15] + +RFC 3840 SIP Capabilities August 2004 + + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.2. Application + + Media feature tag name: sip.application + + ASN.1 Identifier: 1.3.6.1.8.4.2 + + Summary of the media feature indicated by this tag: This feature tag + indicates that the device supports application as a streaming + media type. This feature tag exists primarily for completeness. + Since so many MIME types are underneath application, indicating + the ability to support applications provides little useful + information. + + Values appropriate for use with this feature tag: Boolean. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application, for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Routing a call to a phone that can support a + media control application. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.3. Data + + Media feature tag name: sip.data + + ASN.1 Identifier: 1.3.6.1.8.4.3 + + Summary of the media feature indicated by this tag: This feature tag + indicates that the device supports data as a streaming media type. + + Values appropriate for use with this feature tag: Boolean. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + + + + +Rosenberg, et al. Standards Track [Page 16] + +RFC 3840 SIP Capabilities August 2004 + + + Examples of typical use: Routing a call to a phone that can support + a data streaming application. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.4. Control + + Media feature tag name: sip.control + + ASN.1 Identifier: 1.3.6.1.8.4.4 + + Summary of the media feature indicated by this tag: This feature tag + indicates that the device supports control as a streaming media + type. + + Values appropriate for use with this feature tag: Boolean. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Routing a call to a phone that can support + a floor control application. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.5. Video + + Media feature tag name: sip.video + + ASN.1 Identifier: 1.3.6.1.8.4.5 + + Summary of the media feature indicated by this tag: This feature tag + indicates that the device supports video as a streaming media + type. + + Values appropriate for use with this feature tag: Boolean. + + + + + + + +Rosenberg, et al. Standards Track [Page 17] + +RFC 3840 SIP Capabilities August 2004 + + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Routing a call to a phone that can support + video. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.6. Text + + Media feature tag name: sip.text + + ASN.1 Identifier: 1.3.6.1.8.4.6 + + Summary of the media feature indicated by this tag: This feature tag + indicates that the device supports text as a streaming media type. + + Values appropriate for use with this feature tag: Boolean. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Routing a call to a phone that can support + text. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.7. Automata + + Media feature tag name: sip.automata + + ASN.1 Identifier: 1.3.6.1.8.4.7 + + Summary of the media feature indicated by this tag: The sip.automata + feature tag is a boolean value that indicates whether the UA + represents an automata (such as a voicemail server, conference + server, IVR, or recording device) or a human. + + + + +Rosenberg, et al. Standards Track [Page 18] + +RFC 3840 SIP Capabilities August 2004 + + + Values appropriate for use with this feature tag: Boolean. TRUE + indicates that the UA represents an automata. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Refusing to communicate with an automata + when it is known that automated services are unacceptable. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.8. Class + + Media feature tag name: sip.class + + ASN.1 Identifier: 1.3.6.1.8.4.8 + + Summary of the media feature indicated by this tag: This feature tag + indicates the setting, business or personal, in which a + communications device is used. + + Values appropriate for use with this feature tag: Token with an + equality relationship. Typical values include: + + business: The device is used for business communications. + + personal: The device is used for personal communications. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application, for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Choosing between a business phone and a home + phone. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + + + + + + +Rosenberg, et al. Standards Track [Page 19] + +RFC 3840 SIP Capabilities August 2004 + + +10.9. Duplex + + Media feature tag name: sip.duplex + + ASN.1 Identifier: 1.3.6.1.8.4.9 + + Summary of the media feature indicated by this tag: The sip.duplex + media feature tag indicates whether a communications device can + simultaneously send and receive media ("full"), alternate between + sending and receiving ("half"), can only receive ("receive-only") + or only send ("send-only"). + + Values appropriate for use with this feature tag: Token with an + equality relationship. Typical values include: + + full: The device can simultaneously send and receive media. + + half: The device can alternate between sending and receiving + media. + + receive-only: The device can only receive media. + + send-only: The device can only send media. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: + This feature tag is most useful in a communications application + for describing the capabilities of a device, such as a phone or + PDA. + + Examples of typical use: Choosing to communicate with a broadcast + server, as opposed to a regular phone, when making a call to hear + an announcement. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.10. Mobility + + Media feature tag name: sip.mobility + + ASN.1 Identifier: 1.3.6.1.8.4.10 + + Summary of the media feature indicated by this tag: The sip.mobility + feature tag indicates whether the device is fixed (meaning that it + is associated with a fixed point of contact with the network), or + + + +Rosenberg, et al. Standards Track [Page 20] + +RFC 3840 SIP Capabilities August 2004 + + + mobile (meaning that it is not associated with a fixed point of + contact). Note that cordless phones are fixed, not mobile, based + on this definition. + + Values appropriate for use with this feature tag: Token with an + equality relationship. Typical values include: + + fixed: The device is stationary. + + mobile: The device can move around with the user. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: + This feature tag is most useful in a communications application + for describing the capabilities of a device, such as a phone or + PDA. + + Examples of typical use: Choosing to communicate with a wireless + phone instead of a desktop phone. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.11. Description + + Media feature tag name: sip.description + + ASN.1 Identifier: 1.3.6.1.8.4.11 + + Summary of the media feature indicated by this tag: The + sip.description feature tag provides a textual description of the + device. + + Values appropriate for use with this feature tag: String with an + equality relationship. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Indicating that a device is of a certain + make and model. + + Related standards or documents: RFC 3840 + + + + +Rosenberg, et al. Standards Track [Page 21] + +RFC 3840 SIP Capabilities August 2004 + + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.12. Event Packages + + Media feature tag name: sip.events + + ASN.1 Identifier: 1.3.6.1.8.4.12 + + Summary of the media feature indicated by this tag: Each value of the + sip.events (note the plurality) feature tag indicates a SIP event + package [9] supported by a SIP UA. The values for this tag equal + the event package names that are registered by each event package. + + Values appropriate for use with this feature tag: Token with an + equality relationship. Values are taken from the IANA SIP Event + types namespace registry. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Choosing to communicate with a server that + supports the message waiting event package, such as a voicemail + server [12]. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.13. Priority + + Media feature tag name: sip.priority + + ASN.1 Identifier: 1.3.6.1.8.4.13 + + Summary of the media feature indicated by this tag: The sip.priority + feature tag indicates the call priorities the device is willing to + handle. A value of X means that the device is willing to take + requests with priority X and higher. This does not imply that a + phone has to reject calls of lower priority. As always, the + decision on handling of such calls is a matter of local policy. + + + + + + + +Rosenberg, et al. Standards Track [Page 22] + +RFC 3840 SIP Capabilities August 2004 + + + Values appropriate for use with this feature tag: An integer. Each + integral value corresponds to one of the possible values of the + Priority header field as specified in SIP [1]. The mapping is + defined as: + + non-urgent: Integral value of 10. The device supports non-urgent + calls. + + normal: Integral value of 20. The device supports normal calls. + + urgent: Integral value of 30. The device supports urgent calls. + + emergency: Integral value of 40. The device supports calls in the + case of an emergency situation. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Choosing to communicate with the emergency + cell phone of a user. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.14. Methods + + Media feature tag name: sip.methods + + ASN.1 Identifier: 1.3.6.1.8.4.14 + + Summary of the media feature indicated by this tag: Each value of the + sip.methods (note the plurality) feature tag indicates a SIP + method supported by this UA. In this case, "supported" means that + the UA can receive requests with this method. In that sense, it + has the same connotation as the Allow header field. + + Values appropriate for use with this feature tag: Token with an + equality relationship. Values are taken from the Methods table + defined in the IANA SIP parameters registry. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + + +Rosenberg, et al. Standards Track [Page 23] + +RFC 3840 SIP Capabilities August 2004 + + + Examples of typical use: Choosing to communicate with a presence + application on a PC, instead of a PC phone application. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.15. Extensions + + Media feature tag name: sip.extensions + + ASN.1 Identifier: 1.3.6.1.8.4.15 + + Summary of the media feature indicated by this tag: Each value of the + sip.extensions feature tag (note the plurality) is a SIP extension + (each of which is defined by an option-tag registered with IANA) + that is understood by the UA. Understood, in this context, means + that the option tag would be included in a Supported header field + in a request. + + Values appropriate for use with this feature tag: Token with an + equality relationship. Values are taken from the option tags + table in the IANA SIP parameters registry. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Choosing to communicate with a phone that + supports quality of service preconditions instead of one that does + not. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.16. Schemes + + Media feature tag name: sip.schemes + + ASN.1 Identifier: 1.3.6.1.8.4.16 + + Summary of the media feature indicated by this tag: Each value of the + sip.schemes (note the plurality) media feature tag indicates a URI + scheme [10] that is supported by a UA. Supported implies, for + + + +Rosenberg, et al. Standards Track [Page 24] + +RFC 3840 SIP Capabilities August 2004 + + + example, that the UA would know how to handle a URI of that scheme + in the Contact header field of a redirect response. + + Values appropriate for use with this feature tag: Token with an + equality relationship. Values are taken from the IANA URI scheme + registry. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Choosing to get redirected to a phone number + when a called party is busy, rather than a web page. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.17. Actor + + Media feature tag name: sip.actor + + ASN.1 Identifier: 1.3.6.1.8.4.17 + + Summary of the media feature indicated by this tag: This feature tag + indicates the type of entity that is available at this URI. + + Values appropriate for use with this feature tag: Token with an + equality relationship. The following values are defined: + + principal: The device provides communication with the principal + that is associated with the device. Often this will be a + specific human being, but it can be an automata (for example, + when calling a voice portal). + + attendant: The device provides communication with an automaton or + person that will act as an intermediary in contacting the + principal associated with the device, or a substitute. + + msg-taker: The device provides communication with an automaton or + person that will take messages and deliver them to the + principal. + + information: The device provides communication with an automaton + or person that will provide information about the principal. + + + + +Rosenberg, et al. Standards Track [Page 25] + +RFC 3840 SIP Capabilities August 2004 + + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Requesting that a call not be routed to + voicemail. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +10.18. Is Focus + + Media feature tag name: sip.isfocus + + ASN.1 Identifier: 1.3.6.1.8.4.18 + + Summary of the media feature indicated by this tag: This feature tag + indicates that the UA is a conference server, also known as a + focus, and will mix together the media for all calls to the same + URI [13]. + + Values appropriate for use with this feature tag: Boolean. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: This + feature tag is most useful in a communications application for + describing the capabilities of a device, such as a phone or PDA. + + Examples of typical use: Indicating to a UA that the server to which + it has connected is a conference server. + + Related standards or documents: RFC 3840 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 11.1 of RFC 3840. + +11. Security Considerations + +11.1. Considerations for Media Feature Tags + + This section discusses security considerations for the media feature + tags, including, but not limited to, this specification. + + + + + + +Rosenberg, et al. Standards Track [Page 26] + +RFC 3840 SIP Capabilities August 2004 + + + The media feature tags defined in Section 10 reveal sensitive + information about a user or the user agent they are describing. Some + of the feature tags convey capability information about the agent - + for example, the media types it can support, the SIP methods it can + support, and the SIP extensions it can support. This capability + information might be used for industrial espionage, for example, and + so its protection may be important. Other attributes, such as the + mobility, priority, and isfocus attributes, reveal characteristics of + the user agent. These attributes are more sensitive than the + capability information. They describe the way in which a user agent + is utilized by a user, and thus reveal information about user + preferences and the ways in which they want calls handled. Some + feature tags, such as languages, reveal information about the user + themself. As a result, applications which utilize these media + feature tags SHOULD provide a means for ensuring their + confidentiality. + + The media feature tags can be used in ways which affect application + behaviors. For example, the SIP caller preferences extension [11] + allows for call routing decisions to be based on the values of these + parameters. Therefore, if an attacker can modify the values of these + feature tags, they may be able to affect the behavior of + applications. As a result of this, applications which utilize these + media feature tags SHOULD provide a means for ensuring their + integrity. Similarly, media feature tags should only be trusted as + valid when they come from the user or user agent described by those + feature tags. As a result, mechanisms for conveying feature tags + SHOULD provide a mechanism for guaranteeing authenticity. + +11.2. Considerations for Registrations + + As per the general requirements in Section 11.1, when media feature + tags are carried in a registration, authenticity, confidentiality, + and integrity need to be provided. To accomplish this, registrations + containing capability information SHOULD be made by addressing the + registration to a SIPS URI (in other words, the Request URI of the + request would be sips:example.com when creating a registration in the + example.com domain). Furthermore, the registrar SHOULD challenge the + UA using digest over TLS, to verify its authenticity. The + combination of TLS and digest provide integrity, confidentiality, and + authenticity, as required. + + It is not necessary for the Contact in the registration to itself + contain a sips URI, since the feature tags are not carried in + incoming requests sent to the UA. + + + + + + +Rosenberg, et al. Standards Track [Page 27] + +RFC 3840 SIP Capabilities August 2004 + + +11.3. Considerations for OPTIONS Responses + + When including information on capabilities in a response to an + OPTIONS request, a UA SHOULD verify with the user (either through a + user interface or though prior configuration) whether or not + capability information should be divulged to the requester. If the + identity of the requester cannot be cryptographically verified (using + digest or the SIP identity enhancements [15]), the user SHOULD also + be alerted to this fact, and be allowed to choose whether such + information should be divulged. + + If the user does wish to reveal capability information to the + requester, and wishes to guarantee its confidentiality, but the + request did not arrive using SIPS, the UAS SHOULD redirect the + request to a sips URI. This will cause the UAC to send the OPTIONS + request using SIPS instead, and therefore provide confidentiality of + any responses sent over the secure connections. + + Furthermore, S/MIME MAY be used in the OPTIONS response. In that + case, the capability information would be contained only in the + secured S/MIME body, and not in the header fields of the OPTIONS + response. + +11.4. Considerations for Dialog Initiating Messages + + When a UAS generates a response that will initiate a dialog, and they + wish to include capability information in the Contact header field, + the same considerations as described in Section 11.3 apply. + + When a UAC generates a request that will initiate a dialog, it SHOULD + obtain permission from the user (either through a user interface or + apriori configuration) before including capability information in the + Contact header field of the request. Confidentiality and integrity + of the information SHOULD be provided using SIPS. S/MIME MAY be + used. + +12. IANA Considerations + + There are a number of IANA considerations associated with this + specification. + +12.1. SIP Media Feature Tag Registration Tree + + This specification serves to create a new media feature tag + registration tree, per the guidelines of Section 3.1.4 of RFC 2506 + [3]. The name of this tree is the "SIP Media Feature Tag + Registration Tree", and its prefix is "sip.". It is used for the + registration of media feature tags that are applicable to the Session + + + +Rosenberg, et al. Standards Track [Page 28] + +RFC 3840 SIP Capabilities August 2004 + + + Initiation Protocol, and whose meaning is only defined within that + usage. + + The addition of entries into this registry occurs through IETF + consensus, as defined in RFC 2434 [18]. This requires the + publication of an RFC that contains the registration. The + information required in the registration is identical to the IETF + tree. As such, specifications adding entries to the registry should + use the template provided in Section 3.4 of RFC 2506. Note that all + media feature tags registered in the SIP tree will have names with a + prefix of "sip.". No leading "+" is used in the registrations in any + of the media feature tag trees. + +12.2. Media Feature Tags + + This specification registers a number of new Media feature tags + according to the procedures of RFC 2506 [3]. These registrations are + all made in the newly created SIP tree for media feature tags. These + registrations are: + + sip.audio: The information for registering the sip.audio media + feature tag is contained in Section 10.1. + + sip.application: The information for registering the sip.application + media feature tag is contained in Section 10.2. + + sip.data: The information for registering the sip.data media feature + tag is contained in Section 10.3. + + sip.control: The information for registering the sip.control media + feature tag is contained in Section 10.4. + + sip.video: The information for registering the sip.video media + feature tag is contained in Section 10.5. + + sip.text: The information for registering the sip.text media feature + tag is contained in Section 10.6. + + sip.automata: The information for registering the sip.automata media + feature tag is contained in Section 10.7. + + sip.class: The information for registering the sip.class media + feature tag is contained in Section 10.8. + + sip.duplex: The information for registering the sip.duplex media + feature tag is contained in Section 10.9. + + + + + +Rosenberg, et al. Standards Track [Page 29] + +RFC 3840 SIP Capabilities August 2004 + + + sip.mobility: The information for registering the sip.mobility media + feature tag is contained in Section 10.10. + + sip.description: The information for registering the sip.description + media feature tag is contained in Section 10.11. + + sip.events: The information for registering the sip.events media + feature tag is contained in Section 10.12. + + sip.priority: The information for registering the sip.priority media + feature tag is contained in Section 10.13. + + sip.methods: The information for registering the sip.methods media + feature tag is contained in Section 10.14. + + sip.extensions: The information for registering the sip.extensions + media feature tag is contained in Section 10.15. + + sip.schemes: The information for registering the sip.schemes media + feature tag is contained in Section 10.16. + + sip.actor: The information for registering the sip.actor media + feature tag is contained in Section 10.17. + + sip.isfocus: The information for registering the sip.isfocus media + feature tag is contained in Section 10.18. + +12.3. SIP Option Tag + + This specification registers a single SIP option tag, pref. The + required information for this registration, as specified in RFC 3261 + [1], is: + + Name: pref + + Description: This option tag is used in a Require header field of + a registration to ensure that the registrar supports the caller + preferences extensions. + +13. Acknowledgments + + The initial set of media feature tags used by this specification were + influenced by Scott Petrack's CMA design. Jonathan Lennox, Bob + Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty + provided helpful comments. Graham Klyne provided assistance on the + usage of RFC 2533. Thanks to Allison Mankin for her comments and + support, and to Ted Hardie for his guidance on usage of the media + feature tags. + + + +Rosenberg, et al. Standards Track [Page 30] + +RFC 3840 SIP Capabilities August 2004 + + +14. References + +14.1. Normative References + + [1] 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. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag + Registration Procedure", BCP 31, RFC 2506, March 1999. + + [4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC + 2533, March 1999. + + [5] Klyne, G., "Corrections to "A Syntax for Describing Media + Feature Sets"", RFC 2738, December 1999. + + [6] Hoffman, P., "Registration of Charset and Languages Media + Features Tags", RFC 2987, November 2000. + + [7] Klyne, G., "MIME Content Types in Media Feature Expressions", + RFC 2913, September 2000. + + [8] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [9] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + + [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, August + 1998. + +14.2. Informative References + + [11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller + Preferences for the Session Initiation Protocol (SIP)", RFC + 3841, August 2004. + + [12] Mahy, R., "A Message Summary and Message Waiting Indication + Event Package for the Session Initiation Protocol (SIP)", RFC + 3842, August 2004. + + + + + + +Rosenberg, et al. Standards Track [Page 31] + +RFC 3840 SIP Capabilities August 2004 + + + [13] Rosenberg, J., "A Framework for Conferencing with the Session + Initiation Protocol", Work in Progress, May 2003. + + [14] Howes, T. and M. Smith, "LDAP: String Representation of Search + Filters", Work in Progress, March 2003. + + [15] Peterson, J., "Enhancements for Authenticated Identity + Management in the Session Initiation Protocol (SIP)", Work in + Progress, March 2003. + + [16] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and + D. Gurle, "Session Initiation Protocol (SIP) Extension for + Instant Messaging", RFC 3428, December 2002. + + [17] Klyne, G., "Protocol-independent Content Negotiation + Framework", RFC 2703, September 1999. + + [18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg, et al. Standards Track [Page 32] + +RFC 3840 SIP Capabilities August 2004 + + +Appendix A. Overview of RFC 2533 + + This section provides a brief overview of RFC 2533 and related + specifications that form the content negotiation framework. This + section does not represent normative behavior. In the event of any + conflict between the tutorial material here and the normative text in + RFC 2533, RFC 2533 takes precedence. + + A critical concept in the framework is that of a feature set. A + feature set is information about an entity (in our case, a UA), which + describes a set of features it can handle. A feature set can be + thought of as a region in N-dimensional space. Each dimension in + this space is a different media feature, identified by a media + feature tag. For example, one dimension (or axis) might represent + languages, another might represent methods, and another, MIME types. + A feature collection represents a single point in this space. It + represents a particular rendering or instance of an entity (in our + case, a UA). For example, a "rendering" of a UA would define an + instantaneous mode of operation that it can support. One such + rendering would be processing the INVITE method, which carried the + application/sdp MIME type, sent to a UA for a user that is speaking + English. + + A feature set can therefore be defined as a set of feature + collections. In other words, a feature set is a region of N- + dimensional feature-space, that region being defined by the set of + points - feature collections - that make up the space. If a + particular feature collection is in the space, it means that the + rendering described by that feature collection is supported by the + device with that feature set. + + How does one represent a feature set? There are many ways to + describe an N-dimensional space. One way is to identify mathematical + functions which identify its contours. Clearly, that is too complex + to be useful. The solution taken in RFC 2533 is to define the space + with a feature set predicate. A feature predicate defines a relation + over an N-dimensional space; its input is any point in that space + (i.e., a feature collection), and is true for all points that are in + the region thus defined. + + RFC 2533 describes a syntax for writing down these N-dimensional + boolean functions, borrowed from LDAP [14]. It uses a prolog-style + syntax which is fairly self-explanatory. This representation is + called a feature set predicate. The base unit of the predicate is a + filter, which is a boolean expression encased in round brackets. A + filter can be complex, where it contains conjunctions and + + + + + +Rosenberg, et al. Standards Track [Page 33] + +RFC 3840 SIP Capabilities August 2004 + + + disjunctions of other filters, or it can be simple. A simple filter + is one that expresses a comparison operation on a single media + feature tag. + + For example, consider the feature set predicate: + + (& (foo=A) + (bar=B) + (| (baz=C) (& (baz=D) (bif=E)))) + + This defines a function over four media features - foo, bar, baz, and + bif. Any point in feature space with foo equal to A, bar equal to B, + and baz equal to either C or D, and bif equal to E, is in the feature + set defined by this feature set predicate. + + Note that the predicate doesn't say anything about the number of + dimensions in feature space. The predicate operates on a feature + space of any number of dimensions, but only those dimensions labeled + foo, bar, baz, and bif matter. The result is that values of other + media features don't matter. The feature collection + {foo=A,bar=B,baz=C,bop=F} is in the feature set described by the + predicate, even though the media feature tag "bop" isn't mentioned. + Feature set predicates are therefore inclusive by default. A feature + collection is present unless the boolean predicate rules it out. + This was a conscious design choice in RFC 2533. + + RFC 2533 also talks about matching a preference with a capability + set. This is accomplished by representing both with a feature set. + A preference is a feature set - its a specification of a number of + feature collections, any one of which would satisfy the requirements + of the sender. A capability is also a feature set - its a + specification of the feature collections that the recipient supports. + There is a match when the spaces defined by both feature sets + overlap. When there is overlap, there exists at least one feature + collection that exists in both feature sets, and therefore a modality + or rendering desired by the sender which is supported by the + recipient. + + This leads directly to the definition of a match. Two feature sets + match if there exists at least one feature collection present in both + feature sets. + + Computing a match for two general feature set predicates is not easy. + Section 5 of RFC 2533 presents an algorithm for doing it by expanding + an arbitrary expression into disjunctive normal form. However, the + feature set predicates used by this specification are constrained. + They are always in conjunctive normal form, with each term in the + conjunction describing values for different media features. This + + + +Rosenberg, et al. Standards Track [Page 34] + +RFC 3840 SIP Capabilities August 2004 + + + makes computation of a match easy. It is computed independently for + each media feature, and then the feature sets overlap if media + features specified in both sets overlap. Computing the overlap of a + single media feature is very straightforward, and is a simple matter + of computing whether two finite sets overlap. + +Authors' Addresses + + Jonathan Rosenberg + dynamicsoft + 600 Lanidex Plaza + Parsippany, NJ 07054 + US + + Phone: +1 973 952-5000 + EMail: jdrosen@dynamicsoft.com + URI: http://www.jdrosen.net + + Henning Schulzrinne + Columbia University + M/S 0401 + 1214 Amsterdam Ave. + New York, NY 10027 + US + + EMail: schulzrinne@cs.columbia.edu + URI: http://www.cs.columbia.edu/~hgs + + Paul Kyzivat + Cisco Systems + 1414 Massachusetts Avenue + BXB500 C2-2 + Boxboro, MA 01719 + US + + EMail: pkyzivat@cisco.com + + + + + + + + + + + + + + + +Rosenberg, et al. Standards Track [Page 35] + +RFC 3840 SIP Capabilities August 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Rosenberg, et al. Standards Track [Page 36] + -- cgit v1.2.3