Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Feb 2003 13:54:39 -0500

> This will require every presence client to support caller prefs.
We'll, let's be carefull, a presence client per se doesn't
make calls to devices.  It's the calling UA that would need to
support caller prefs if it wishes to direct the call to a specific
device.  The UA and the presence client are likely to be
one and the same, but let's keep the roles separate please.

Now, if I do get a complex presence document, and, for some reason
I have yet to really understand, I want to insist that the call go to
a specific device maintained by the principal, then, yes, the
caller UA has to support caller prefs.

You can contrast that with inventing a new language to describe
various characteristics of a device, and having the UA have to
interpret that, as well as caller prefs.  
 
> 
> It also means that the client has to correctly guess the 
> right series of 
> caller preferences to route the request to the desired contact.
I think any mechanism we come up with to differentiate one device
from another can be implemented in caller prefs, rather than somewhere
else.

> 
> It also means that every proxy in the presentity domain has 
> to support 
> caller preferences.
No, I think it means that the incoming sip proxy for calls (IM, games,...)
that forwards based on your presence has to understand caller prefs.
It's pass-along to everyone else in the sip domain.  It doesn't occur
in the presence domain as above.

> 
> It also means that the only information one can put in presence is 
> information that can also be reflected into caller 
> preferences. So, if, 
> for example, I have a new presence status like activity, and 
> I have two 
> PCs, both equal, but I am at one, and not the other, so that the ONLY 
> difference is activity, this will mean we need to add a caller 
> preferences "activity" feature parameter, and a client will 
> need to keep 
> it up to date.
Agree.  Of course, I would say that we would need caller prefs only
so that the caller can manage to convince my incoming proxy to send 
the call to the PC I am not at, since I would expect that normally, 
a call to me would be forwarded to the PC I was at.    

> 
> Because of this, we will not be able to extend presence 
> statuses without 
> also extending caller preferences. Having been working on tuning the 
> caller preferences algorithm for DOZENS of hours over the 
> last weeks, I 
> can say with some confidence that I do not think caller prefs 
> will ever 
> satisfy the needs of disambiguating two devices with the richness of 
> presence we have been talkign about. Now, caller prefs may 
> work in some 
> cases, but its the PRESENTITY's domain which is in the position to 
> determine whether or not it will work, not the WATCHERS.
It seems to me if you can define the difference in the presence
document, you use the same "language" in caller prefs.  Define it
once, use it both places.  

Most of the richness in the presence stuff is information about the
principal, not the devices he has.  The differences between the
devices are simple. 

Of course, I think it is the CALLED party that actually decides what
device it takes calls on, but that's another thread.

> 
> So, really, I think we have a fundamental disconnect here.
> 
> TO me, the presence document contains a list of tuples, each of which 
> specifies a point of contact for the presentity. The semantic of the 
> contact URI is that, if I send an INVITE to it, I get 
> connected to the 
> thing described by the tuple.
> 
> Do we agree on this point, or not?
Agree

> 
> Assuming we agree, in order to do this, the thing constructing the 
> contacts has to do so in such a way that a call to that contact gets 
> routed to the thing represented by the tuple. This is a natural 
> consequence if you buy the above definition.
No, because you made an assumption I don't make:
I think you assume a tuple describes the presence information of one
device.  

While I can't stop you from constructing your presence client from 
doing that, I hope you won't stop me from constructing my presence 
client so that I describe one principal with one tuple.
That tuple has one contact address, but it describes the presence
of the principal, covering all of the devices he may have.

Brian
 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Feb 2003 14:20:47 -0500

I'm not sure there is a one right way to do things, given that this 
largely depends on the coupling between presence information, policy and 
the end system capabilities (as well as issues of trust). There are at 
least three models:

(1) single (sip/tel) contact URI, with different qualifications, using 
caller preferences

As long as each device is uniquely identified by the caller preferences, 
this works even if presence information offers additional information. 
Thus, I don't think all caller preferences information needs to be 
reflected in presence (or only caller preferences), just enough that the 
outcome is the same.

In many practical cases this is likely to work. The only major 
limitation I can think of is location-based routing where I want to 
reach the person at a specific location. Unless the person is really an 
aggregate, callee-based routing should deal with that.

(2) custom-made contact URIs for each tuple.

Avoids the uniqueness issues.

Requires fairly tight coordination between presence and request routing 
since I need to make up new devices when I create a new communications 
presence. I may also need to worry about whether these identities convey 
authorization (whoever can see this URI can call me).

(3) business card that enumerates all my capabilities, with long-term 
'universal' addresses

Requires least coordination, but has privacy and control problems.

Is there another option?

> interpret that, as well as caller prefs.  

Or create the unique IDs which are essentially hashed versions of 
caller-prefs.

>>preferences "activity" feature parameter, and a client will 

Unless you can rely on the normal call routing to not route the call to 
the inactive one (or you don't care that your inactive one rings and 
nobody picks up).

Why would you care that the call gets forked to an inactive device?