Subject: [Sip] an update to caller prefs

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Nov 2002 08:28:03 -0500

Folks,

As you probably noticed, I posted an update to the caller prefs spec. 
There were a lot of changes between this rev and the last, as the issues 
of rfc2533 integration get sorted out. Below you will find a list of 
changes.

I quickly found that figuring out the "right thing" in terms of behavior 
was difficult without some concrete use cases to motivate it. As a 
result, I worked with Paul Kyzivat to put together some use cases for 
caller prefs. The result is a work-in-progress I-D that I did not submit 
yet, but might be useful for the group to take a look at in order to 
understand some of whats in callerr prefs:

http://www.jdrosen.net/papers/draft-rosenberg-sip-callerprefs-usecases-0a.txt

Paul and I will be updating this and then submit after the moratorium.

I will be sending some separate emails on the various open issues in the 
draft.

-Jonathan R.

Changes from -06:

* changed the priority attribute from an ordered token to an integer, by
mapping values of the SIP Priority header field to integers. This
is needed because, despite the text in RFC 2506, RFC 2533 does not actually
support tokens with an ordered relationship. Thats a good thing, since
if it did, a proxy would need to know about the attribute in order to
perform the matching operation. With an integral value, it doesn't need to.

* requested IANA to assign ASN.1 values for the various attributes. This
was done per Graham Klyne's recommendation. Even though we don't need
them, they would allow other ASN.1 based protocols to use these attributes.

* In rfc2533, feature tag values can be either quoted or not. When 
quotes are
present, it means that the value is to be compared CS, and when not
present, CI. We need to provide a similar clue to proxies, so they can
determine whether an attribute value is to be compared CI or CS. We
can't use quoted strings for that, since each contact parameter value is
already surrounded by quoted strings. So, a pair of angle brackets <>
is now used to indicate a CS comparison.

* clarified that a proxy doesn't need to know anything about the
feature tags in order to properly perform the matching operation. I
hadn't figured out how this was supported in rfc2533, but after a
discussion with Graham at ietf 54, I now understand. The following
text was added to summarize the basic idea:

--
It is important to note that the proxy does not have to know anything
about the meaning of the feature tags that it is comparing. The rules
for performing the comparison depend on syntactic hints present in the
values of each feature tag. For example, a predicate such as:

\begin{verbatim}
foo>=4
\end{verbatim}

implies that the feature tag foo is a numeric value. The matching
rules in RFC 2533 only require to know whether the feature tag is a
numeric, token, quoted string, etc.
--

* pointed out in IANA considerations section that the registrations
are meant for the IETF tree.

* added left and right angle brackets to grammar for the string-value
feature tags.

* noted that the string value feature tags in caller prefs support
UTF-8 strings, whereas RFC 2533 allows only US-ASCII. Explicitly
pointed out that this is NOT a problem, since these values are only
compared using CS rules. We got burned in bis when it was not
explicitly stated that we weren't ever trying to do CI matching on
arbitrary utf-8 header field values.

* explicitly indicated that feature tags are from any of the
registration trees defined in rfc 2506. THis includes the URI tree,
which allows for vendor-specific feature tags. The usage of the URI
tree for this purpose is explicitly called out.

* indicated that when a caller prefs parameter and a header can
indicate the same capability in a dialog-establishing message, the
header takes precedence. For example, the methods parameter vs. the
Allow header. If both are present, Allow is used.

* removed the media feature tag (whcih indicated the top level MIME
types supported by the UA), and added separate feature tags for audio,
video, message, application, text and image, each as a separate
boolean tag. So, if a device can do audio and video, its registration
might be like:

Contact: sip:1.2.3.4;audio="TRUE";video="TRUE"

The benefit of this, as discussed at IETF 54, is that the
Accept-Contact header can explicitly ask for things like "route this
call to a device that does BOTH audio and video". This kind of split
is generally needed whenever you want to ask for a UA that supports
multiple values of a single feature tag.

* added support for an implicit preference for media types, by
examining the SDP in an INVITE. SO, for example, if the SDP has two m
lines, one audio, one video, the proxy can treat it as if there was an
Accept-Contact header with audio=TRUE and video=TRUE in it. This is
done with MAY strenth, since I don't want to force proxies to look at
bodies.

* removed the "features" attribute, and added a separate boolean for
voicemail and for attendant. This is because the features tag said its
values are orthogonal. This orthogonality implies that they should be
separate features. Also, clarified that when you say this:

Contact: sip:1.2.3.4;voicemail="TRUE"

in a REGISTER, it does NOT mean that this is a phone that will fall
back to voicemail on no answer - it means that this device *IS* a
voicemail server. That allows a caller to very explicitly request
thigns like "dont route this call to voicemail" - a very, very, very
handy thing IMHO.

* added text recommending that if a UA registers support for a
specific MIME type (such as video/h263), it should also register
support for the top level MIME type (video=TRUE).

* changed the BNF for the feature tag values from token to
token-nobang, which is the same as token but without the !. This is
necessary to avoid ambiguity over whether the ! is a negation operator
or part of the feature tag value.

* the negation operator used to apply to the entire disjunction. Now,
it applies to an individual element. That is:

Accept-Contact:*;duplex="!half,send"

used to mean:
(! (| (duplex=half) (duplex=send)))

and now means:

(| (! (duplex=half)) (duplex=send))

apparently, usage of the negation operator over the entire disjunction
can introduce computation complexity into the comparison
algorithm. Plus, I think this usage of applying it to individual
elements is more intuitive and useful.

* pointed out that there is no way to tell if a contact param is a
feature tag used by caller prefs, or a contact parameter used by
another extension. however, it turns out that it doesn't matter, and
this is explained in the document.

* added support for numeric feature inequalities and ranges. In the
previous draft, if you had a numeric feature tag, such as
"x-resolution", the only thing you could do as indicate that it equals
some value. You couldn't ask for a UA with a display less than a
certain x resolution, or within a range of values. This is a critical
weakness, and would prohibit us from expressing many capabilities
which will be useful for wireless (things like memory constraints,
display constraints, etc.). This is fixed now, allowing all of the rfc
2533 numeric constraints.

* added support for features which are strings, meaning that they are
compared using case sensitive matching rules, rather than case
insensitive, which is the case for tokens. THey are indicated with
angle brackets.

* added the Require-Contact header. It allows a UA to indicate that a
request should only be routed to a matching UA, and all others are
discarded. It is similar to accept-Contact, but more forceful. Several
use cases required differentiating this modality from that of
Accept-Contact.

* added the cid and https URI schemes to the list of schemes that can be
used with the schemes tag.

* Consolidated BNF into one section

* Grammar for Reject-Contact used to allow a q-value, even though
q-values are not used for that header. This has been fixed.

* implementation strength of the preferences algorithms at a compliant
proxy was not specified. It is now listed as SHOULD.

* mention in several places that using rfc2533 syntax as an
intermediate processing step is not mandatory. Any implementation that
results in the same outputs can be used.

* Added subsections to the proxy processing section to facilitate
reading.

* The "only=TRUE" parameter present in callerprefs-05, and omitted
from -06, is now back, but in a different way. It is integrated into
the processing performed by a UAS, which will also honor the
Accept,Reject and Require-Contact header fields. Only a UA will
include the uri-user and uri-domain filter rules into the feature set
that describes a UA. Combined with the rules for how require and
reject-contact processing happens, the net result is that URI
preferences are only ever checked at a UA; this is the only place they
can be.

* Some implicit preferences are now Require-Contact preferences -
specifically, those where the request will fail if routed to a UA
which doesn't support the preference. That includes methods and
events.

* Accept-Contact implicit preferences work by creating a NEW predicate
for the implicit preferences, rather than adding terms to existing
predicates. This has better behavior in the event the explicit
preference doesn't match. For example, if a user indicates a
preference for voicemail (Accept-Contact: *;voicemail="TRUE") and adds
an Accept-Language header for Spanish, their call will prefer a
Spanish voicemail system, and if thats not available, either a SPanish
user or an English voicemail system. The least preferred contact would
be an English user.

* Added Accept-Language implicit preferences.

* proxies no longer add an implicit uri-user and uri-domain term to
the contact predicate.

* Added a brief tutorial on RFC 2533, covering sufficient material to
understand caller prefs without reading it.

* Added mention of rfc 2738, which provides a minor update to
rfc2533.

* added text recommending that a UA provide full disclosure in its
feature set registrations, and that it MUST list all values for a
particular feature tag that it does include.

* mentioned that other applications can used the capability
information uploaded in caller prefs.

* described the general model of how rfc2533 applies to SIP UAs, and
why it matters.

* consistent use of the terms header, header field

* added IANA registration for pref option tag.

* general improvement in terminology

* clarify that you can change feature sets mid-dialog by sending an
updated feature set in a target refresh request.

* CHanged the four header fields from "amr" (in terms of table 1/2) to
"r", since proxies shouldnt muck with them. We'd like to preserve e2e
signatures on them.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip