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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Feb 2003 08:00:45 -0500

I think we are getting ourselves wrapped around the axle
because we have two opposing views of how devices interact
with presence.

The viewpoint you and Jonathan seem to have is that there
are multiple tuples in a presence document each describing
one device.  Since there is a contact address in the tuple,
you want that contact address to get you to that device.

I want a single object that represents one presentity.
It gives you all the information the principal is willing
to give that particular watcher about him.  There is ONE
contact address.  In this object, I represent several
possible devices.  As I have said in the past, I really
don't want to make devices explicit, but I am willing
to compromise on that.  What I care about is that normally,
I don't give you a device address, I give you a single
AoR that represents the Principal.  If you want to influence
how the call is routed to the Principal, who may indeed
have multiple devices near him at any one time, use
Caller Preferences to do that.

The problem I have with one device per tuple is that I
don't see how I get my preferred representation to work.
The problem you have with one object (and one address)
per Principal is you don't see how to address a device.
We have to figure out what the middle ground is.
I'm not objecting to having a way to provide a device
address if the principal wishes to.  I'm trying to
figure out a way so that if the principal does NOT
wish to provide device addresses, or even enumerate
the devices he has, all watcher/UA implementations will 
work pretty well. 

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, February 11, 2003 6:24 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs
> 
> 
> 
> 
> [email-masked] wrote:
> > Its not up to the caller to dictate where the call should 
> be routed, its up to the callee. The caller only presents a 
> wish list called "caller preferences". If the callee has 
> another device that matches those preferences, but its not 
> the device that the tuple described, and the call is routed 
> there, is there any wrong in that?
> 
> That's not my point. My point is truth in advertising. If I 
> pick a tuple 
> based on what it advertises, and send a request to the corresponding 
> contact, I expect to get to a device with characteristics consistent 
> with what the tuple advertised.
> 
> Based on discussion, there are open questions about this. 
> Assume for the 
> moment that all published contacts are sip addresses:
> 
> 1) if I simply send an INVITE to the contact address from the tuple, 
> without annotating my request in any way with my desired 
> features, can I 
> expect it to arrive at a device that has (or at least 
> recently had) the 
> features described in the tuple?
> 
> 2) if (1) is false, can I achieve the intent by annotating 
> the request 
> in some well known way with information derived from the tuple?
> 
> > We have to be careful with privacy issues here. I can 
> publish all the caller prefs in <prescaps>, but I still 
> reserve the right to have my AoR as the contact.
> 
> I'm not arguing with that. (1) above can be achieved by the publisher 
> appending sufficient callerprefs onto the AOR in the contact 
> to select a 
> suitable device. (2) can be achieved as long as all capabilities are 
> represented as prescaps.
> 
> Things that are represented by status other than prescaps presents a 
> problem. If the presentity is showing two tuples, one with status 
> <happy> and another with status <mad>, how can I ensure my call is 
> directed to the <happy> one? If (1) is true then I can, because it is 
> the publisher's problem to figure out how to tag the contact 
> to achieve 
> that end.
> 
> 	Paul
> 
> >>-----Original Message-----
> >>From: ext Paul Kyzivat [mailto:[email-masked]]
> >>Sent: Tuesday, February 11, 2003 3:42 AM
> >>To: Khartabil Hisham (NMP/Helsinki)
> >>Cc: [email-masked]; [email-masked]; 
> [email-masked]
> >>Subject: Re: [Simple] RPIDS: Capabilities in tuples and Caller Prefs
> >>
> >>
> >>
> >>
> >>[email-masked] wrote:
> >>
> >>>>Let me elaborate on your example. Lets say you've got a PC 
> >>>>and a phone. 
> >>>>You advertise one tuple for video (calls to which should get 
> >>>>routed to 
> >>>>the PC) and one for audio (calls to which get routed to both 
> >>>>the PC and 
> >>>>the phone). A watcher clicks on the "video" tuple. However, 
> >>>>by default, 
> >>>>their device does not ask for video streams - it uses an 
> >>>>audio stream in 
> >>>>the initial call setup, and adds video once the call 
> >>>>completes. If the 
> >>>>URI you use in both contacts is the same, how is the proxy to 
> >>>>know that 
> >>>>this call was for the PC alone? There is no video in the SDP.
> >>>
> >>>
> >>>You, as a caller (and watcher), have a preference to use 
> >>
> >>video. If your device asks for audio when you explicitly 
> >>asked for a video call, then you need a new device, or you 
> >>need your device to implement caller preferences.
> >>
> >>>We have a mechanism to solve such a problem, caller 
> >>
> >>preferences. Why invent a new one?
> >>
> >>You as a caller and watcher know, in your head, that you want to 
> >>communicate with a device that supports the characteristics 
> described 
> >>for the tuple you are viewing via your presence client.
> >>
> >>Your UAC is going to construct the invitation from the 
> information in 
> >>the tuple you have selected. (I doubt that you want to redundantly 
> >>specify all the information presented there.) It will also 
> >>perhaps use 
> >>some information from your "command" to initiate this - perhaps 
> >>something like "make voice call".
> >>
> >>Presumably the UAC will construct the To: address using the 
> <contact> 
> >>from the <tuple> you selected. It *could* also construct 
> callerprefs 
> >>from the other contents of the tuple. It should be 
> >>straightforward to do 
> >>so from the <prescaps> rendition of the capabilities of the 
> >>contact, if 
> >>present. In general there is no good way to map any other 
> capability 
> >>that might be specified.
> >>
> >>This isn't guaranteed to get to any device corresponding to 
> the tuple 
> >>you selected, unless we make some rules so that it does.
> >>
> >>What Jonathan proposed was that the entry in the <contact> 
> >>simplify this 
> >>by providing some kind of guarantee that if I select a tuple, 
> >>I will get 
> >>to a device supporting the capabilities claimed in the 
> description of 
> >>that tuple. Seems reasonable to me.
> >>
> >>	Paul
> >>
> >>
> > 
> > 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Feb 2003 19:49:22 -0500

Brian, sorry to be so long in responding. I have been preoccupied with 
other things. Comments inline.

	Paul

> because we have two opposing views of how devices interact

I agree that this is the problem. I think the problem goes away if we 
permit both usages to coexist.

> don't see how I get my preferred representation to work.

For your preferred representation, you don't use one device per tuple. 
Instead you simply use one tuple, with the AOR as the contact address.

This is a usage that you, as a presentity, negotiate with your presence 
server to publish.

> per Principal is you don't see how to address a device.

We just choose to use multiple tuples, with multiple addresses.

> We have to figure out what the middle ground is.

I think the actual problem, if any, is with the client. It is the server 
that gets to decide which of these models it wishes to use. The client 
must accomodate.

For us it is not a problem - you only publish one tuple, so to us it is 
just a single virtual device.

I don't know if this is a problem to you or not. Clients need to be 
prepared to present information about multiple tuples to their users, 
and preferably provide the user with suitable courses of action on a 
per-tuple basis. This is more work than if there is but a single tuple. 
But I can think of some concise and convenient GUI interfaces for this.

> the devices he has, all watcher/UA implementations will 

Where is the problem?