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

From: [email-masked]
Date: Mon, 10 Feb 2003 11:38:36 +0200

> -----Original Message-----
> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: Friday, February 07, 2003 8:55 PM
> To: 'Jonathan Rosenberg'
> Cc: Khartabil Hisham (NMP/Helsinki); [email-masked]
> Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs
> 
> 
> > 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.

It is a likely case that they are physically separate. I was a presence client on my PC, but make my calls from my mobile phone. Its much easier to make caller prefences than having to copy a uri that looks like:

sip:[email-masked].

I don't mind mandating caller preferences to be implemented, if a user wants to own a UA that has the luxury feature of presence based call routing.

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

Yes, the call is forwarded using the script as created by the proxy when it examined the presence info. The caller doesn't need to decide the PC, its the routing logic that needs to route the call to the right destination. The routing logic is in the network.

Looking at Jonathan's earlier example:

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

Regards,
Hisham

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2003 20:41:39 -0500

> 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