Subject: [Sip] trimming "implicit preferences for media and priority" from caller prefs

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 25 Jan 2003 00:49:03 -0500

I have been working on yet-another revision of caller preferences, in my 
continuing attempts to get this thing finished. Just when I thought it 
was done, and all the changes were happily applied, I ran into another 
issue. Grr.

The issue is an interaction between the implicit preferences mechanism 
in the draft, and the desire to reach a user wherever they are.

Anyway, let me explain the problem by an example. Lets say I send an 
INVITE with audio and video in the SDP. The called party has two 
devices, a PC w/ audio and video, and a  cell phone with audio. They are 
not at their PC right now, but are available by cell. The desired 
behavior, and the intent of the caller (since they did not specify a 
preference), is that the call would reach both devices and ring both, 
and the user answers at the cell phone with audio only. However, the 
implicit preferences will cause the PC to ring first (because its a 
better match to the "implicit preference" to have video), and then the 
cell phone. THis will increase call setup time and worsen the user 
experience.

This problem is a specific case of a more genreal issue, which is that 
the implicit caller preferences mechanism is at odds with the proposed 
fix to HERFP (see 
http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt if you 
forget what HERFP is). They cannot co-exist. The whole idea with the 
HERFP fix is to let the request go everywhere it can, since the called 
party could be at any one of the devices. But, the caller prefs implicit 
preferences would prioritize and select only the matching devices. The 
called party may not be at that device, though.

The essence of the problem, I think, is that there is no such thing as 
implicit preferences. Just because I list audio and video in my SDP, 
does not mean I want the call to be routed to a device which supports 
those. It just means that those are the media types I want to try to use 
for this call. Generally, danger lurks wherever the network tries to 
assume something about caller intent, when it should not have assumed it.

So, my proposed solution is to remove the implicit preferences 
computation for media types, and also for priority (sections 7.2.2.1 and 
7.2.2.4 of caller prefs -07). The priority one is good to remove since 
we were never sure it was right to begin with. That would leave implicit 
preferences computations ONLY for methods, languages and event packages. 
There are issues there too, but of a somewhat different sort, which I 
will post in a separate note.

So, unless someone screams really soon, consider those two features removed.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 26 Jan 2003 14:39:03 -0500

Caller preferences seems to mandate being explicit rather than assuming 
things, so I agree that this should go. This is partially a lack of 
expressiveness of SDP (and the media preferences in caller-prefs), which 
can't distinguish between three subtly different things:

- capabilities that the device has (things that are possible)

- things the user would like to do now (which may be smaller or larger 
than the current capabilities);

- things that the user might want to do later (e.g., after reaching a 
higher-bandwidth area or transferring a conference mid-call to a more 
capable device).

Also, this is really a symptom of two non-commensurate quantities 
(preference for multiple media and preference for quickly reaching the 
destination) being at odds. Without a script, we can't really express 
all the subleties here, from "I'm willing to wait for the most desirable 
device to become available" at one extreme to "all devices being 
available, I choose X" at the other.

The problem would not occur if only devices where the user is available 
are reachable. In this example, the correct solution would be that the 
PC would not be in the reachable set at all.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 28 Jan 2003 17:57:19 -0800

I agree.  I believe it also unsafe to use implicit schemes (sip:, tel:, 
sips:, etc...).

thx,
-r

On Friday, January 24, 2003, at 09:49 PM, Jonathan Rosenberg wrote:

> I have been working on yet-another revision of caller preferences, in 
> my continuing attempts to get this thing finished. Just when I thought 
> it was done, and all the changes were happily applied, I ran into 
> another issue. Grr.
>
> devices, a PC w/ audio and video, and a  cell phone with audio. They 
> are not at their PC right now, but are available by cell. The desired 
> party could be at any one of the devices. But, the caller prefs 
> implicit preferences would prioritize and select only the matching 
> devices. The called party may not be at that device, though.
>
> those. It just means that those are the media types I want to try to 
> use for this call. Generally, danger lurks wherever the network tries 
> to assume something about caller intent, when it should not have 
> assumed it.
>
> computation for media types, and also for priority (sections 7.2.2.1 
> and 7.2.2.4 of caller prefs -07). The priority one is good to remove 
> since we were never sure it was right to begin with. That would leave 
> implicit preferences computations ONLY for methods, languages and 
> event packages. There are issues there too, but of a somewhat 
> different sort, which I will post in a separate note.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Jan 2003 15:14:36 -0500

inline.

Henning Schulzrinne wrote:
> destination) being at odds.

Right. This is exactly what I was trying to say.

> Without a script, we can't really express 

Indeed. WHich is why I think its good to not try and infer what the user 
is tryign to do. That would only get in the way of some kind of explicit 
script or other mechanism developed to achieve the desired processing.

ANyway, given Rohan's and Henning's agreement, I think we are closed on 
this particular point.

-Jonathan R.