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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 6 Feb 2003 10:57:47 -0500

The RPIDS work has had a couple of threads running amongst the authors
and contributors.  Now that the latest draft is out, we've been 
asked to put any further discussions on the list, which is most
appropriate.  This message is a continuation of one such thread.

Jonathan and I have been having a discussion of whether the
presence information includes a set of PS-manufactured contact
uris that correspond to the devices enumerated in the presence
document.  Jonathan proposes that there be an arbitrary categorization
of information in the document, and each tuple have a contact
address that is specific to that category.  The presence system
would then work with the outbound proxy for the IM/Voice/Video
devices to direct this contact uri to the appropriate device.

I would prefer that there be a small number (one is good) of
"well known" addresses that is my contact address, and a caller
use Caller Prefs to cause the call (IM/whatever) to get to the
right device.  

So, with that, I pick up the thread. > > is from me, > is from Jonathan
> > What the heck do we need separate contact addresses manufactured
> > by the presence agent for?  If you send a call to my
> > sip uri with some SDP, my proxy can get it to the "right" device.
> 
> How does it know which is the right device? On a separate 
> thread on this 
> topic, we concluded, I believe, that presence represented a sort of 
> contract. When the PA advertised a tuple with certain sets of 
> capabilities (is a cell phone, supports video), it was the 
> responsibility of the PA to construct a URI such that the 
> caller, doing 
> nothing other than invoking a call to that URI, would get its call 
> routed to one or more UA that are accuratedly described by those 
> capabilities. Generally, this means that the PA will need to 
> know which 
> tuple the caller tried to reach, in order to do this.
I think this is all caller prefs.  I don't understand why we would
ever define something in SIMPLE that was not representable in
caller prefs with respect to how a caller expressed which device
(or really, which capabilities) a future call was to be routed to.
I don't see any way this limits presence, or puts undue burden
on caller prefs.

> 
> 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.
The caller prefs requests video even if the SDP doesn't have it.

> 
> The problem is less contrived when the presence represents 
> devices, such 
> as PC and cell phone. Presumably, when the watcher chooses the cell 
> phone, a call should go to the cell phone and NOT the PC. How 
> would the 
> proxy know to do that? The only reasonably way was to have 
> the PA come 
> up with a URI which had that effect, using whatever technique 
> it likes.
Again I think caller prefs gives you the capability you need.
 
> 
> > If you want to influence what that is, caller prefs can do that
> > (but it's up to me to actually decide).
> 
> We also talked about this. You dont want the watcher to have 
> to come up 
> with the appropriate set of caller prefs to route the call to the 
> desired device. You can use caller prefs only in the sense 
> that the PA 
> can include a contact URI in the presence doc like this:
> 
> sip:[email-masked];Require-Contact=*;mobility="mobile"
If the caller wants to force a call to my cell, this looks like
a reasonable uri to me, whether the caller created it because
it understands the syntax of caller prefs or, if you prefer,
because that is the contact uri in the presence document.  
It's a heck of a lot better than the prior uri you suggested.
 
> All the caller needs to do is make a call to this URI. It 
> doesn't need 
> to know how to build the caller prefs headers.
I really think that a rich presence system will find
it easy to build a uri with caller prefs.

I further think that it's not appropriate to invent a new way for a
watcher/caller to express preferences for how his call is
handled.  Caller Prefs is how we do that.

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