[Sip] changes in caller prefs

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

Folks,

As you may have seen, I have submitted an update to the caller prefs 
spec. A lot of work went into this draft since the last rev. There are a 
lot of changes, which are summarized below. Generally speaking, the 
reasons for many of these changes were to make caller prefs functional 
for many of the use cases that we are considering. The reason that the 
draft took so long is that it still cannot cover all of them, and I 
believe significantly more complexity would be needed to support all of 
them. However, I have concluded that we should simply declare those out 
of scope for now, primarily because we dont really know what people are 
going to use caller prefs for. We need to gain more experience with it.

The specific cases which arent well covered at this point are those 
where you wish to preferentially route to a UA that has declared a 
capability that is the best explicit match for the callers preference. 
For example, if the caller asks for audio, video, messaging, the call 
would be routed first to a UA that said it did audio and video (but said 
nothing about messaging), and second to a UA that said it did audio (but 
said nothign about messaging or video).

If we agree that this feature is out of scope, I believe caller prefs as 
written is done, and there are no open issues. A lot of good fixes went 
into this version, and its time to declare victory. I'll be talking more 
about this during the ietf meeting.


Changes:

* added Paul K as co-author to acknowledge his contributions to the
work.

* we always had this problem that there was no way to determine which
contact parameters were caller prefs. Enough folks have complained
that I put a solution in place. The parameters defined in this spec
itself can appear as they are. However, any other parameters
(including ones registered already) have to appera with a leading
+. So, if you invent a new media tag foo, you would use it in the
contact params thusly:

Contact: <sip:user@domain>;audio="TRUE";+foo="FALSE"

* eliminated the Require-Contact header field. Replaced it with the
new require parameter of the Accept-Contact header field.

* added a weighting to the proxy computations, so that contacts that
are a better match to the accept-contact header result in a higher
q-value.

* aligned the "mime" media type feature tags around the SDP media types
instead. Thus, the values defined include audio, video, application,
data and control.

* added text to deal with the possible future definition of new SDP
media types:

If a new SDP media type were to be defined, such as ``message'', a new
feature tag registration SHOULD be created for it. The name of the
feature tag MUST equal that of the media type, unless there is an
unlikely naming collision between the new media type and an existing
feature tag registration. As a result of this, implementations can
safely contruct caller preferences and callee capabilities for the new
media type before it is registered, as long as there is no naming
conflict.

* added the new "explicit" parameter to the Accept-Contact header
field. It is used to signal that a contact must match explicitly.

* changed the "voicemail" tag to "msgserver" since the voicemail term
is voice specific.

* the q-value parameter can now appear anywhere in the header field
value; it need not occur after the feature tags, as before.

* allow the feature tag to appaer with no value. i.e.,:

Accept-Contact: *;video;audio

when present in this form, it means ="TRUE".

* allow for the value to be a comma separate lists of numerics and 
booleans,
not just tokens, as previously. However, you still can only have a
single string value.

* you can negate booleans and numerics now (used to be only token
equalities could be negated)

* fixed the syntax bug which would result in quoted strings being
double-quoted.

* changed the range syntax to use a colon, and removed the useless "R"

* numbers were formerly represented in fractional form (i.e., 3/4)
instead of decimal (0.75). THis was just because thats how rfc2533
represents them. Several folks complained, so I changed it to a
decimal form. The section on mapping to rfc2533 describes the
conversion between the two. Of course, in practice, it is probably
never needed to convert.

* Changed the syntax of the feature tag itself, adding support for
escaping and the + sign

* Allowed for generic-param in Accept and Reject contact, to allow for
future extensions.

* Mandated that, when numeric parameters are present in a feature
param, they be representable as an ANSI C double.

* Changed the title to reflect sip-guidlines guidance

* changed the header table column for proxies from r to ar. THis means
a proxy can add or modify a value. Discussion of this is added in the
proxy processing section. Proxies can't remove or modify header field
values because of s/mime, and this is pointed out.

* removed implicit preferences for media, languages and priority per
list discussion.

* added a note saying that you are now allowed to express explicit
preferences for methods, event packages or schemes not defined in ietf
standards track protocols.

* added UA processing of OPTIONS. The contact header in the 200 OK to
options can contain feature parameters.

* added isfocus parameter. This is needed for the conferencing
work. It seemed easier to add it in here than to issue a separate RFC
just to register it.

* if application of caller prefs results in the elimination of all
registered contacts, the algorithm is re-run, but this time, any
implict preferences are not at the require strength. This is as per
list discussion.

* added an extensive example to the proxy matching section

* note that if a 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.

* updated table 2/3 to also include MESSAGE.

* added a nice figure to explain the proxy matching operation

* added an example service that is enabeld by called prefs to help
motivate interest.

* clients registering caller prefs params SHOULD use sips for privacy
services, and callers SHOULD use sips for integrity protection (iesg
wants to see baseline mechanisms for addressign all threats described
in security considerations)

* Previously, the uri-domain and uri-user feature tags had very
special processing. Only the UA would compute them (they were not real
feature tags) for registered
contacts, and apply them to any Accept or Reject-Contact. This was to
solve the problem previously solved by the "only=true" flag. Namely, a
proxy couldn't reject a contact because of a mismatch in the URI,
since a downstream forwarding operation might actually route to that
contact. As it turns out, this problem is not specific to the URI
parameters. Generally, it is only safe to compute caller preferences
when they refer to a URI that is a UA, as opposed to an AOR. So,
several changes were made. First, uri-domain and uri-user would made
full feature tags. Like all the others, they are explicitly registered
by a UA. A UA can now opt to register NO feature parameters for a
contact. Such contacts are "immune" from caller preferences
processing. Thus, when a UA registers an AOR, it includes no feature
parameters. When it registers a contact for a UA, it includes feature
parameters. It can include the uri-user and uri-domain
parameters. They must be explicit now. These receive no special
processing at the proxy. The only "exception" is that in Accept or
Reject-Contact, they can appear as parameters, or appear as the URI
itself. To some degree, that makes the URI redundant, but I retained
it for backwards compatibility.

* special treatment of the schemes parameter by the proxy has been
removed. Formerly, if it wasnt explicitly indicated, the proxy
computed an implicit schemes parameter. No longer, for the same
problem as above.

* implicit preferences are only computed by the proxy if no explicit
preferences at all were provided. This eliminates the need for the
proxy to figure out how to combine the explicit and implicit
preferences. Text was added the the UA section RECOMMENDing inclusion
of method and event preferences, and to do so by adding a term to all
existing A-C predicates.

* UA registration procedures explicitly call out the handling of
contacts that are not UA instances. There is a good discussion on the
meaning of registering an AOR, and how to associate feature parameters
with it.

* the spec was unclear about exactly WHEN in the UAS processing steps
the caller preferences checks are done. It actually matters. It needs
to be done after authentication/authorization, but before the rest of
8.2.1 of rfc3261. Also, the spec didnt state what to do if there was
or wasnt a match. If there is no match, send 480. If there was a
match, continue with request processing.

* the spec had evolved over time to an inconsistent usage of the
schemes feature parameter. There are two interpretations. One is "this
is the scheme of the URI associated with my UA", making it a peer of
the uri-domain and uri-user parameters. Another interptation is "I
know how to handle redirects to URIs of these schemes, or how to
process them if they were entered on my UI". The desired
interpretation is the latter. That has been clarified, and usage made
consistent with this view throughout the spec.

* clarify that quoted strings in rfc2533 are matched using CS
matching, and tokens using CI.

* provided a warning that the "application" feature tag is not that
useful in genreal.

* clarified that the priority feature tag indicates that a UA can
support calls of a certain priority and higher.

* added sip-extensions feature tag

* Accept-Contact and Reject-Contact used to have a URI or a * as the
value, along with the feature params. With the explicit uri-user and
uri-domain params, continued use of the URI introduced redundancy in
the header, and also made the text more confusing. So, it has been
removed. The two headers ALWAYS have a value of *, followed by the
feature params, which can include the uri-user and uri-domain if the
caller wants to express preferences on those. The * itself can't be
removed, since the sip
guidelines spec mandates that a token be present in the value.

* added some guidance on proper redirection using caller prefs. If you
redirect and include q-values that were the result of caller prefs
modification, the redirect can't include the caller prefs feature
parameters. If they did, the upstream proxy would apply the same
caller prefs operation again!

* substantial rework of the algorithm used to combine the various
q-values involved. Now, a specific algorithm is provided, engineered
to have particular properties.


-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip