Re: [Sip] Changes in caller prefs -09

Rohan Mahy <rohan@cisco.com> Wed, 13 August 2003 21:58 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07891 for <sip-archive@odin.ietf.org>; Wed, 13 Aug 2003 17:58:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3d9-0003hH-Da for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 17:58:07 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLw7Yg014205 for sip-archive@odin.ietf.org; Wed, 13 Aug 2003 17:58:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3d4-0003gh-BE; Wed, 13 Aug 2003 17:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n3cm-0003gJ-BH for sip@optimus.ietf.org; Wed, 13 Aug 2003 17:57:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07864 for <sip@ietf.org>; Wed, 13 Aug 2003 17:57:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3cj-0005ZC-00 for sip@ietf.org; Wed, 13 Aug 2003 17:57:41 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19n3ci-0005Z3-00 for sip@ietf.org; Wed, 13 Aug 2003 17:57:41 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7DLv3pp016300; Wed, 13 Aug 2003 14:57:03 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKI44562; Wed, 13 Aug 2003 14:49:57 -0700 (PDT)
Date: Wed, 13 Aug 2003 14:59:49 -0700
Subject: Re: [Sip] Changes in caller prefs -09
Content-Type: text/plain; delsp="yes"; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v552)
Cc: sip@ietf.org, Ted Hardie <hardie@qualcomm.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <3F0A6F93.5000305@dynamicsoft.com>
Message-Id: <75D0F1B8-CDD9-11D7-91B8-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

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


_______________________________________________
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