[Sip] More woes with implicit caller preferences

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

Folks,

Well, I *thought* I was done with the caller preferences revision. 
However, I began the process of validating the spec against our use 
cases, and found that one of them broke, once more due to implicit 
preferences.

I'll spare people the gory details, and summarize the problem thusly. 
When a caller makes explicit preferences in the request (by including 
Accept and Reject contact header fields), it is very hard for a proxy to 
properly determine how to ADD implicit preferences (for the method and 
events). The reason is that there are many ways in which the explicit 
and implicit preferences can be combined (add a new predicate, add a 
term to all existing predicates, add a term to some existing predicates, 
change the q-values after such additions, etc.). I do not think there is 
one right way. Indeed, one of the use cases failed with the current 
mechanism (add a new predicate), whereas others worked. The right way 
depends on the desired service, but the proxy doesnt know what it is.

So, I have a simple solution.

The solution is that the proxy NEVER adds implicit preferences if there 
are any explicit preferences at all. That is, if there is an Accept or 
Reject Contact header field, the proxy does not try to add implicit 
preferences. Only in the case where there are no headers, will the proxy 
compute an implicit preference. In this way, we eliminate the 
combination problem I point out above. This change also simplifies the 
proxy processing in the case where an implicit preference eliminates all 
contacts in the target set. Currently, this will require the proxy to 
run the entire algorithm again. With this change, it won't. If implicit 
preferences is used, and all targets are eliminated, the proxy simply 
uses the original target set without caller preferences processing.

I will need to add words that encourage a caller who uses callerprefs to 
include preferences for the method and event packages. The use case 
document will elaborate on the various ways in which one might express 
those preferences, and show how they affect routing.

I doubt there will be complaints, so I am going to go ahead and change 
the text to reflect this. However, if you do have issues with this 
solution, please speak now.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip