Internet Engineering Task Force SIP WG Internet Draft J. Rosenberg dynamicsoft H. Schulzrinne Columbia U. [-draft-ietf-sip-callerprefs-07.txt November 4, 2002-] {+P. Kyzivat Cisco draft-ietf-sip-callerprefs-08.txt March 2, 2003+} Expires: [-May-] {+September+} 2003 [-Session Initiation Protocol (SIP)-] Caller Preferences and Callee Capabilities {+for the Session Initiation Protocol (SIP)+} STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which [-URIs-] {+Uniform Resource Identifiers (URI)+} a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining [-four-] {+three+} new request [-headers,-] {+header fields,+} Accept-Contact, [-Reject- Contact, Require-Contact-] {+Reject-Contact,+} and Request-Disposition, which specify the caller's preferences. The extension also defines new parameters for the Contact header {+field+} that describe the {+J. Rosenberg et. al. [Page 1] Internet Draft SIP Caller Preferences March 2, 2003+} capabilities and characteristics of a [-UA.-] {+User Agent (UA).+} J. Rosenberg et. al. [Page [-1]-] {+2]+} Internet Draft SIP Caller Preferences [-November 4, 2002-] {+March 2, 2003+} Table of Contents 1 Introduction ........................................ [-3-] {+5+} 2 Terminology ......................................... [-4-] {+6+} 3 Definitions ......................................... [-4-] {+6+} 4 Overview of Operation ............................... [-6-] {+8+} 5 Usage of the Content Negotiation Framework .......... [-7-] {+9+} 6 UA Behavior ......................................... [-8-] {+11+} 6.1 Expressing Capabilities in a Registration ........... [-8-] {+11+} 6.2 Expressing Preferences in a Request ................. [-10-] {+14+} 6.2.1 Request Handling Preferences ........................ [-11-] {+15+} 6.2.2 Feature Set Preferences ............................. [-11-] {+15+} 6.3 Indicating Feature Sets in Remote Target URIs ....... [-12-] {+16+} 6.4 {+Processing+} Request Handling and Feature Set Preferences [-........ 13-] {+.................................................... 17 6.5 OPTIONS Processing .................................. 17+} 7 Proxy Behavior ...................................... [-14-] {+18+} 7.1 Request-Disposition Processing ...................... [-14-] {+18+} 7.2 Preference and Capability Matching .................. [-14-] {+18+} 7.2.1 Extracting Explicit Preferences ..................... [-14-] {+18+} 7.2.2 Extracting Implicit Preferences ..................... [-15-] {+19+} 7.2.2.1 [-Priority ............................................ 15 7.2.2.2-] Methods ............................................. [-16 7.2.2.3-] {+19 7.2.2.2+} Event Packages ...................................... [-16 7.2.2.4 Media Types ......................................... 17 7.2.2.5 Languages ........................................... 17-] {+20+} 7.3 Constructing Contact Predicates ..................... [-18-] {+20+} 7.4 Matching ............................................ [-19-] {+21 7.4.1 Example ............................................. 27+} 8 Header Field Definitions ............................ [-21-] {+29+} 8.1 Request Disposition ................................. [-21-] {+29+} 8.2 [-Accept-Contact, Reject-Contact,-] {+Accept-Contact+} and [-Require- Contact-] {+Reject-Contact+} Header Fields [-.......................................... 23-] {+..... 31+} 8.3 Contact Header Field ................................ [-23-] {+31+} 9 Media Feature Tag Definitions ....................... [-24-] {+32+} 9.1 Attendant ........................................... [-24-] {+32+} 9.2 Audio ............................................... [-25-] {+33+} 9.3 {+Application ......................................... 33 9.4 Data ................................................ 34 9.5 Control ............................................. 35 9.6+} Automata ............................................ [-25 9.4-] {+35 9.7+} Class ............................................... [-26 9.5-] {+36 9.8+} Duplex .............................................. [-26 9.6 Image ............................................... 27 9.7 Message ............................................. 28 9.8-] {+36 9.9+} Mobility ............................................ [-28 9.9-] {+37 9.10+} Description ......................................... [-29 9.10-] {+38 9.11+} Event Packages ...................................... [-29 9.11-] {+38 9.12+} Priority ............................................ [-30-] {+39+} J. Rosenberg et. al. [Page [-2]-] {+3]+} Internet Draft SIP Caller Preferences [-November 4, 2002 9.12 Methods ............................................. 31-] {+March 2, 2003+} 9.13 [-Schemes-] {+Methods+} ............................................. [-32-] {+40+} 9.14 [-Text ................................................ 33-] {+SIP Extensions ...................................... 41+} 9.15 {+Schemes ............................................. 42 9.16+} Video ............................................... [-33 9.16 Voicemail ........................................... 34-] {+43 9.17 Message Server ...................................... 43 9.18 Is Focus ............................................ 44 9.19 URI User ............................................ 44 9.20 URI Domain .......................................... 45+} 10 Augmented BNF ....................................... [-34-] {+45+} 11 Mapping Feature Parameters and Feature Set Predicates ..................................................... [-35-] {+47+} 12 Security Considerations ............................. [-38-] {+50+} 13 IANA Considerations ................................. [-39-] {+50+} 13.1 Media Feature Tags .................................. [-39-] {+50+} 13.2 SIP Header Fields ................................... [-39-] {+51+} 13.3 SIP Option Tags ..................................... [-40-] {+51+} 14 [-Acknowledgements .................................... 40-] {+Acknowledgments ..................................... 52+} 15 Author's Addresses .................................. [-40-] {+52+} 16 Normative References ................................ [-41-] {+52+} 17 Informative References .............................. [-42-] {+54+} A Overview of RFC 2533 ................................ [-43-] {+55+} J. Rosenberg et. al. [Page [-3]-] {+4]+} Internet Draft SIP Caller Preferences [-November 4, 2002-] {+March 2, 2003+} 1 Introduction When a Session Initiation Protocol (SIP) [1] server receives a request, there are a number of decisions it can make regarding processing of the request. These include: o whether to proxy or redirect the request o which URIs to proxy or redirect to o whether to fork or not o whether to search recursively or not o whether to search in parallel or sequentially The server can base these decisions on any local policy. This policy can be statically configured, or can be based on programmatic execution or database access. However, the administrator of the server is the not the only entity with an interest in request processing. There are at least three parties which have an interest: (1) the administrator of the server, (2) the user that sent the request, and (3) the user to whom the request is directed. The directives of the administrator are embedded in the policy of the server. The preferences of the user to whom the request is directed (referred to as the callee, even though the request may not be INVITE) can be expressed most easily through a script written in some type of scripting language, such as the Call Processing Language (CPL) [-[16].-] {+[22].+} However, no mechanism exists to incorporate the preferences of the user that sent the request (also referred to as the caller, even though the request may not be INVITE). For example, the caller might want to speak to a specific user, but want to reach them only at work, because the call is a business call. As another example, the caller might want to reach a user, but not their voicemail, since it is important that the caller talk to the called party. In both of these examples, the caller's preference amounts to having a proxy make a particular routing choice based on the preferences of the caller. This extension allows the [-requestor-] {+caller+} to have these preferences met. It does so by specifying mechanisms by which a caller can provide preferences on processing of a request. There are two types of preferences. One of them, called request handling preferences, are encapsulated in the Request-Disposition header field. They [-provides-] {+provide+} specific request handling directives for a server. The other, called feature preferences, are present in the [-Accept-Contact, Reject- Contact,-] {+Accept-Contact+} and [-Require-Contact-] {+Reject- Contact+} header fields. They allow the caller to {+provide a feature set+} J. Rosenberg et. al. [Page [-3]-] {+5]+} Internet Draft SIP Caller Preferences [-November 4, 2002 provide a feature set-] {+March 2, 2003+} [2] that expresses its preferences on the characteristics of the UA that is to be reached. These are matched with a feature set carried in the Contact header {+field+} of a REGISTER request, which describes the capabilities of the UA represented by the Contact URI. The extension is very general purpose, and not tied to a particular service. Rather, it is a tool that can be used in the development of many services. Indeed, the feature sets uploaded to the server in REGISTER requests can be used for a variety of purposes, not just meeting caller preferences. Applications can use this information to tailor information sent to a user as part of an instant message, for example [-[17]. 2 Terminology In this document,-] {+[3]. One example of+} the [-key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels-] {+a service enabled by caller preferences is a "one number" service. A user can have a single identity (their SIP URI) for all of their devices - their cell phone, PDA, work phone, home phone, and so on. If the caller wants to reach the user at their business phone, they simply select "business phone" from a pull-down menu of options when calling that URI. Users would no longer need to maintain and distribute separate identities for each device. 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 RFC 2119 [4] and indicate requirement levels+} for compliant SIP implementations. 3 Definitions Caller: Within the context of this specification, a caller refers to the user on whose behalf a UAC is operating. It is not limited to a user who's UAC sends the INVITE method. Feature: As defined in RFC 2703 [-[18],-] {+[23],+} 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 [-[18],-] {+[23],+} a feature tag is a name that identifies a feature. {+An example is "methods".+} Media Feature: As defined in RFC 2703, [-[18],-] {+[23],+} 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. {+J. Rosenberg et. al. [Page 6] Internet Draft SIP Caller Preferences March 2, 2003+} 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 [2], a feature collection is a collection of different media features and [-J. Rosenberg et. al. [Page 4] Internet Draft SIP Caller Preferences November 4, 2002-] 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 [-[18],-] {+[23],+} a feature set is Information about a sender, [-recipient, data file-] {+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 full set of possible attributes. Feature Preferences: Caller preferences that described desired properties of a UA that the request is to be routed to. [-These-] {+Feature+} preferences [-are carried in-] {+can be made explicitly with+} the [-Accept-Contact, Reject-Contact-] {+Accept-Contact+} and [-Require-Contact-] {+Reject-Contact+} header fields. Request Handling Preferences: Caller preferences that describe desired request treatment at a server. These preferences are carried in the Request-Disposition header field. Feature Parameters: A set of SIP header field parameters that can appear in the Contact, [-Accept-Contact, Reject-Contact-] {+Accept-Contact+} and [-Require-Contact-] {+Reject- Contact+} header fields. The feature parameters represent an encoding of a feature set. [-There is a one-one mapping between a-] {+Each+} set of feature parameters [-and-] {+maps to+} a feature set [-predicate, as both represent alternative encodings of a feature set.-] {+predicate.+} Capability: As defined in RFC 2703 [-[18],-] {+[23],+} 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. [-Filter:-] {+Target Set:+} A [-single expression in a feature predicate. Simple Filter: An expression in a feature predicate which-] {+target set+} is a [-comparison (equality or inequality)-] {+set+} of {+candidate URI that+} a [-feature tag against-] {+proxy or redirect server can send or redirect+} a [-feature value. Disjunction:-] {+request to. Frequently, target sets are obtained from a registration, but they need not be. Explicit Preference:+} A [-boolean OR operation across some number of terms. Predicate:-] {+caller preference indicated explicitly in the Accept-Contact or Reject-Contact header fields. Implicit Preference:+} A [-boolean expression. Feature Set Predicate: From RFC 2533 [2], a feature set predicate-] {+caller preference that+} is [-a-] {+implied through the presence of other aspects of a request. For example, if J. Rosenberg et. al. [Page 7] Internet Draft SIP Caller Preferences March 2, 2003 the request method is INVITE, it represents an implicit caller preference to route the request to a UA that supports the INVITE method. Filter: A single expression in a feature set predicate. Simple Filter: An expression in a feature 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 [2], 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 [-J. Rosenberg et. al. [Page 5] Internet Draft SIP Caller Preferences November 4, 2002-] 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. 4 Overview of Operation This extension defines a set of additional parameters to the Contact header field, called feature parameters. Each parameter name is [-a-] {+an encoded+} feature tag, as defined in RFC 2703 [-[18],-] {+[23],+} that defines a capability for the UA associated with the Contact header field value. For example, there is a parameter for the SIP methods supported by the UA. Each feature parameter has a value; that value is the set of feature values for that feature tag. Put together, all of the feature parameters specify a feature set that is supported by the UA associated with that Contact header field value. When a UA registers, it places these parameters in the Contact header field value to provide a feature set for [-each-] {+a+} URI it is registering. The feature parameters are also mirrored in the Contact header field in a REGISTER response. The proxy can use this feature set to route requests based on caller preferences. Furthermore, Contact header fields in requests and responses that establish a dialog can contain these parameters. That allows a UA in a dialog to indicate its {+J. Rosenberg et. al. [Page 8] Internet Draft SIP Caller Preferences March 2, 2003+} feature set to its peer. For example, by including the [-"voicemail"-] {+"msgserver"+} feature tag with value "TRUE" in the 200 OK to an INVITE, the UAS can indicate to the UAC that it is a voicemail server. This information is useful for user interfaces, as well as automated call handling. When a caller sends a request, it can optionally include new header fields which request certain handling at a server. These preferences fall into two categories. The first category, called request handling preferences, are carried in the Request-Disposition header field. They describe specific behavior that is desired at a server. Request handling preferences include whether the caller wishes the server to proxy or redirect, and whether sequential or parallel search is desired. These preferences can be applied at every proxy or redirect server on the call signaling path. The second category of preferences, called feature preferences, are carried in the [-Accept-Contact, Reject-Contact,-] {+Accept-Contact+} and [-Require-Contact-] {+Reject-Contact+} header fields. These header fields also contain feature sets, represented by the same feature parameters that are used in the Contact [-header.-] {+header field.+} Here, the feature parameters represent the caller's preferences. The Accept-Contact header field contains feature sets that describe UAs that the caller would like to reach. The [-Reject- J. Rosenberg et. al. [Page 6] Internet Draft SIP Caller Preferences November 4, 2002 Contact header field contains feature sets which, if matched by a UA, imply that the request should not be routed to that UA. The Require- Contact-] {+Reject-Contact+} header field contains feature sets which, if [-not-] matched by a UA, imply that the request should not be routed to that UA. [-Require- Contact and Accept-Contact are similar, but Require-Contact is more forceful. Contacts which don't match are outright rejected, whereas with Accept-Contact, they are tried as fallbacks.-] Proxies use the information in the [-Accept-Contact, Reject-Contact-] {+Accept-Contact+} and [-Require-Contact-] {+Reject-Contact+} header fields to select amongst [-registered contacts. Proxies also compute-] {+contacts in their target set. When neither of those header fields are present, the proxy computes+} implicit preferences from the request. These are caller preferences that are not explicitly placed into the request, but can be inferred from the presence of other message components. As an example, if the request method is INVITE, this is an implicit preference to route the call to a UA that supports the INVITE method. Both request handling and feature preferences can appear in any request, not just INVITE. However, they are only useful in requests where proxies need to determine a request target. If the domain in the request URI is not owned by any proxies along the request path, those proxies will never access a location service, and therefore, never have the opportunity to apply the caller preferences. This makes sense; typically, the request URI will identify a UAS for mid- dialog requests. In those cases, the routing decisions were already made on the initial request, and it makes no sense to redo them for subsequent requests in the dialog. 5 Usage of the Content Negotiation Framework This specification makes heavy use of the terminology and concepts in {+J. Rosenberg et. al. [Page 9] Internet Draft SIP Caller Preferences March 2, 2003+} the content negotiation work carried out within the IETF, and documented in several RFCs. The ones relevant to this specification are RFC 2506 [-[4]-] {+[5]+} which provides a template for registering media feature tags, RFC 2533 [2] which presents a syntax and matching algorithm for media feature sets, RFC 2738 [-[5],-] {+[6],+} which provides a minor update to RFC 2533, and RFC 2703 [-[18]-] {+[23]+} 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 the SIP entities at hand. The goal of this specification is to allow a UA to express its feature set, and for a caller to express a feature set that describes [-J. Rosenberg et. al. [Page 7] Internet Draft SIP Caller Preferences November 4, 2002-] properties of a desirable (or undesirable) UA. Therefore, we are using feature sets to describe 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 [-messaging.-] {+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 instant of 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 "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. 6-] {+J. Rosenberg et. al. [Page 10] Internet Draft SIP Caller Preferences March 2, 2003 at hand. 6+} UA Behavior UA behavior covers [-four-] {+five+} separate cases. The first is registration, where a UA can declare its capabilities. The second is expression of [-preferences,-] {+preferences in a request,+} where a UA can tell a proxy how it wants the request to be processed and routed. The third is expressing of capabilities, through a feature set, in the Contact header field of a target refresh request or response. The fourth is UAS processing of the request handling and feature preferences. {+The fifth is UAS processing of an OPTIONS request.+} 6.1 Expressing Capabilities in a Registration When a UA registers, it [-MAY construct-] {+can choose to indicate+} a feature [-predicate for each Contact-] {+set associated with a registered contact. Whether or not a UA does so depends on what the registered+} URI [-it registers. In-] {+represents. If+} the [-text that follows,-] {+registered URI represents a UA instance (the common case in registrations), a UA compliant to+} this [-process is-] {+specification SHOULD indicate a feature set using the mechanisms+} described [-in terms of RFC 2533 [2] (and its minor update, [5]) syntax and constructs, followed-] {+here. If, however, the registered URI represents an address-of-record, or some other resource that is not representable+} by a [-conversion-] {+single feature set, it SHOULD NOT include a feature set. As an example, if a user wishes+} to [-the syntax used-] {+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. If a UA does not include feature parameters for a contact, that contact will be immune from the caller preference processing. Therefore, if a registering client does not want caller preferences applied to a contact, it omits all feature parameters. Addresses-of- record in particular often need to be immune from caller preferences processing. If they were not, such a URI might be eliminated from consideration, even though a downstream UA satisfies the desired constraints.+} J. Rosenberg et. al. [Page [-8]-] {+11]+} Internet Draft SIP Caller Preferences [-November 4, 2002 specification.-] {+March 2, 2003+} However, [-this-] {+in some cases a UA may wish to express feature parameters for an address-of-record. One example is an AOR which+} represents a [-logical-] {+mutliplicity 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. The remainder of this section assumes that a UA would like to associate a feature set with a contact that it is registering. To do that, it constructs a feature predicate for that contact. In the text that follows, this process is described in terms of RFC 2533 [2] (and its minor update, [6]) 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. The feature predicate constructed by a UA MUST be an AND of [-terms.-] {+terms (called a conjunction).+} Each term is either an OR of simple filters (called a disjunction), or a single simple filter. In the case of an OR of simple filters, each filter MUST indicate feature values for the same feature tag (i.e., the disjunction represents a set of values for a particular feature tag), and each element of the conjunction MUST be for a different feature tag. Each filter can be an equality, the negation of an equality, or in the case of numeric feature tags, an {+inequality, range, or negation of an+} inequality or range. This feature predicate is then converted to a list of feature parameters using the procedure specified in Section 11. Those feature parameters are added to the the Contact header field value containing the URI that the parameters apply to. A UA MAY use any feature tags that are registered through IANA in the IETF or global trees [-[4];-] {+[5];+} this document registers several that are appropriate for SIP. It is also permissible to use the URI tree [-[4]-] {+[5]+} for expressing vendor-specific feature tags. Feature tags in any other trees created through IANA MAY also be used. A UA [-MAY-] {+SHOULD+} include the [-"schemes"-] {+"uri-user" and "uri-domain"+} feature tag in its feature parameters. [-However, this tag MUST include a-] {+The+} value [-that matches-] {+of those tags SHOULD be equal to+} the [-scheme-] {+user and domain part+} of the [-URI being registered. For example,-] {+registered URI, respectively. Setting them differently is likely to result in odd behavior, and should only be done+} if [-a SIP URI-] {+some unforseen service neccesitates it. Note that the "uri-user" feature tag+} is [-being registered,-] {+a quoted string (implying case sensitive matching), and+} the [-schemes parameter can include-] {+"uri-domain" feature tag is+} a {+token, implying case J. Rosenberg et. al. [Page 12] Internet Draft+} SIP [-and TEL URI [6]. If this-] {+Caller Preferences March 2, 2003 insensitive matching. Note that the "schemes"+} feature tag is [-omitted,-] {+not a peer of+} the [-proxy will assume an implicit value for it, equal to-] {+"uri-user" and "uri-domain" feature tags. That is, it does not indicate+} the scheme of the registered URI. [-It is RECOMMENDED-] {+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 feature [-parameters.-] {+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. [-This includes features that are supported, and those that are not. For example, if a UA does not support video, it SHOULD include a 'video="FALSE"' parameter in its registered Contact.-] Furthermore, when a UA registers values for a particular feature tag, it MUST list all values that it supports. For example, when including the [-methods-] {+"methods"+} feature tag, a UA MUST list all methods it supports. The matching algorithms in this specification assume that [-ommission-] {+omission+} of a value from a list means that the value is not supported. {+When using the "methods" feature tag, a UA MUST NOT include values that correspond to methods not standardized in IETF standards track RFCs. When using the "events" feature tag, a UA MUST NOT include values that correspond to event packages not standardized in IETF standards track RFCs. When using the "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.+} 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. In absence of the Require header field, a server that does not understand this extension will simply ignore the Contact header field parameters. [-J. Rosenberg et. al. [Page 9] Internet Draft SIP Caller Preferences November 4, 2002-] As an example, a UA that supports audio and video media types, is a voicemail server, and is not mobile would construct a feature predicate like this: (& (audio=TRUE) (video=TRUE) [-(voicemail=TRUE)-] {+(msgserver=TRUE) (automata=TRUE) (attendant=TRUE)+} (mobility=fixed) (| (methods=INVITE) (methods=BYE) (methods=OPTIONS) (methods=ACK) [-(methods=CANCEL)))-] {+(methods=CANCEL)) J. Rosenberg et. al. [Page 13] Internet Draft SIP Caller Preferences March 2, 2003 (uri-user="user") (uri-domain=host.example.com)+} 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="TRUE";video="TRUE" [-;voicemail="TRUE";mobility="fixed"-] {+;msgserver="TRUE";automata;attendant;mobility="fixed"+} ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" {+;uri-user="" ;uri-domain="host.example.com"+} Content-Length: 0 {+Note that a voicemail server is usually an automata and an attendant, as defined below.+} 6.2 Expressing Preferences in a Request A caller wishing to express preferences for a request includes Accept-Contact, [-Reject-Contact, Require-Contact-] {+Reject-Contact+} or [-Request- Disposition-] {+Request-Disposition+} header fields in the request, depending on their particular preferences. No additional behavior is required after the request is sent. The Accept-Contact, [-Reject-Contact, Require-Contact-] {+Reject-Contact+} and [-Request- Disposition-] {+Request-Disposition+} header fields in an ACK for a non-2xx final response, or in a CANCEL request, MUST be equal to the values in the original request being acknowledged or cancelled. This is to ensure proper operation through stateless proxies. [-J. Rosenberg et. al. [Page 10] Internet Draft SIP Caller Preferences November 4, 2002-] If the UAC wants to be sure that servers understand the header fields described in this specification, it MAY include a Proxy-Require header field with a value of "pref". However, this is NOT RECOMMENDED, as it leads to interoperability problems. In any case, caller preferences can only be considered preferences - there is no guarantee that the requested service [-or capability-] is executed. As such, inclusion {+J. Rosenberg et. al. [Page 14] Internet Draft SIP Caller Preferences March 2, 2003+} of a Proxy-Require header field does not mean the preferences will be executed, just that the caller preferences extension is understood by the proxies. 6.2.1 Request Handling Preferences The Request-Disposition header field specifies caller preferences for how a server should process a request. Its value is a list of tokens, each of which specifies a particular processing directive. The syntax of the header field can be found in Section 10, and the semantics of the directives are described in Section 8.1. 6.2.2 Feature Set Preferences A UAC can indicate caller preferences for the capabilities of a UA that should be reached or not reached as a result of sending a SIP request. To do that, it adds one or more [-Accept-Contact, Reject- Contact,-] {+Accept-Contact+} and [-Require-Contact-] {+Reject- Contact+} header field values. Each header field value [-is either-] {+contains+} a [-URI or the wildcard "*", along with-] {+set of+} feature parameters that define a feature set. In the case of Accept-Contact, each value can also have a q-value parameter. Each feature set MUST follow the constraints of Section 6.1. [-That-] {+The feature sets placed into these header fields MAY overlap; that+} is, [-when represented by-] a [-feature set predicate, each predicate MUST be a conjunction of terms. Each term is either an OR of simple filters (called a disjunction), or a single simple filter. In the case of an OR of simple filters, each filter MUST indicate feature values for the same feature tag (i.e., the disjunction represents a set of values for a particular feature tag), and each element of the conjunction MUST be for a different feature tag. Each filter can be an equality, the negation of an equality, or in the case of numeric feature tags, an inequality or range. The feature sets placed into these header fields MAY overlap; that is, a UA MAY indicate preferences for-] {+UA MAY indicate preferences for+} feature sets that match according to the matching algorithm of RFC 2533 [2]. The UA MAY use any feature tag in an IANA registry or in a vendor defined URI tree. [-Note that the-] {+A+} UAC can express explicit preferences for the [-methods,-] {+methods and+} event packages [-and priorities-] supported by a UA. [-As described-] {+It is RECOMMENDED that a UA include a term+} in [-Section 7.2.2,-] {+an Accept-Contact feature set with the "methods" feature tag, whose value includes the method of the request. When+} a [-proxy will compute implicit preferences from-] {+UA sends a SUBSCRIBE request, it is RECOMMENDED that a UA include a term in an Accept-Contact feature set with+} the [-J. Rosenberg et. al. [Page 11] Internet Draft SIP Caller Preferences November 4, 2002 request if explicit ones-] {+"events" feature tag, whose value includes the event package of the request. Whether these terms+} are [-not provided.-] {+placed into a new feature set, or whether they are included in each feature set, is at the discretion of the implementor. In most cases, the right effect is achieved by including a term in each feature set.+} The Reject-Contact header field allows the UAC to specify that a UA should not be contacted if it matches any of the values of the header field. Each value of the Reject-Contact header field contains a [-URI or a "*"-] {+"*", purely to align the syntax with guidelines for SIP extensions [24],+} and is parameterized by a set of feature parameters. Any UA whose capabilities match the feature set described by the feature [-parameters, and whose URI matches the URI in the value (if specified),-] {+parameters+} matches the value. [-A value of "*" indicates a wildcard operation on the URI, so that any URI matches.-] As with registrations, it is not necessary for a UAC to construct the feature set in RFC 2533 syntax as an intermediate step. The only requirement is that the feature {+J. Rosenberg et. al. [Page 15] Internet Draft SIP Caller Preferences March 2, 2003+} parameters, if converted back to RFC 2533 format, meet the requirements above. The [-Require-Contact-] {+Accept-Contact+} header field allows the UAC to specify that a UA should [-not-] be contacted if it [-doesn't match-] {+matches some or+} all of the values of the header field. Each value of the [-Require-Contact-] {+Accept-Contact+} header field contains a [-URI or a-] "*" and is parameterized by {+a+} set of feature parameters. Any UA whose capabilities match the feature set described by the feature [-parameters, and whose URI matches the URI in the value (if specified),-] {+parameters+} matches the value. {+The q-value parameter provides a weighting operation.+} A {+q-value parameter with a particular+} value {+means that the caller's preference for a UA described by the feature parameters equals that value. The processing rules at a proxy will also favor those UA that are a "better" match to a particular value. Here, better means that more+} of [-"*"-] {+its capabilities explicitly match the feature preferences. The value may also contain an "explicit" parameter, which+} indicates {+that only UA whose capabilities explicitly match are considered+} a [-wildcard operation on-] {+match. If one of+} the [-URI, so-] {+values contains the "require" parameter, it means+} that [-any URI matches.-] {+the UA must match that value.+} As with registrations, it is not necessary for a UAC to construct the feature set in RFC 2533 syntax as an intermediate step. The only requirement is that the feature parameters, if converted back to RFC 2533 format, meet the requirements above. {+6.3 Indicating Feature Sets in Remote Target URIs Target refresh requests and responses are used to establish and modify the remote target URI.+} The [-Accept-Contact header field allows-] {+remote target URI is contained in+} the {+Contact header field. A+} UAC [-to specify that a UA should be contacted if it matches some-] or [-all of-] {+UAS MAY add feature parameters to+} the [-values-] {+Contact header field value in target refresh requests and responses, for the purpose+} of {+indicating+} the [-header field. If a UA matches none-] {+capabilities+} of the [-values,-] {+UA. To do that,+} it [-should be contacted as-] {+constructs+} a [-last resort. Each value of the Accept-Contact header field contains a URI or a "*" and is parameterized by a set of feature parameters. Any UA whose capabilities match the feature set described by the feature parameters, and whose URI matches the URI in the value (if specified), matches the value. A value of "*" indicates a wildcard operation on the URI, so that any URI matches. The q-value provides a weighting operation, allowing the UAC to request preferential routing to UAs that match that value above other values. As with registrations, it is not necessary for a UAC to construct the feature set in RFC 2533 syntax as an intermediate step. The only requirement is that the feature parameters, if converted back to RFC 2533 format, meet the requirements above. 6.3 Indicating Feature Sets in Remote Target URIs Target refresh requests and responses are used to establish and modify the remote target URI. The remote target URI is contained in J. Rosenberg et. al. [Page 12] Internet Draft SIP Caller Preferences November 4, 2002 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 feature set predicate according to-] {+feature set predicate according to+} the constraints of Section 6.1, and converts it to a set of feature parameters using the rules in Section 11. 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 [-request,-] {+requests,+} and MAY change mid-dialog to signal a change in UA capabilities. There is overlap in the caller preferences mechanism with the Allow, Accept, Accept-Language, and Allow-Events [7] header fields, which can also be used in target refresh requests. Specifically, the Allow header field and [-methods-] {+"methods"+} feature tag indicate the same information. The Accept header field and the [-type-] {+"type"+} feature tag indicate the same information. The Accept-Language header field and the [-language-] {+"language"+} feature tag indicate the same information. The Allow-Events header field and the [-events-] {+"events"+} feature tag indicate the same information. It is possible that other header fields and feature tags defined in the {+J. Rosenberg et. al. [Page 16] Internet Draft SIP Caller Preferences March 2, 2003+} 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. 6.4 {+Processing+} Request Handling and Feature Set Preferences When a UAS compliant to this specification receives a request whose request-URI [-correspods-] {+corresponds+} to one of its registered Contacts, it SHOULD apply the behavior described in Section 7 as if it were a proxy for the domain in the request-URI. The UAS acts as if its location database contains a single request target for the request-URI. That target is associated with a feature set. The feature set is the same as the one placed in the registration of the URI in the request-URI. [-It also adds-] {+This processing occurs after+} the [-uri-user-] {+client authenticates+} and [-uri-domain terms to-] {+authorizes+} the [-conjunction as-] {+request, but before the remainder of the general UAS processing+} described in Section [-7.2.1. Having-] {+8.2.1 of RFC 3261. If+} a [-UAS perform the matching operations as-] {+UA registers against two separate addresses-of-record, and the contacts registered for each have different capabilities, a UA MUST use different URIs in each registration. This is so that the UA can uniquely determine the feature set that is associated with the request URI of an incoming request. If, after performing this processing, there are no URI left in the target set, the UA SHOULD reject the request with a 480 response. If there is a URI remaining (there was only one to begin with), the UA proceeeds with request processing as per RFC 3261. Having a UAS perform the matching operations as+} if it were a proxy [-has many benefits. First, it-] allows {+certain+} caller preferences to be honored even if the proxy doesn't support the extension. [-Secondly, and perhaps more importantly,-] {+6.5 OPTIONS Processing When a UAS compliant to this specification receives an OPTIONS request, it MAY add+} feature [-set processing of preferences-] {+parameters to the Contact header field in the OPTIONS response+} for the [-URI will only occur at a UA, not at a proxy. Thats because-] {+purpose of indicating+} the [-UA is-] {+capabilities of+} the [-only one that adds-] {+UA. To do that, it constructs a feature set predicate according to+} the [-uri-user-] {+constraints of Section 6.1,+} and [-uri-domain terms-] {+converts it+} to {+a set of feature parameters using+} the {+rules in Section 11. These are then added as Contact header field parameters in OPTIONS response. Indeed, if+} feature [-set describing a request target.-] {+parameters were included in the registration generated by that UA, those same parameters SHOULD be used in the OPTIONS response.+} J. Rosenberg et. al. [Page [-13]-] {+17]+} Internet Draft SIP Caller Preferences [-November 4, 2002-] {+March 2, 2003+} 7 Proxy Behavior Proxy behavior consists of two orthogonal sets of rules - one for processing the Request-Disposition header field, and one for processing the URI and feature set preferences in the [-Accept-Contact, Reject-Contact,-] {+Accept-Contact+} and [-Require-Contact-] {+Reject-Contact+} header fields. [-7.1 Request-Disposition Processing If the request contains-] {+In addition to processing these headers,+} a [-Request-Disposition-] {+proxy MAY add one if not present, or add a value to an existing+} header field, [-the server-] {+as if it were a UAC. This is useful for a proxy to request processing in downstream proxies in the implementation of a feature. However a proxy MUST NOT modify or remove an existing header field or header field value. This is particularly important when S/MIME is used. The message signature could include the caller preferences header fields, allowing the UAS to verify that, even though proxies may have added header fields, the original caller preferences were still present. 7.1 Request-Disposition Processing If the request contains a Request-Disposition header field, the server+} SHOULD execute the directives as described in Section 8.1, unless it has local policy configured to direct it otherwise. 7.2 Preference and Capability Matching A proxy compliant to this specification MUST NOT apply the preferences matching operation described here to a request unless it is the owner of the domain in the request URI, and accessing a location service that has capabilities associated with request targets. However, if it is the owner of the domain, and accessing a location service that has capabilities associated [-wth-] {+with+} request targets, it SHOULD apply the processing described in this section. Typically, this is a proxy that is using a registration database to determine the request targets. However, if a proxy knows about capabilities through some other means, it SHOULD apply the processing defined here as well. {+If it does perform the processing, it MUST do so as described below.+} The processing is described through a conversion from the syntax described in this specification to RFC 2533 syntax, followed by a matching operation and a sorting of resulting contact values. The usage of RFC 2533 syntax as an intermediate step is not required, it only serves as a useful tool to describe the behavior required of the proxy. A proxy can use any steps it likes so long as the results are identical to the ones that would be achieved with the processing described here. 7.2.1 Extracting Explicit Preferences {+J. Rosenberg et. al. [Page 18] Internet Draft SIP Caller Preferences March 2, 2003+} The first step in proxy processing is to extract explicit preferences. To do that, it looks for the [-Accept-Contact,-] {+Accept-Contact and+} Reject- Contact [-and Require-Contact-] header fields. For each value of those header fields, it [-SHOULD convert all-] {+extracts the feature parameters. These are the header field+} parameters [-except for-] {+whose name is one of+} the [-q-value-] {+base-tags (see Section 10), or whose name begins with a plus (+). The proxy converts all of those parameters+} to the syntax of RFC 2533, based on the rules in Section 11. [-If a value of the header field was not a "*", it SHOULD take the URI in that value, and add two terms to the top level conjunction: J. Rosenberg et. al. [Page 14] Internet Draft SIP Caller Preferences November 4, 2002 (uri-user=) and (uri-domain=) If the user part of the SIP URI is absent, the uri-user term is not added, only the uri-domain one. No URI parameters are used. Note that these are not "real" feature tags; they are not registered with IANA and cannot appear anywhere in actual form. They are merely added in order to perform the matching operation.-] The result will be a set of feature set predicates in conjunctive normal form, each of which is associated with one of the [-three-] {+two+} preference header fields. If there was a q parameter associated with a header field value in the Accept-Contact header field, the feature set predicate derived from that header field value is assigned a preference equal to that q value. [-7.2.2 Extracting Implicit Preferences The proxy then applies any "implicit" preferences. These preferences are ones not explicitly stated in the three-] {+If there was a req-parameter associated with a+} header [-fields, but implied by-] {+field value in+} the [-presence of other-] {+Accept-Contact+} header [-fields in-] {+field,+} the [-request. 7.2.2.1 Priority The Priority-] {+feature set predicate derived from that+} header field {+value+} is [-an indication of a caller preference - a desire to be routed-] {+said+} to {+have its require flag set. Similarly, if there was an explicit-param associated with+} a [-UA that can handle requests of the desired priority. If-] {+header field value in+} the [-request contained a Priority-] {+Accept- Contact+} header field, the [-proxy looks for feature tags with the value "priority" in all-] feature set [-predicates. If-] {+predicate derived from+} that [-feature tag-] {+header field value+} is {+said to have its explicit flag set. 7.2.2 Extracting Implicit Preferences If, and only if, the proxy did+} not [-used in-] {+find+} any {+explicit preferences in the request (because there was no Accept-Contact or Reject-Contact header field), the proxy extracts implicit preferences. These preferences are ones implied by the presence+} of {+other information in+} the [-predicates,-] {+request. First,+} the proxy creates a [-new-] {+conjunction with no terms. This conjunction represents a+} feature set [-predicate, and associates it-] {+that will be associated+} with the Accept-Contact header [-field (note-] {+field, as if it were included there. Note+} that there is no modification of the message implied - only an association for the purposes of [-processing). The new predicate looks like: (& (priority>=[numeric value of the Priority header field])) J. Rosenberg et. al. [Page 15] Internet Draft SIP Caller Preferences November 4, 2002-] {+processing. Furthermore, this feature set has its require flag set, but not its explicit flag.+} The [-numeric value of the Priority header field is obtained through the procedures described in Section 9.11. For example, if the request had a Priority header field with a value of urgent, the-] proxy [-would create-] {+then adds terms to+} the [-following predicate: (& (priority >= 3)) 7.2.2.2-] {+conjunction for the two implicit preference types below. 7.2.2.1+} Methods [-Another-] {+One+} implicit preference is the method. When a UAC sends a request with a specific method, it is an implicit preference to have the request routed only to UAs that support that method. To support this implicit preference, the proxy [-looks for feature tags with the value "methods" in all feature set predicates. If that feature tag is not used in any of the predicates, the proxy examines the predicates associated with the Require-Contact header field. If there are no predicates associated with that header field, the proxy creates a new empty feature set predicate, and associates it with the Require- Contact header field (note that there is no modification of the message implied - only an association for the purposes of processing). In this case, an empty predicate is one with a conjunction, but no terms in that conjunction yet. For all predicates associated with the Require-Contact header field (including the one which may have just been created), the proxy SHOULD add-] {+adds+} a term to the conjunction of the following form: {+J. Rosenberg et. al. [Page 19] Internet Draft SIP Caller Preferences March 2, 2003+} (methods=[method of request]) [-7.2.2.3-] {+7.2.2.2+} Event Packages For requests that establish a subscription [7], the Event header field is another expression of an implicit preference. It expresses a desire for the request to be routed only to a server than supports the given event package. To [-implement that-] {+support this+} implicit preference, the proxy [-looks for feature tags with-] {+adds a term to+} the [-value "events"-] {+conjunction of the following form: (events=[value of the Event header field]) 7.3 Constructing Contact Predicates The proxy then takes each URI+} in [-all feature-] {+the target+} set [-predicates. If that-] {+(the set of URI it is going to proxy or redirect to), and obtains its capabilities as an RFC 2533 formatted+} feature [-tag-] {+set predicate. This+} is [-not used in any of-] {+called a contact predicate. If+} the [-predicates,-] {+target URI was obtained through a registration,+} the proxy [-examines-] {+computes+} the [-predicates associated with-] {+contact predicate by extracting+} the [-Require-Contact header field. If there are no predicates associated with that-] {+feature parameters from the Contact+} header [-field,-] {+field and+} the [-proxy creates-] {+converting them to+} a [-new-] {+feature predicate. To extract the feature parameters, the proxy follows these steps: 1. Create an initial,+} empty {+list of+} feature [-set J. Rosenberg et. al. [Page 16] Internet Draft SIP Caller Preferences November 4, 2002 predicate, and associates it with-] {+parameters. 2. If+} the [-Require-Contact header field (note that there is no modification of-] {+Contact URI parameters included+} the [-message implied - only an association for-] {+"attendant", "audio", "automata", "class", "duplex", "data", "control", "mobility", "description", "events", "priority", "methods", "schemes", "application", "video", "msgserver", "language", "isfocus", "uri-user", "uri-domain" or "type" parameters, those are copied into+} the [-purposes of processing). In this case, an empty predicate is one-] {+list. 3. If any Contact URI parameter name begins+} with a [-conjunction, but no terms yet. For all predicates associated-] {+"+", it is copied into the list if the list does not already contain that name+} with the [-Require-Contact header field (including-] {+plus removed. In other words, if+} the [-one which may have just been created),-] {+"video" feature parameter is in+} the [-proxy SHOULD add a term of-] {+list,+} the [-following form: (events=[value of-] {+"+video" parameter would not be placed into+} the [-Event header field]) 7.2.2.4 Media Types Another implicit preference is for-] {+list. This conflict should never arise if+} the [-sessions that are-] {+client were compliant+} to [-be established. If a UA generates an INVITE request with a session description that includes video,-] this {+specification, since it+} is [-an implicit preference to be connected-] {+illegal+} to [-a UA that supports video. To implement this implicit preference,-] {+use+} the [-proxy looks-] {++ form+} for [-feature tags with the values "audio", "video", "application", "message", "text" or "image" in all feature set predicates. If none-] {+encoding+} of [-those-] {+a+} feature [-tags are used-] {+tag+} in [-any of-] the [-predicates,-] {+base set. If+} the [-proxy MAY create a new feature-] {+URI in the target+} set [-predicate, and associate-] {+had no feature parameters,+} it [-with the Accept-Contact header field (note-] {+is said to J. Rosenberg et. al. [Page 20] Internet Draft SIP Caller Preferences March 2, 2003 be immune to caller preference processing. This means+} that [-there-] {+the URI+} is [-no modification of-] {+removed from+} the [-message implied - only an association for-] {+target set temporarily,+} the [-purposes-] {+caller preferences processing described below is executed, and then the URI is added back in. Assuming the URI has feature parameters, they are converted to RFC 2533 syntax using the rules+} of [-processing). This-] {+Section 11. The resulting+} predicate [-has-] {+is associated with+} a [-term for each top-level media type listed in-] {+q-value. If+} the [-session description, with-] {+contact predicate was learned through+} a [-value of TRUE. For example, if-] {+REGISTER request,+} the [-request-] {+q-value+} is [-an INVITE request, with a Session Description Protocol (SDP) [19] body, where-] {+equal to+} the [-SDP contains-] {+q-value in the Contact header field parameter, else "1.0" if not specified. As+} an [-audio and a video media description,-] {+example, consider+} the [-proxy-] {+following registered Contact header field: Contact: ;audio;video;mobility="fixed"; +message="TRUE";other-param=66372; methods="INVITE,OPTIONS,BYE,CANCEL,ACK";schemes="sip,http"; uri-user="";uri-domain="example.com" This+} would [-construct-] {+be converted into+} the following predicate: (& (audio=TRUE) [-(video=TRUE)) This implicit preference is added with MAY strength, and-] {+(video=TRUE) (mobility=fixed) (message=TRUE) (| (methods=INVITE) (methods=OPTIONS) (methods=BYE) (methods=CANCEL) (methods=ACK)) (| (schemes=sip) (schemes=http)) (uri-user="user") (uri-domain="example.com")) Note that "other-param" was+} not [-SHOULD,-] {+considered a featuer parameter,+} since it [-requires the proxy to examine the body of the request. This can have performance implications, and won't always be possible. For example, if the body-] is [-encrypted,-] {+neither a base tag nor did it begin with a leading +. 7.4 Matching It is important to note that+} the proxy [-cannot examine it. 7.2.2.5 Languages-] {+does not have to know anything+} J. Rosenberg et. al. [Page [-17]-] {+21]+} Internet Draft SIP Caller Preferences [-November 4, 2002 The languages understood by-] {+March 2, 2003 about+} the [-caller is another form of implicit preference. The Accept-Language header field contains a list-] {+meaning+} of the [-languages-] {+feature tags+} that [-content should be returned in. It-] {+it+} is [-reasonable-] {+comparing in order+} to [-imply that-] {+perform+} the [-caller would like-] {+matching operation. The rules for performing+} the [-call to be routed to-] {+comparison depend on syntactic hints present in the values of each feature tag. For example,+} a [-user-] {+predicate such as: (foo>=4) implies+} that [-speaks those languages as well. To implement that implicit preference, the proxy looks for feature tags with-] the [-value "language" in all feature set predicates. If that-] feature tag {+"foo"+} is [-not used-] {+a numeric value. The matching rules+} in [-any of-] {+RFC 2533 only require an implementation to know whether+} the [-predicates,-] {+feature tag is a numeric, token, or quoted string (booleans can be treated as tokens). Quoted strings are always matched using a case- sensitive matching operation. Tokens are matched using case- insensitive matching. Numerics are matched using normal mathematical comparisons. First,+} the proxy [-creates a new feature set predicate for each value in-] {+applies+} the [-Accept-Language-] {+predicates associated with the Reject- Contact+} header [-field, and associates it-] {+field. For each contact predicate, each Reject-Contact predicate (that is, each predicate associated+} with the [-Accept-Contact-] {+Reject-Contact+} header [-field (note-] {+field) is examined. If+} that [-there-] {+Reject-Contact predicate contains a filter for a feature tag, and that feature tag+} is [-no modification of-] {+not present anywhere in+} the [-message implied - only an association-] {+contact predicate, that Reject-Contact predicate is discarded+} for the [-purposes-] {+processing+} of [-processing). Each-] {+that contact predicate. If the Reject-Contact+} predicate is [-of-] {+not discarded, it is matched to+} the [-following form: (& (language=[value-] {+contact predicate using the matching operation+} of {+RFC 2533 [2]. If+} the [-Accept-Language header field])) Furthermore, if an Accept-Language header field value had-] {+result is+} a [-q-value associated with it,-] {+match, the URI corresponding to+} that [-q-value-] {+contact predicate is discarded from the target set. The result+} is {+that Reject-Contact will only discard URIs where the UA has explicitly indicated support for the features that are not wanted. Next, the proxy applies the predicates+} associated with the [-corresponding feature set predicate. 7.3 Constructing-] {+Accept-+} Contact [-Predicates The proxy then takes-] {+header field. For+} each [-URI-] {+contact that remains+} in the target {+set, the proxy constructs a matching set, Ms. Initially, this+} set [-(the set-] {+contains all+} of [-URI it-] {+the Accept-Contact predicates. Each of those predicates+} is [-going to proxy or redirect to), and obtains its capabilities as an RFC 2533 formatted feature set predicate. This-] {+examined. It+} is [-called a contact predicate. If target URI was obtained through a registration, the proxy computes-] {+matched to+} the contact predicate [-by taking all Contact URI parameters except for the q and expires parameters, and converting them to RFC 2533 syntax-] using the [-rules-] {+matching operation+} of [-Section 8.1.-] {+RFC 2533 [2].+} If the [-contact predicate doesn't already contain a "schemes" feature tag, the proxy SHOULD add a term containing one, whose value-] {+result+} is [-equal to the scheme of-] {+not a match, and+} the [-URI. The resulting-] {+Accept-Contact+} predicate [-is associated with a q-value. If-] {+had its require flag set,+} the {+URI corresponding to that+} contact predicate [-was learned through a REGISTER request, the q-value-] is [-equal to-] {+discarded from+} the [-q-value in-] {+contact set. If+} the [-Contact header field parameter, else "1.0" if-] {+result is+} not [-specified. As an example, if-] a [-REGISTER request had-] {+match, but+} the [-following Contact URI: Contact: sip:1.2.3.4;mobility="fixed";q=0.8-] {+Accept-Contact predicate did not have its require flag set, that contact URI is not discarded from the contact set, however, the Accept-Contact predicate is+} J. Rosenberg et. al. [Page [-18]-] {+22]+} Internet Draft SIP Caller Preferences [-November 4, 2002 The proxy would compute-] {+March 2, 2003 removed from+} the [-following-] {+matching set for that contact. For each+} contact [-predicate, associating it with a q-value of 0.8: (& (mobility=fixed) (schemes=sip)) 7.4 Matching It is important to note-] that {+remains in+} the [-proxy does not have to know anything about the meaning of-] {+target set,+} the [-feature tags-] {+proxy computes a score for+} that [-it is comparing in order to perform-] {+contact against each predicate+} the {+contact's+} matching [-operation. The rules for performing-] {+set. Let+} the [-comparison depend on syntactic hints present-] {+number of terms+} in the [-values of each feature tag. For example, a-] {+Accept-Contact+} predicate [-such as: foo>=4 implies-] {+conjunction be equal to N. Each term in+} that [-the feature tag foo is-] {+predicate contains+} a [-numeric value. The matching rules in RFC 2533 only require to know whether the-] {+single+} feature [-tag is a numeric, token, quoted string, etc. First, the proxy applies the predicates associated with-] {+tag. If+} the [-Reject- Contact header field. For each-] contact [-predicate, each Reject-Contact predicate (that is, each-] predicate [-associated with the Reject-Contact header field) is examined. If that Reject-Contact predicate contains a filter for-] {+has+} a {+term containing that same+} feature tag, [-and that-] {+the score is incremented by 1/N. If the+} feature tag [-is-] {+was+} not present [-anywhere-] in the contact predicate, [-that Reject-Contact predicate is discarded for-] the [-processing-] {+score remains unchanged. Based on these rules, the score can range between zero and one. The require and explicit tags are then applied, resulting in potential modification+} of [-that contact predicate. If-] the [-Reject-Contact predicate is not discarded, it-] {+score and the target set. This process+} is [-matched to-] {+summarized in Figure 1. If the score for+} the contact predicate [-using-] {+against that Accept-Contact predicate was less than one, and+} the [-matching operation of RFC 2533 [2]. If-] {+Accept-Contact predicate had an explicit tag, if+} the [-result is-] {+predicate also had+} a [-match,-] {+require tag,+} the {+Contact+} URI corresponding to that contact predicate is [-discarded from-] {+dropped. If, however,+} the [-target set (and of course, its contact-] predicate {+did not have a require tag, the score+} is [-discarded as well).-] {+set to zero. If there was no explicit tag, the score is unchanged.+} The [-result-] {+next step+} is [-that Reject-Contact will only discard URIs where the UA has explicitly indicated support for the features that are not wanted. Next,-] {+to combine+} the [-proxy applies-] {+scores and+} the [-predicates-] {+q-values+} associated with the [-Require- Contact header field. J. Rosenberg et. al. [Page 19] Internet Draft SIP Caller Preferences November 4, 2002-] {+predicates in the matching set, to arrive at an overall caller preference, Qa.+} For {+those URIs in the target set which remain, there will be a score which indicates its match against+} each [-contact-] {+Accept- Contact+} predicate [-that remains,-] {+in the matching set. If there are M Accept-Contact predicates in the matching set, there will be M scores S1 through SM, for each contact. There will also be a preference associated with+} each [-Require-Contact-] {+Accept-Contact+} predicate [-is examined.-] {+(derived from the q-value parameter, as discussed in Section 7.2.1), X1..XM.+} The [-Require-Contact predicate-] {+caller preference, Qa,+} is [-matched to-] {+computed as shown in Figure 2. Note that in+} the [-contact predicate using-] {+limit as all Si go to zero, Qa equals+} the [-matching operation-] {+arithmetic average+} of [-RFC 2533 [2].-] {+Xi. This algorithm was chosen carefully so as to exhibit certain properties: o+} If [-the result-] {+Si+} is [-not-] {+1 for i=j, and zero for all other i, Qa=Xi. In other words, if+} a [-match,-] {+contact predicate matches one of+} the [-URI corresponding-] {+Accept- Contact predicates with a score of one (referred to as an explicit match), and all others match with a score of zero (referred+} to {+as an implicit match), the caller's preference equals the q-value of+} that [-contact predicate-] {+predicate. J. Rosenberg et. al. [Page 23] Internet Draft SIP Caller Preferences March 2, 2003 o If Si+} is [-discarded from-] the [-target-] {+same for all predicates in the matching+} set, [-as-] {+Qa+} is {+equal to the average of the q-values for the predicates. o If+} the contact predicate [-itself. For each contact predicate that remains, each Accept-Contact predicate is examined. The-] {+matches only one+} Accept-Contact [-predicate-] {+predicate, Qa+} is [-matched-] {+equal+} to the [-contact predicate using the matching operation-] {+q-value of that predicate, independent+} of [-RFC 2533 [2]. If-] the [-result-] {+score. The final step+} is [-a match,-] {+to combine+} the [-URI associated-] {+overall caller preference for the contact (Qa)+} with the {+q-value provided for that+} contact [-predicate is considered a candidate URI. The set of Accept-Contact predicates which matched-] {+by+} the [-contact predicate is called its matching set.-] {+callee (which we denote as Qb).+} The [-q-value-] {+proxy can use any averaging mechanism at its disposal, prefentially treating the callers preference and the callee's preference as policy dictates. In the absence+} of [-URIs from-] {+policy indicating otherwise,+} the [-target set-] {+two values+} are [-then modified-] {+arithmetically averaged. This results in an overall q-value+} for {+that contact, Qo, equal to: Qa + Qb Qo = --------- 2 At+} this [-transaction only, in order to incorporate the caller's preferences. If the-] {+point, any+} URI [-in-] {+that were removed from+} the target set [-is not a candidate URI, its q-value-] {+because they were immune from caller preferences are added back in, and Qo for that URI+} is set to [-zero. If the URI is a candidate URI,-] its {+original q-value, or 1.0 if there was no+} q-value [-is combined with those from-] {+specified. If there were no URIs in+} the [-matching set. This document does not prescribe a specific algorithm for combining q-values. Among many possibilities, a server MAY-] {+target+} set {+after+} the [-q-value to the average-] {+application+} of the [-original value specified-] {+processing+} in [-the registration,-] {+this section,+} and the [-average q-value amongst-] {+caller preferences were based on implicit preferences (Section 7.2.2),+} the [-predicates-] {+processing+} in [-the matching set. This gives equal weight to caller-] {+this section is discarded,+} and [-callee preferences. The only requirement for-] the [-combining process is that if a-] {+original+} target [-URI has a q-value of q1, and-] {+set, along with their original q-values, is used. This handles+} the [-q values amongst-] {+case where implicit preferences for+} the [-predicates-] {+method or event packages resulted+} in the [-matching set are q2,q3,..qn, the combined q value, qm, must satisfy: MIN(q1,q2,q3,..qn) <= qm <= MAX(q1,q2,q3,..,qn) Note that this preference computation only determines the ordering-] {+elimination+} of [-request attempts, so that-] {+all potential targets. By going back to+} the [-properties of-] {+original target set, those URIs will be tried, and result in+} the [-preference computation are-] {+generation+} of [-secondary importance.-] {+a 405 or 489.+} The [-q- value ordering provides only limited flexibility to indicate, for example, that a particular parameter is more important than another one-] {+UAC can then use this information to try again,+} or [-that combinations of two parameters should be weighed heavily. If-] {+report+} the [-server proxies,-] {+error to+} the [-target set is then sorted according-] {+user. Without reverting+} to the [-updated q-value. Processing from this point depends on-] {+original target set,+} the [-configuration-] {+UAC would see a 480 response,+} and [-policy-] {+have no knowledge+} of {+why their request failed. Of course,+} the [-server. If-] {+target set can also be empty after+} the [-server elects to do-] {+application of explicit preferences. This will result in the generation of+} a [-sequential proxy, it SHOULD try-] {+480 by+} the [-highest q-value contact entry first, trying addresses with decreasing q-values as each attempt-] {+proxy. This behavior is acceptable, and indeed, desirable in the case of explicit preferences. When the caller makes an explicit preference,+} J. Rosenberg et. al. [Page [-20]-] {+24]+} Internet Draft SIP Caller Preferences [-November 4, 2002 fails. If the server elects to do a parallel proxy,-] {+March 2, 2003 T +----------> DROP Contact | | / \ / \ T / \ F +---->/require\------> Set score=0 | \ / | \ / / \ \ / / \ \/ score<1 / \ +-------> /explicit----> Score unchanged | \ / F | \ / / \ \ / / \ \/ +--------+ / \ -->|Compute |--> /Score \ --------> Score unchanged | Score | \ / score=1 +--------+ \ / \ / \/ Figure 1: Score Computation J. Rosenberg et. al. [Page 25] Internet Draft SIP Caller Preferences March 2, 2003 / / / | 0, if M=0 | | | | M | ------ | \ | \ | / Si*Xi | / Qa = | ------ | i=1 | if M>0 | ------------------ | | M | ------ | \ | \ | / Si | / | ------ \ i=1 \ \ Figure 2: Computation of Qa+} it [-SHOULD group contact entries with "close" q-values together, and-] {+is agreeing that its request might fail because of a preference mismatch. One might+} try {+to return an error indicating+} the [-group with the highest q-value first, then-] {+capabilities of+} the [-group with-] {+callee, so that+} the [-next lowest q-values, and-] {+caller could perhaps try again. However, doing+} so [-on. The precise method of-] {+results in+} the [-grouping is left-] {+leaking of potentially sensitive information+} to the [-implementor. A reasonable choice is to round each q-value to-] {+caller without authorization from+} the [-nearest tenth,-] {+callee,+} and [-group those-] {+therefore this specification does not provide a means for it. Any proxy processing that takes the q-values as inputs (for example, a forking operation as described in Section 16.6 of RFC 3261 [1]) would use Qo instead of the original q-value associated+} with the [-same-] {+contact, for this specific transaction only. To avoid preferring one J. Rosenberg et. al. [Page 26] Internet Draft SIP Caller Preferences March 2, 2003 contact to another because of a relatively small difference in their overall q-value, it is RECOMMENDED that the values be+} rounded [-value.-] {+to the nearest tenth before they are used by the proxy.+} If a proxy server is recursing, it [-SHOULD apply-] {+applies+} the caller preferences to the Contact header fields returned in the redirect responses. Any [-target-] URI remaining after the application of caller preferences [-SHOULD be-] {+are+} added to the [-list of untried addresses.-] {+proxy's target set if it is not already in the target set.+} This list is then resorted based on q values. The server uses this list for subsequent proxy operations. If the server is redirecting, it [-SHOULD return-] {+returns+} all entries in the target set, including a q-value {+of Qo+} for each {+Contact URI+} as obtained through the [-combining process.-] {+process above.+} This [-SHOULD include-] {+includes+} any URI with a zero q-value. {+However, it MUST NOT include the feature parameters for the entries in the target set.+} If {+it did,+} the {+upstream proxy+} server [-is executing any other type of policy, as-] {+would apply the same caller preferences once more, resulting in+} a [-general guideline, it SHOULD prefer target URI with higher q values than those with lower q values. 8 Header Field Definitions This specification defines four new header fields - Accept-Contact, Reject-Contact, Require-Contact and Request-Disposition. Table 1 is an extension-] {+double application+} of [-Tables 2 and 3-] {+those preferences. If the redirect server does wish to include the feature parameters+} in [-[1] for-] the [-Accept- Contact, Reject-Contact, Require-Contact and Request-Disposition-] {+Contact+} header [-fields. The column "INF" is for-] {+field, it MUST redirect using+} the [-INFO method [8], "PRA" is for-] {+original target set and original q-values, before+} the [-PRACK method [9], "UPD"-] {+application of caller preferences. It+} is [-for-] the [-UPDATE method [10], "SUB" is for-] {+usage of these modified q-values that allows+} the [-SUBSCRIBE method [7], and "NOT"-] {+caller preferences to be taken into account, while at the same time giving the proxy flexibility in how it processes the request. 7.4.1 Example Consider the following example, which+} is {+contrived but illustrative of the various components of the matching process. There are five registered Contacts+} for {+sip:user@example.com. They are: Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.1 Contact: sip:u2@h.example.com;audio="FALSE"; methods="INVITE";msgserver;q=0.2 Contact: sip:u3@h.example.com;audio;msgserver; methods="INVITE";video;q=0.3 Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.4 Contact: sip:u5@h.example.com;q=0.5 an INVITE sent to sip:user@example.com contained+} the [-NOTIFY method [7]. Header field where proxy ACK BYE CAN INV OPT REG PRA UPD SUB NOT INF _____________________________________________________________________________ Accept-Contact R r o o o o o - o o o o o Reject-Contact R r o o o o o - o o o o o Require-Contact R r o o o o o - o o o o o Request-Disposition R r o o o o o o o o o o o Table 1: Accept-Contact, Reject-Contact, Require-Contact and Request-Disposition-] {+following caller preferences+} header [-fields 8.1 Request Disposition-] {+fields:+} J. Rosenberg et. al. [Page [-21]-] {+27]+} Internet Draft SIP Caller Preferences [-November 4, 2002-] {+March 2, 2003 Reject-Contact: *;msgserver;video Accept-Contact: *;audio;require;q=0.5, *;video;explicit;q=0.4, *;methods="BYE";class="business";q=1.0 There are no implicit preferences in this example, because explicit preferences are provided.+} The [-Request-Disposition header field specifies-] {+proxy first removes u5 from the target set, since it is immune from+} caller preferences [-for how a server should process-] {+processing. Next, the proxy processes the Reject-Contact header field. It is+} a [-request. Its value-] {+match for all four remaining contacts, but only an explicit match for u3. Thats because u3 is the only one that explicitly indicated support for video, and explicitly indicated it+} is a [-list-] {+messaging server. So, u3 gets discarded, and the others remain. Next, each+} of [-tokens,-] {+the remaining three contacts is compared against+} each of [-which specifies a particular directive. Its syntax-] {+the three Accept-Contact predicates. u1+} is [-specified in Section 10. Note that-] a [-compact form, using the letter d, has been defined. There can only be one value of-] {+match to all three, earning+} a [-directive per header field (i.e., you can't have both "proxy"-] {+score of 1.0 for the first two predicates,+} and [-"redirect"-] {+0.5 for the third (the methods feature tag was present+} in the [-same Request-Disposition header field). When-] {+contact predicate, but+} the [-caller specifies a directive,-] {+class tag was not). u2 doesn't match+} the [-server SHOULD treat it as-] {+first predicate. Because that predicate has+} a [-hint, not as-] {+require tag, u2 is discarded. u4 matches the first predicate, earning+} a [-requirement and MAY ignore-] {+score of 1.0. u4 does match+} the [-directive. The directives have-] {+second predicate, but since+} the [-following semantics: proxy-directive: This directive indicates whether-] {+match is not explicit (the score is 0.0, in fact),+} the [-caller would like each server-] {+score is set+} to [-proxy or redirect. If-] {+zero (it was already zero, so nothing changes). u4 does not match+} the [-server is incapable-] {+third predicate. At this point, u1 and u4 remain. u1 matched all three Accept-Contact predicates, so that its matching set contains all three, with scores+} of [-performing-] {+1, 1, and 0.5. u4 matches+} the [-requested directive, it SHOULD ignore it. cancel-directive: This directive indicates whether-] {+first two predicates, with scores of 1.0 and 0.0. Qa for u1 is then computed as: 1.0*0.5 + 1.0*0.4 + 0.5*1.0 --------------------------- = 0.56 1.0 + 1.0 + 0.5 Qa for u4 is then computed as: J. Rosenberg et. al. [Page 28] Internet Draft SIP Caller Preferences March 2, 2003 1.0*0.5 + 0.0*0.4 ------------------ = 0.5 1.0 + 0.0 Qo for u1 is+} the [-caller would like each proxy server to send a CANCEL request downstream in response to a 200 OK from-] {+average of 0.56 and+} the [-downstream server (which-] {+registered q-value of 0.1, which equals 0.33. Qo for u4+} is the [-normal mode-] {+average+} of [-operation, making it somewhat redundant), or whether this function should be left to-] {+0.5 and+} the [-caller. If a proxy receives a request with this parameter set-] {+registered q-value of 0.4, which equals 0.45. Rounding these+} to [-"no-cancel", it SHOULD NOT CANCEL any outstanding-] {+the nearest tenth, Qo for u1 is 0.3 and Qo for u4 is 0.5. Now, u5 is added back in. It retains its original q-value of 0.5. Since its q-value matches that of u4, both u4 and u5 would be tried in parallel. Should both fail, u1 would be tried. 8 Header Field Definitions This specification defines three new header fields - Accept-Contact, Reject-Contact, and Request-Disposition. Tables 1 and 2 are an extension of Tables 2 and 3 in [1] for the Accept-Contact, Reject-Contact and Request-Disposition header fields. The column "INF" is for the INFO method [8], "PRA" is for the PRACK method [9], "UPD" is for the UPDATE method [10], "SUB" is for the SUBSCRIBE method [7], "NOT" is for the NOTIFY method [7], and "MSG" is for the MESSAGE method [3]. Header field where proxy ACK BYE CAN INV OPT REG _________________________________________________________ Accept-Contact R ar o o o o o - Reject-Contact R ar o o o o o - Request-Disposition R ar o o o o o o Table 1: Accept-Contact, Reject-Contact and Request-Disposition header fields 8.1 Request Disposition The Request-Disposition header field specifies caller preferences for how a server should process a request. Its value is a list of tokens, each of which specifies a particular directive. Its syntax is specified in Section 10. Note that a compact form, using the letter d, has been defined. The directives are grouped into types. There can only be one directive of each type per request (i.e., you can't have both "proxy" and "redirect" in the same Request-Disposition header J. Rosenberg et. al. [Page 29] Internet Draft SIP Caller Preferences March 2, 2003 Header field where proxy PRA UPD SUB NOT INF MSG _________________________________________________________ Accept-Contact R ar o o o o o o Reject-Contact R ar o o o o o o Request-Disposition R ar o o o o o o Table 2: Accept-Contact, Reject-Contact, and Request-Disposition header fields field). When the caller specifies a directive, the server SHOULD honor that directive. The following types of directives are defined: proxy-directive: This type of directive indicates whether the caller would like each server to proxy ("proxy") or redirect ("redirect"). cancel-directive: This type of directive indicates whether the caller would like each proxy server to send a CANCEL request downstream ("cancel") in response to a 200 OK from the downstream server (which is the normal mode of operation, making it somewhat redundant), or whether this function should be left to the caller ("no-cancel"). If a proxy receives a request with this parameter set to "no- cancel", it SHOULD NOT CANCEL any outstanding+} branches on receipt of a 2xx. However, it would still send CANCEL on any outstanding branches on receipt of a 6xx. fork-directive: This {+type of+} directive indicates whether a proxy should fork a [-request,-] {+request ("fork"), or proxy to only a single address ("no-fork"). If the server is requested not to fork, the server SHOULD proxy the request to the "best" address (generally the one with the highest q-value). The directive is ignored if "redirect" has been requested. recurse-directive: This type of directive indicates whether a proxy server receiving a 3xx response should send requests to the addresses listed in the response ("recurse"),+} or {+forward the list of addresses upstream towards the caller ("no-recurse"). The directive is ignored if "redirect" has been requested. parallel-directive: For a forking proxy server, this type of directive indicates whether the caller would like the proxy J. Rosenberg et. al. [Page 30] Internet Draft SIP Caller Preferences March 2, 2003 server to+} proxy {+the request+} to {+all known addresses at once ("parallel"), or go through them sequentially, contacting the next address+} only {+after it has received+} a [-single address.-] {+non-2xx or non-6xx final response for the previous one ("sequential"). The directive is ignored if "redirect" has been requested. queue-directive: If the called party is temporarily unreachable, e.g., because it is in another call, the caller can indicate that it wants to have its call queued ("queue") or rejected immediately ("no-queue").+} If the {+call is queued, the+} server {+returns "182 Queued". A queued call can be terminated as described in [1]. Example: Request-Disposition: proxy, recurse, parallel The set of request disposition directives+} is [-requested-] {+purposefully+} not {+extensible. This is+} to [-fork,-] {+avoid a proliferation of new extensions to SIP that are "tunneled" through this header field. 8.2 Accept-Contact and Reject-Contact Header Fields The syntax for these header fields is described in Section 10. A compact form, with+} the [-server SHOULD proxy-] {+letter a, has been defined for+} the [-request-] {+Accept- Contact header field, and with the letter j for the Reject-Contact header field. The enc-feature-tag is an encoded version of any valid feature tag, a number of which are applicable+} to {+SIP, and defined in Section 9. Note that string-value uses+} the [-"best" address (generally-] {+qdtext production from RFC 3261. This production allows UTF-8 characters. This is in contrast to RFC 2533, which only allows ASCII characters in quoted strings. Usage of UTF-8 here is permissible since these values are never compared except using case sensitive matching rules. 8.3 Contact Header Field This specification extends+} the [-one with-] {+Contact header field. In particular, it allows for+} the [-highest q value). The directive-] {+Contact header field parameters to include feature-param, whose BNF is described in Section 10. Feature-param+} is [-ignored if "redirect" has been requested. recurse-directive: This directive indicates whether-] a [-proxy server receiving-] {+feature parameter that describes+} a [-3xx response should send requests to the addresses listed in the response (i.e., recurse), or forward the list-] {+feature+} of [-addresses upstream towards-] the [-caller. The directive is ignored if "redirect" has been requested. parallel-directive: For a forking proxy server, this directive indicates whether-] {+UA associated with+} the [-caller would like-] {+URI in+} the [-proxy server-] {+Contact header field. Feature parameters are identifiable because they either belong+} to [-proxy-] the [-request to all-] {+well+} known [-addresses at once,-] {+set of base feature tags,+} or [-go through them sequentially, contacting the next address only after it has received-] {+they begin with+} a [-non-2xx or non-6xx final response for the previous one. The directive is ignored if-] {+plus sign.+} J. Rosenberg et. al. [Page [-22]-] {+31]+} Internet Draft SIP Caller Preferences [-November 4, 2002 "redirect" has been requested. queue-directive: If-] {+March 2, 2003 9 Media Feature Tag Definitions This specification defines an initial set of media feature tags for use with this specification. New media feature tags MAY be registered with IANA, based on+} the [-called party is temporarily unreachable, e.g., because it is in another call,-] {+process defined for feature tag registrations [5]. This section also serves as+} the [-caller can indicate that it wants-] {+IANA registration for these feature tags. Any registered feature tags MAY be used with this specification. However, several existing ones appear+} to [-have its call queued rather than rejected immediately. If-] {+be particularly applicable. These include the language feature tag [11], which can be used to specify+} the [-call is queued,-] {+language of+} the [-server returns "182 Queued". A queued call-] {+human or automata represented by the UA, and the type feature tag [12], which+} can be [-terminated as described in [1]. Example: Request-Disposition: proxy, recurse, parallel The set of request disposition directives is purposefully not extensible. This is-] {+used+} to [-avoid a proliferation-] {+specify the MIME types+} of [-new extensions to SIP that are "tunnelled" through this header field. 8.2 Accept-Contact, Reject-Contact, and Require-Contact Header Fields The syntax for these header fields is described in Section 10. A compact form, with-] the [-letter a, has been defined for-] {+media formats supported by+} the [-Accept- Contact header field, and with-] {+UA. However,+} the [-letter j for-] {+usage of+} the [-Reject-Contact header field. The feature-tag is any valid-] {+audio, video, application, data and control+} feature [-tag, a number-] {+tags (each+} of which [-are applicable to SIP, and-] {+indicate a media type, as+} defined in [-Section 9. Note that string-value uses the qdtext production from-] RFC [-3261. This production allows UTF-8 characters. This is in contrast-] {+2327 [13] supported by the UA) are preferred+} to [-RFC 2533, which only allows ASCII characters in quoted strings. Usage of UTF-8 here-] {+indicating support for specific media formats. When the type feature tag+} is [-permissible since these values are never compared except using case sensitive matching rules. 8.3 Contact Header Field This specification extends-] {+present, there SHOULD also be a feature tag present for+} the [-Contact header field.-] {+its top-level MIME type with a value of TRUE.+} In [-particular,-] {+other words, if a UA indicates in a registration that it supports the video/H263 MIME type, it should also indicate that+} it [-allows for the Contact header field parameter-] {+supports video generally: Contact: sip:192.0.2.1;type="video/H263";video="TRUE" If a new SDP media type were+} to [-include tag-set, whose BNF is described in Section 10. Tag-set is-] {+be defined, such as "message",+} a [-set of-] {+new+} feature [-parameters that describes-] {+tag registration SHOULD be created for it. The name of+} the feature [-set-] {+tag MUST equal that+} of the [-UA associated with-] {+media type, unless there is an unlikely naming collision between+} the [-URI in-] {+new media type and an existing feature tag registration. As a result of this, implementations can safely construct caller preferences and callee capabilities for+} the [-Contact header field. It-] {+new media type before it+} is [-important to note that-] {+registered, as long as+} there is no [-way to differentiate, by syntax, Contact parameters that are part-] {+naming conflict. If a new media feature tag is registered with the intent+} of [-tag-set or just other extensions. It turns out-] {+using+} that {+tag with+} this [-does not matter. If a proxy should mistakenly take a contact parameter used by another extension, and assume it-] {+specification, the registration+} is {+done for the unencoded form of the tag (see Section 11). In other words, if+} a {+new+} feature {+tag "foo" is registered, the IANA registration would be for the tag "foo" and not "+foo". When that+} parameter [-when its not,-] {+is used within the Contact, Accept-Contact and Reject-Contact header fields,+} it [-will-] {+would+} be [-ignored by-] {+encoded using its + form. 9.1 Attendant+} J. Rosenberg et. al. [Page [-23]-] {+32]+} Internet Draft SIP Caller Preferences [-November 4, 2002 the matching algorithm unless the same parameter appears in-] {+March 2, 2003 Media feature tag name: attendant ASN.1 Identifier: New assignment by IANA. Summary of+} the [-Accept-Contact or Reject-Contact header fields. However, it won't ever appear in these header fields, since those header fields only ever contain-] {+media+} feature [-parameters, and-] {+indicated by this tag: This feature tag indicates that+} the [-parameter-] {+device+} is [-not actually a feature parameter. 9 Media Feature Tag Definitions This specification defines-] an [-initial set-] {+automated or human attendant that will answer if the actual user+} of [-media feature tags-] {+the device is not available. Values appropriate+} for use with this [-specification. New media-] feature [-tags MAY be registered with IANA, based on the process defined for-] {+tag: Boolean. The+} feature tag [-registrations [4].-] {+is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:+} This [-section also serves-] {+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 has an auto-attendant feature. Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with+} the [-IANA registration for these-] {+RFC number of this specification.]] 9.2 Audio Media+} feature [-tags. Any registered-] {+tag name: audio ASN.1 Identifier: New assignment by IANA. Summary of the media+} feature [-tags MAY be used-] {+indicated by this tag: This feature tag indicates that the device supports audio as a media type. Values appropriate for use+} with this [-specification. However, several existing ones appear to be particularly applicable. These include-] {+feature tag: Boolean. The feature tag is intended primarily for use in+} the [-language-] {+following applications, protocols, services, or negotiation mechanisms: This+} feature tag [-[11], which-] {+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 [-be used-] {+support audio. Related standards or documents: RFC XXXX [[Note+} to [-specify-] {+IANA: Please replace XXXX with+} the [-language-] {+RFC number+} of [-the human or automata represented by the UA, and the type-] {+this specification.]] 9.3 Application J. Rosenberg et. al. [Page 33] Internet Draft SIP Caller Preferences March 2, 2003 Media+} feature tag [-[12], which can be used to specify the MIME types-] {+name: application ASN.1 Identifier: New assignment by IANA. Summary+} of the media [-formats supported-] {+feature indicated+} by [-the UA. However, the usage of the audio, video, application, message, text and image-] {+this tag: This+} feature [-tags (each of which indicate-] {+tag indicates that the device supports application as+} a [-top level-] media [-type supported by the UA)-] {+type. This feature tag exists primarily for completeness. Since so many MIME types+} are [-preferred to-] {+underneath application,+} indicating {+the ability to+} support [-for specific media formats. When-] {+applications provides little useful information. In most cases,+} the {+concrete MIME+} type {+is a better parameter to use in a predicate representing a preference. Values appropriate for use with this feature tag: Boolean. The+} feature tag is [-present, there SHOULD also be a-] {+intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This+} feature tag [-present-] {+is most useful in a communications application,+} for {+describing+} the [-its top-level MIME type with-] {+capabilities of+} a [-value-] {+device, such as a phone or PDA. Examples+} of [-TRUE. In other words, if-] {+typical use: Routing+} a [-UA indicates in-] {+call to+} a [-registration-] {+phone+} that [-it-] {+can+} supports {+gaming application. Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with+} the [-video/H263 MIME type, it should also indicate that it supports video generally: Contact: sip:1.2.3.4;type="video/H263";video="TRUE" 9.1 Attendant-] {+RFC number of this specification.]] 9.4 Data+} Media feature tag name: [-attendant-] {+data+} ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: This feature tag indicates that the device [-is an automated or human attendant that will answer if the actual user of the device is not available.-] {+supports data as a media type.+} Values appropriate for use with this feature tag: Boolean. [-J. Rosenberg et. al. [Page 24] Internet Draft SIP Caller Preferences November 4, 2002-] 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 [-has an auto-attendant feature.-] {+can supports a data streaming application. J. Rosenberg et. al. [Page 34] Internet Draft SIP Caller Preferences March 2, 2003+} Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.2 Audio-] {+9.5 Control+} Media feature tag name: [-audio-] {+control+} ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: This feature tag indicates that the device supports [-audio-] {+control+} as a [-MIME-] 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.-] {+supports a floor control application.+} Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.3-] {+9.6+} Automata Media feature tag name: automata ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: The automata feature tag is a boolean value that indicates whether the UA represents an automata (such as a voicemail server, conference server, or recording device) or a human. Values appropriate for use with this feature tag: Boolean. TRUE [-J. Rosenberg et. al. [Page 25] Internet Draft SIP Caller Preferences November 4, 2002-] 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: Choosing to communicate with a message {+J. Rosenberg et. al. [Page 35] Internet Draft SIP Caller Preferences March 2, 2003+} recording device instead of a user. Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.4-] {+9.7+} Class Media feature tag name: class ASN.1 Identifier: New assignment by IANA. 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 XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.5-] {+9.8+} Duplex Media feature tag name: duplex ASN.1 Identifier: New assignment by IANA. [-J. Rosenberg et. al. [Page 26] Internet Draft SIP Caller Preferences November 4, 2002-] Summary of the media feature indicated by this tag: The duplex media feature tag lists 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: {+J. Rosenberg et. al. [Page 36] Internet Draft SIP Caller Preferences March 2, 2003+} 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 XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.6 Image-] {+9.9 Mobility+} Media feature tag name: [-image-] {+mobility+} ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: [-This-] {+The mobility+} feature tag indicates [-that-] {+whether+} the device [-supports image as a MIME media type.-] {+is fixed, wireless, or somewhere in-between.+} Values appropriate for use with this feature tag: [-Boolean.-] {+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.+} J. Rosenberg et. al. [Page [-27]-] {+37]+} Internet Draft SIP Caller Preferences [-November 4, 2002 Examples of typical use: Routing a call to a phone that can support image transfer.-] {+March 2, 2003+} Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.7 Message-] {+9.10 Description+} Media feature tag name: [-message-] {+description+} ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: [-This-] {+The description+} feature tag [-indicates that the device supports message as-] {+provides+} a [-MIME media type.-] {+textual description of the device.+} Values appropriate for use with this feature tag: [-Boolean.-] {+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: [-Routing-] {+Indicating that+} a [-call to-] {+device is of+} a [-phone that can support messaging.-] {+certain make and model.+} Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.8 Mobility-] {+9.11 Event Packages+} Media feature tag name: [-mobility-] {+events+} ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: The [-mobility feature-] {+event packages [7] supported by a SIP UA. The values for this+} tag [-indicates whether-] {+equal+} the [-device is fixed, wireless, or somewhere in-between.-] {+event package names that are registered by each event package.+} Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include: [-fixed:-] {+presence: SIP event package for for user presence [25]. winfo: SIP event package for watcher information [26]. refer:+} The [-device is wired. mobile:-] {+SIP REFER event package [27]. J. Rosenberg et. al. [Page 38] Internet Draft SIP Caller Preferences March 2, 2003 dialog:+} The [-device is wireless.-] {+SIP dialog event package [28]. conference: The SIP conference event package [29]. reg: The SIP registration event package [30]. message-summary: The SIP message summary event package [31].+} The feature tag is intended primarily for use in the following [-J. Rosenberg et. al. [Page 28] Internet Draft SIP Caller Preferences November 4, 2002-] 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-] {+server that supports the message waiting event package, such as+} a [-desktop phone.-] {+voicemail server [31].+} Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.9 Description-] {+9.12 Priority+} Media feature tag name: [-description-] {+priority+} ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: The [-description-] {+priority+} feature tag [-provides a textual description-] {+indicates the call priorities the device is willing to handle. A value+} of {+X means that+} the [-device.-] {+device is willing to take requests with priority X and higher.+} Values appropriate for use with this feature tag: [-String with an equality relationship.-] {+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 J. Rosenberg et. al. [Page 39] Internet Draft SIP Caller Preferences March 2, 2003 emergency calls.+} 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-] {+Choosing to communicate with the emergency cell phone+} of a [-certain make and model.-] {+user.+} Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.10 Event Packages-] {+9.13 Methods+} Media feature tag name: [-events-] {+methods+} ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: The [-event packages [7]-] {+methods (note the plurality) feature tag indicates the SIP methods+} supported by [-a SIP-] {+this+} UA. [-The values for-] {+In+} this [-tag equal-] {+case, "supported" means that+} the [-event package names-] {+UA can receive requests with this method. In+} that [-are registered by each event package.-] {+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 include: INVITE: The SIP INVITE method [1]. ACK: The SIP ACK method [1]. BYE: The SIP BYE method [1]. CANCEL: The SIP CANCEL method [1]. OPTIONS: The SIP OPTIONS method [1]. REGISTER: The SIP REGISTER method [1]. INFO: The SIP INFO method [8]. UPDATE: The SIP UPDATE method [10]. SUBSCRIBE: The SIP SUBSCRIBE method [7].+} J. Rosenberg et. al. [Page [-29]-] {+40]+} Internet Draft SIP Caller Preferences [-November 4, 2002 equality relationship. Typical values include: presence: SIP event package for for user presence [20]. winfo: SIP event package for watcher information [21]. refer: The SIP REFER event package [22]. dialog: The SIP dialog event package [23]. conference:-] {+March 2, 2003 NOTIFY:+} The SIP [-conference event package [24]. reg:-] {+NOTIFY method [7]. PRACK:+} The SIP [-registration event package [25]. message-summary:-] {+PRACK method [9]. MESSAGE:+} The SIP [-message summary event package [26].-] {+MESSAGE method [3].+} 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-] {+presence application on+} a [-voicemail server [26].-] {+PC, instead of a PC phone application.+} Related standards or documents: RFC XXXX [[Note to IANA: Please replace XXXX with the RFC number of this specification.]] [-9.11 Priority-] {+9.14 SIP Extensions+} Media feature tag name: [-priority-] {+sip-extensions+} ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: The [-priority-] {+sip- extensions+} feature tag [-indicates-] {+is a list of SIP extensions (each of which is defined by an option-tag registered with IANA) that are understood by+} the [-call priorities-] {+UA. Understood, in this context, means that+} the [-device is willing to handle.-] {+option tag would be included in a Supported header field in a request.+} Values appropriate for use with this feature tag: [-An integer. Each integral value corresponds to one of the possible values-] {+Token with an equality relationship. Values include: 100