Subject: Re: [Sip] Changes in caller prefs -09

From: Rohan Mahy <[email-masked]>
Date: Wed, 13 Aug 2003 14:59:49 -0700

Hi,

I already privately replied to Jonathan about this and spoke up at the  
meeting, but since there has been a significant lack of discussion...

<as a chair>
If you feel Jonathan's proposal is reasonable, please send him a  
private ping.  If not, please raise your issues.
</as a chair>

On Tuesday, July 8, 2003, at 12:15 AM, Jonathan Rosenberg wrote:

> 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.

<as an individual>
I'm not losing any sleep over this use case, as the user can still do  
this in two-steps (use Reject-Contact first, get back a 404 response  
and then retry).  Simple things should be easy. More complicated things  
can be harder.
</as an individual>

thanks,
-rohan

> 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
> [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

_______________________________________________
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