[Sip] Changes in caller prefs -09

[Jonathan Rosenberg <[e-mail]>]

Folks,

You may have noticed that caller prefs -09 was posted:

http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-09.txt
http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-09.html
http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-09.txt

This document is substantially different from -08.

First, the capabilities stuff has been yanked into a separate I-D 
(http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-00.txt). 
That includes REGISTER and OPTIONS processing, and all of the media 
feature tag definitions and registrations.

The reason for the split, as I indicated in another note, was that we 
believed there were going to continue to be problems with the caller 
preferences piece of callerprefs (i.e., the Accept-Contact and 
Reject-Contact header fields). A big issue we encountered with -08 
based on excellent input from Ted Hardie, was that q-value arithmetic 
is a no-no. Q-values as defined are ordinal, and you can't perform 
arithmetic on them, or compare them between different sources. We had 
been doing a lot of that in -08.

So, in -09, the algorithm has changed. THe proxy computes the score 
for each Accept-Contact rule against each Contact, as before. The 
overall caller preference for a contact is then computed as the 
average of the scores across all Accept-Contacts for that contact. 
Previously, we had a really complex function instead of arithmetic 
average. The reason had a lot to do with quirks that arise when you 
try to do q-value arithmetic. Anyway, once the average (the caller 
preference) is computed, it is used in a specific way. For those 
contacts with EQUAL Q-VALUES AS SET BY THE CALLEE, the caller 
preference is used to order them. We never combine the caller and 
callee preferences; we merely use the caller preference to provide an 
order when the callee provides none.

This algorithm is a lot simpler, and it never tries to do arithmetic 
on q-values. However, there is some loss of functionality. I tested 
the algorithm on all of the use cases, and found that a few failed. 
For example, Section 3.5 of 
http://www.jdrosen.net/papers/draft-ietf-sipping-callerprefs-usecases-00.txt 
describes a case. There, the caller wants the call to go to a 
videophone, but will take an audio-only device as a second choice. The 
callee prefers the audio-only phone. Because the caller preferences 
can't ever reorder callee contacts with differing q-values, there is 
no way to "override" the callee preference for the audio phone, and 
still fall back to it in the case where the videophone doesnt work or 
can't be reached.

Section 3.12 describes a similar case, where a user wants to go right 
to voicemail, but will take a call with the user if there is no 
voicemail. We can't do that anymore.

I welcome comments on whether this loss of functionality is 
substantial enough that we need to investigate ways of getting it 
back. I personally would prefer to just declare victory with what 
works and move on.

Some of the other changes:

* elimination of the q-values in the Accept-Contact; they were never 
needed in any of the use cases, so I removed them

* Clarification on the purpose of Proxy-Require, based on comments by 
Mary and others during wglc.

* A lot more discussion on how to set the require and explicit 
parameters. These can be confusing, and its hard to tell which of them 
you need.

* when a proxy is redirecting, it sets the q-values for the contacts 
to anything which orders them based on the results of the above algorithm


Comments and questions welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip