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

From: [email-masked]
Date: Tue, 11 Feb 2003 11:06:46 +0200

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?

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.

Regards,
Hisham

> -----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: Tue, 11 Feb 2003 18:24:02 -0500

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

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