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

From: [email-masked]
Date: Fri, 7 Feb 2003 17:38:51 +0200

I have to agree with Brian. I thought we agreed that call routing and presence info are two separate, but complimentary things. Proving call-routing-info in the presence document is not such a good idea.

Regards,
Hisham

> -----Original Message-----
> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, February 06, 2003 5:58 PM
> To: 'Jonathan Rosenberg'
> Cc: [email-masked]'
> Subject: [Simple] RPIDS: Capabilities in tuples and Caller Prefs
> 
> 
> 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Feb 2003 11:48:04 -0500

This will require every presence client to support 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.

It also means that every proxy in the presentity domain has to support 
caller preferences.

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.

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.

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?

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.

This is not an argument about abstract design principles; if you accept 
that the role of teh contact is to connect me to the thing which is 
represented by that tuple, you have NO CHOICE but to have the presentity 
  provide a different contact for each tuple.

-Jonathan R.

[email-masked] wrote:
 > I have to agree with Brian. I thought we agreed that call routing and
 > presence info are two separate, but complimentary things. Proving
 > call-routing-info in the presence document is not such a good idea.
 >
 > Regards, Hisham
 >
 >
 >> -----Original Message----- From: ext Rosen, Brian
 >> [mailto:[email-masked]] Sent: Thursday, February 06, 2003
 >> 5:58 PM To: 'Jonathan Rosenberg' Cc: [email-masked]' Subject:
 >> [Simple] RPIDS: Capabilities in tuples and Caller Prefs
 >>
 >>
 >> 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.
 >>
 >> 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 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.
 >>
 >>> 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.
 >>
 >>> 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:
 >>>
 >> 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.
 >>
 >>  watcher/caller to express preferences for how his call is handled.
 >> Caller Prefs is how we do that.
 >>
 >> Brian _______________________________________________ Simple
 >> mailing list [email-masked]

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com