Subject: Re: [Simple] modeling dispatchers in the data model: a proposal for moving forward

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 06 Jan 2005 14:39:28 -0600

Jonathan Rosenberg wrote:

> We've gotten ourselves stuck lately in a few places in the presence 
> data model. In particular, folks have come forward with requirements 
> for having multiple services with the same URI. The use cases that 
> have been brought forward include:
>
> 1. I have a softphone on my PC that is one integrated application, 
> available at one AOR with one contact/gruu. I'd like to be able to say 
> that I'm available for IM but not available for voice.

Jonathan:

More feedback on the dispatchers is in a later email; but I do
have one question on the above scenario, though.

Why is this hard to do with the current data model?  Is it not
the case that a composer could publish a document with two tuples;
both will have the same Contact URI, but different servcaps method.
The tuple with the INVITE servcap will have the priority
attribute of contact element set to 0; the one with the
MESSAGE servcap will have the priority attribute of the
contact element set to > 0.0?  A watcher making a routing
decision based on such a document has all the information it
needs, no?

Or am I missing something?

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jan 2005 17:59:38 -0500

> decision based on such a document has all the information it

I agree this can be done (well) with the current model - but I disagree 
with the way you propose.

I imagine the device Jonathan is describing is capable (in general) of 
doing both voice and IM, together or separately, but is currently 
unavailable for voice.

This should preferably be represented as a single tuple, so that both 
voice and IM can be represented together. The fact that they could also 
be used separately is implicit in the way capabilities are described.

The single tuple can be open, specifying audio as unavailable, message 
(the media - i.e. msrp - for session mode IM) as available, and 
method=MESSAGE as available (for page mode IM).

Later, when voice is also available, this tuple can be updated to 
reflect that small change.

The thing that is currently hard to model is mutual exclusion - when 
this softphone can do *either* voice, or IM, but not both concurrently.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 06 Jan 2005 17:07:09 -0600

Paul Kyzivat wrote:
> This should preferably be represented as a single tuple, 

Paul:

Please help me understand -- is this a requirement (i.e., a single
tuple be used to represent different capabilities)?  Clearly we
have the atomic parts to model this -- the tuples could be tied
together by a device-id so that the watcher knows that we are
referring to the same device...

> this softphone can do *either* voice, or IM, but not both concurrently.

In a single tuple, yes.  But then again, is this a requirement
somewhere that I may have missed?

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jan 2005 18:20:41 -0500

Vijay K. Gurbani wrote:
> Paul Kyzivat wrote:
> 
>> I agree this can be done (well) with the current model - but I 
>> disagree with the way you propose.
>>
> tuple be used to represent different capabilities)? 

Is there a requirement that a publisher must *use* a single tuple to 
represent different capabilities? No. There are hardly any requirements 
on how this stuff must be used.

Is there a requirement that it be *possible* to use a single tuple to 
represent different capabilities? In my mind the answer is yes. In any 
case, requirement or not, it is possible with RPID.

 > Clearly we

Ah. But is that the same as saying they may be used concurrently?

(My device is both a floor mop *and* a pogo stick. But it can't do both 
at the same time.)

I imagine that the *advanced* presence enabled client will filter the 
set of tuples and capabilities down to the ones it has the ability to 
use, and display those to me. Then I can pick one to establish 
communications with. I would be making my decision on which to pick 
based on availability for the media I want to use.

> somewhere that I may have missed?

I've lost what the current proposal is right now. You can express this 
with multiple tuples identifying the same contact, *if* we don't treat 
that as an override. That is part of the argument.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Jan 2005 13:12:20 -0600

> case, requirement or not, it is possible with RPID.

Yes, it is.  But the problem is that we do not use RPID to make a
routing decision.  RPID can contain conflicting information about
the presentity in a single tuple (e.g. activity=steering and place-type
=home).  We do not make routing decisions based on RIPD; but we are
making routing decisions based on whether a IM or voice can be used.

Maybe it is not accurate to capture the state of the presentity in a
single tuple when describing capabilities that lead to routing
decisions.

> Ah. But is that the same as saying they may be used concurrently?

OK, then does it suffice to add a new attribute "concurrent=yes";
then when a single tuple contains servcaps of {MESSAGE, INVITE} then
it is a good indication that it can do both concurrently.

>>> this softphone can do *either* voice, or IM, but not both concurrently.

If the softphone cannot do IM and voice concurrently, then it would
publish two tuples as I suggested earlier.  If it could, one
tuple with the new attribute suffices.  Maybe this attribute could
be added to the servcaps XML...?

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jan 2005 15:06:53 -0500

Vijay K. Gurbani wrote:
>> represent different capabilities? No. There are hardly any 
>> requirements on how this stuff must be used.
>>
                                        ^^
Who is "we"?

> making routing decisions based on whether a IM or voice can be used.

Of course there can be conflicting information. But that doesn't mean 
people don't make decisions of whether or not to call, and where, based 
on it. It is a subjective decision.

Perhaps you have a different use case in mind than I do. I am thinking 
of the case where the tuples are rendered to the watching user via a 
presence gui, and the user can request to initiate communication to the 
endpoint associated with any tuple. (Think of a common IM buddy display 
on steroids, where the row for a buddy can be expanded to show separate 
lines for each tuple. Then a right click can request communication.)

It sounds like you are thinking of a presence-aware proxy for an AoR, 
that uses presence to decide which of the registered contacts to route 
to. That is not an unreasonable thing to do, but is likely to use a 
different strategy for use of the RPID data. In the end it doesn't 
really matter much which tuple it picks - it can parallel fork to them 
all. Using the presence data is just an optimization.

> single tuple when describing capabilities that lead to routing

The tuple doesn't capture the entire state of the presentity. But it 
captures at least some of the state of the service at that address. And 
that is enough for the purpose.

If there are multiple tuples with conflicting information, that refer to 
the same contact address, then no big deal. The watching user probably 
doesn't see the actual url anyway, so doesn't know (or care) that they 
are the same. They just look like two services which might be contacted. 
So he picks one based on what it claims, and tries to communicate with it.

>>> Clearly we have the atomic parts to model this -- the tuples could be 
>>> tied

These capabilities already mean "concurrent" in callerprefs, as well as 
in prescaps. Why do we need a new attribute? So we can say in a single 
attribute that they are *not* concurrent? Not concurrent with what? You 
need a grouping syntax if you want to do this in a single tuple. But we 
already have a grouping syntax - the tuple - so why invent another?

> be added to the servcaps XML...?

One tuple, *without* the new attribute suffice.

I have a feeling we are talking past one another.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Jan 2005 16:48:31 -0600

Paul Kyzivat wrote:
[...]

Paul:

The crux of the matter is single tuple or multiple tuples to
represent discrete services accessible through the same
Contact URI.  I favor having multiple tuples with attributes
defining the characteristics of the service; each such tuple
has the same Contact URI (instead of a GRUU).  But as I
understand it, there isn't consensus since you may favor
a single tuple for all services accessible through the
same Contact URI.

Ciao.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jan 2005 18:20:14 -0500

> a single tuple for all services accessible through the

If there are discrete services available thru the same contact URI than 
I agree with representing them as distinct tuples.

The difference of opinion is when there are two services and when there 
is one service with multiple capabilities. Some examples:

1) a video phone. It has both audio and video capabilities. It is 
possible to use either or both in a single session. It is also possible 
to start with just voice and then add video later in the session. I 
think this is one service with one tuple.

2) same as (1), but I have disabled the video feature. It is still one 
service, one tuple, now the video capability is indicated as absent.

3) a sip communicator client on a pc. supports voice, video, and session 
mode IM via MSRP. Any combination of these can be used in a single 
session. Still one service, one tuple.

4) a sip communicator client on a pc. Supports voice, video, page mode 
IM. Permits any combination of voice and video in a session. Permits 
MESSAGE only outside a dialog. The UI for IM is separate from the UI for 
voice/video. This is two services - one for voice & video, another for IM.

5) same as (4), but MESSAGE is permitted both in a dialog and outside. 
MESSAGE in a dialog is integrated with the UI for voice/video. MESSAGE 
outside a dialog has a separate UI. Not at all clear to me whether this 
is one service or two. (Best not to build this device.)

Do you disagree with the above?

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Jan 2005 00:50:13 -0500

inline. I'd ask folks to please read to the end where I have another 
compromise proposal on unique URI that may be more palatable than my 
previous one.

Aki Niemi wrote:

> Hi Jonathan,
> 
> First of all, thanks for pushing the resolution of this issue forward by
> making a concrete proposal.
> 
> I don't think making the dispatcher visible to the composer/watcher 
> actually solves the real problem; it does however reaffirm the statement 
> made in the data model that unique contacts URIs are required in service 
> tuples. The primary motivation for this requirement seems to be that it 
> enables overriding service elements.

No, not so at all. Please see my post in response to Robert's compromise 
proposal where I try to explain the concern more.

> 
> I think we are working with the wrong publication model to begin with, 
> which makes override of service elements problematic. The publication 
> model is that of a presentity employing a set of PUAs with equal rights 
> -- no one PUA is more authoritative than another. They are all 
> publishing their own full view of the presentity's service statuses.
> 
> This is much like a set of users running processes in an OS. Let's say 
> that user 'apniemi' sees that a process run by 'calendar' has gone awry 
> and is not responding. Using the current data model, fixing, or 
> overriding this process would entail user 'apniemi' creating a new 
> process, with matching properties (such as the pid), but a different 
> binary, resulting in overriding the 'calendar' user's process. Normally, 
> of course 'apniemi' probably wouldn't be able to do that, but instead, 
> would need to become 'root' and 'kill' the process.
> 
> So I think ultimately, we need a new interface to the composer, call it 
> root account, that gives us a way to "kill" publications that are 
> publishing stale event state. Perhaps such an interface could be 
> provided as part of the composer policy or authorization policy, but I 
> don't think it necessarily requires uniqueness of service URIs.

Sure, I agree with that you don't require unique URI to do this 
override. As long as you have some kind of unique and easily learnable 
handle it can work. The override isn't the real problem though.

> 
> If we reverse the assumption made in the data model that requires 
> uniqueness of service URIs, will watchers generally be confused if they 
> encounter service tuples with the same contact? I don't think so, as 
> long as the watcher does the following:
> 
> 1) takes note of the meta-information of each service (timestamp, 
> q-value) giving preference to a fresher service, or one with higher 
> q-value.

The point of q-value is not to say "please use this service over another 
service". PDM talks about this. If that were true there would be no 
point in advertising anything but the highest priority service.

> 
> 2) takes note of the characteristics of each service (prescaps for 
> example) along with the contact URI, applying its own known 
> characteristics and service URIs to determine what service the tuple is 
> describing

This seems like the "and magic happens" step, and is exactly the one I'm 
worried about. There is basically no way two watchers are going to 
interpret these the same. The essence of the problem is that the 
document has lost standalone meaning for what the tuple represents.

> 
> 3) takes note of the status, meaning that a basic status of OPEN is a 
> better choice than one with CLOSED, for example
> 
> 4) all of the above being equal, folds all identical services together 
> (after all they are identical in all ways that have relevance to the 
> watcher)
> 
> These steps should guarantee that the watcher can always make a proper 
> selection of which service to invoke. Invoking the service then involves 
> more than a simple "clicking the contact", since in the case of SIP the 
> watcher generally will e.g. construct an SDP offer that matches the 
> service that the watcher thinks the tuple is describing.

It could do that but it need not; the benefit of a URI and its 
definitional characteristic is that you need no other context beyond the 
URI to use it. I should be able to make a SIP call to that URI without 
having seen the presence document at all, and it works to the degree 
that SIP itself would allow the call to proceed. Presence might help 
optimize by allowing me to select media streams that work out of the 
box, for example, but its an optimization not a requirment for 
contacting the URI. If it is, the URI becomes meaningless.

> I believe the 
> invoking of a service MUST work using an AoR. If an INVITE offering 
> voice ends up served by a chess application, I think the system is 
> utterly broken, and needs to be fixed.

This is contradictory. You are saying that two services that are 
different have to be able to have the same AoR, but if you have the same 
AOR, how can you guarantee that an INVITE to that AOR is properly 
dispatched to the right app depending on where it came from?

  One fix could be using GRUUs as
> contacts, but that is not the only fix, and may not even be the best 
> one, IMHO.
> 
> All and all, I still don't buy the requirement for unique service URIs. 
> Also, I think that the default composer policy of union (i.e., collect 
> all service tuples together intact) will take care of the 95% need, 
> leaving out more sophisticated things like override and 
> merging/splitting for future study. 

I agree with that. I'll note that using GRUU has that effect.

Let me make another proposal, which is a variation on the dispatcher 
model I suggested, modified by an idea Henning proposed.

When a PUA publishes a tuple about itself, the <contact>, if present, 
still needs to route to itself. However, we also define an additional 
presence attribute called <i-belong-to> (suggested by Henning), which 
contains a URI which routes to a dispatcher through which that service 
might be reachable. In the SIP case, this could contain the AOR.

Thus, one could build a PUA which publishes about itself. It has no 
GRUU, so it omits the <contact> URI and includes <i-belong-to> 
containing the AOR.

Another smarter PUA would include the GRUU in the <contact>, possibly in 
addition to <i-belong-to> with the AOR.

A dumb composer can always union. A smarter composer can use the service 
URIs in the <contact> if present, in combination with the <i-belong-to> 
information to correlate the services together. It could then produce a 
tuple with the AOR in the <contact> and no <i-belong-to>.

The current contract and meaning of the <tuple> as a service remains as 
it is in the PDM. However, we now have the case where there is a tuple 
describing a service that is not directly reachable. The watcher knows a 
URI through which it might be reached, and can render or combine those 
together in whatever way it sees fit.

In the future, we could define this dispatcher service so that a watcher 
could even learn the policy governing how the dispatch is done.

I think this is simpler than my original proposal, has the benefit of 
maintaining the union operation as the default composition policy, 
retains the semantics of the service tuple as currently in the PDM.

I would be amenable to defining some kind of additional ID that serves 
to identify a tuple uniquely when the <contact> is not present. This 
would allow override even for tuples with no contact (as those published 
from a PUA not supporting gruu).

Is that more palatable?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Jan 2005 17:09:59 -0500

> =home).

This is the houseboat presence status :-)

Sorry, couldn't resist.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Jan 2005 18:19:49 -0500

I'm generally happy with that proposal as a way to move forward. More 
information for the watcher allowing correlation is always a good thing.

I think this means in more detail:

- Use of <i-belong-to> is RECOMMENDED.

- PUA SHOULD publish distinct contacts, which MAY share the same 
<i-belong-to> element value.

- Since existing non-RPID system won't know about <i-belong-to>, 
composers MAY do simple union (keeping tuples with identical Contact and 
maybe a different <note> element to avoid information loss) or MAY apply 
a smart composition policy that somehow merges the two same-contact tuples.

The content-selection HTTP URIs I mentioned earlier may not have contact 
URIs as such (they sometimes do, typically in file-based systems), so 
this is a bit SIP-specific.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jan 2005 11:22:01 -0500

Aki Niemi wrote:
...
> service that the watcher thinks the tuple is describing.  I believe the
> utterly broken, and needs to be fixed. One fix could be using GRUUs as 

OK, lets investigate how that might work. I think you assume that when I 
have selected a tuple, and constructed a request to it, that the request 
wll contain attributes of some sort that correlate to the tuple I 
selected, and no other. This is a bad assumption.

Consider the following case:

- we have presentity sip:[email-masked].

- she has one tuple that identifies a "voice" service
   (<audio>true</audio> <chess>false</chess>).

- she has another tuple that identifies a "chess" service
   (<audio>false</audio> <chess>true</chess>).

- These two tuples really represent different UAs, but in each case
   it is the AoR that is included as a contact in the tuple

- Bob looks at the entry for Alice in his buddy list, and selects
   the IM tuple to initiate a call.

How do you see this working? I guess your assumption is that this is no 
problem. If an INVITE arrives at the proxy with an offer for audio the 
proxy will send it to voice service, while one with an offer for chess 
protocol.

But suppose it is a 3pcc controller that is sending the invite, and it 
has chosen to send the invite without an offer. What can the proxy do now?

The best it can probably do is fork the invite. If so, the voice app 
would perhaps respond with a 18x with an offer of audio, while the chess 
app would respond with a 18x for chess. If so, Bob's UA could cancel the 
chess dialog and keep the one with the voice device.

But it is also possible that the chess app would respond immediately 
with a 2xx. If so, you indeed end up talking to a chess service. How 
would you propose to solve this problem?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jan 2005 17:56:00 -0500

> compromise proposal on unique URI that may be more palatable than my 

I *think* I'm ok with this, as long as it is specified that <contact> 
and <i-belong-to> are mutually exclusive.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jan 2005 17:56:15 -0500

Caller preferences would be one mechanism to address this at the 
signaling level. I don't think relying on SDP inspection is particularly 
helpful.

Paul Kyzivat wrote:
>> selection of which service to invoke. Invoking the service then 
>> involves more than a simple "clicking the contact", since in the case 
>> of SIP the watcher generally will e.g. construct an SDP offer that 
>> matches the service that the watcher thinks the tuple is describing.  
>> I believe the

---

From: Aki Niemi <[email-masked]>
Date: Tue, 11 Jan 2005 12:59:02 +0200

Ahh, the notorious 3pcc, offerless INVITE scenario... I've always been a 
bit suspect of this working in an environment that isn't voice-centric.

How to make the 3pcc scenario work? Well, if the watcher can't live with 
the uncertainty that it brings, and the very real possibility that they 
get an offer containing chess when they really wanted voice, then simply 
don't send an offerless INVITE!

3pcc seems equally broken in this scenario, regardless of whether AoRs 
are used with presence or without presence, e.g., typed in from a 
business card.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Tue, 11 Jan 2005 15:17:23 +0200

Hi Jonathan,

Inline.

ext Jonathan Rosenberg wrote:
>> actually solves the real problem; it does however reaffirm the 
>> statement made in the data model that unique contacts URIs are 
>> required in service tuples. The primary motivation for this 
>> requirement seems to be that it enables overriding service elements.
> 
> 

All right, let's continue this discussion there.

..snip..

>> uniqueness of service URIs, will watchers generally be confused if 
>> they encounter service tuples with the same contact? I don't think so, 
>> as long as the watcher does the following:
>>

Sure it does. Q-value (the priority attribute, that is) is the 
service-independent, presentity-provided preference. Unless I've totally 
misread PIDF, the priority attribute is used to indicate to the watcher 
the preference with which the various communications channels employed 
by the presentity should be used. It doesn't prohibit selecting a tuple 
whose priority is not the highest.

>> characteristics and service URIs to determine what service the tuple 
>> is describing
> 
> 

I'm assuming that each tuple needs to carry meta-information (e.g., 
prescaps) that unambiguously identifies the offered service. Otherwise, 
a watcher could select a GRUU contact with a misinterpreted service, 
causing for example an IM agent to receive a voice invitation. This 
could happen for example with a barebones SIP user agent that has 
limited understanding of the meta-information.

This assumption has to hold regardless of whether we stick to the URI 
uniqueness rule or not. In fact, an AoR contact is less prone to errors 
caused by watcher misinterpretation, since any false selection decision 
made by the wathcer can still be recovered, if for example, the INVITE 
is received by a dispatcher that has a suitable helper application.

So, agreed the above step is "magic", but I was under the assumption 
that we were defining this magic in the form of prescaps, and other 
similar markup.

> contacting the URI. If it is, the URI becomes meaningless.

I agree, but you sound like you would be in favor of AoR contact over a 
GRUU contact here. After all, a GRUU really needs a context to be all 
that useful. Without one, e.g., going through my call-logs from last 
month, there is no guarantee that a GRUU used then would work any more, 
or indeed work for any other session than the one made back then. AoR 
has that property in a sense that it can be expected to work independent 
of time, place and type of session.

Also, there are always (at least) two participants in a call and both 
have their preference over which media to use. Surely the watcher also 
has a say in what sort of media to commit to. This may not be that 
evident in todays UAs that predominantly offer voice-only.

>> I believe the invoking of a service MUST work using an AoR. If an 
>> INVITE offering voice ends up served by a chess application, I think 
>> the system is utterly broken, and needs to be fixed.
> 
> 

Aren't you forgetting something here, namely an SDP offer that (usually 
[1]) goes along with the INVITE? To me this sounds like we have systems 
where dispatching can only work based on Request URI. But surely you can 
dispatch using a plethora of other handles, such as Require-tokens, SDP 
parameters and Subject-headers, to name a few.

I don't like the idea of making the SDP be a static description of all 
media available to the wathcer, and base service dispatch (whether done 
locally at the client or by a proxy) on information "encoded" in the 
GRUU. This seems to be the direction were heading here.

>> All and all, I still don't buy the requirement for unique service 
>> URIs. Also, I think that the default composer policy of union (i.e., 
>> collect all service tuples together intact) will take care of the 95% 
>> need, leaving out more sophisticated things like override and 

I agree this is a simpler approach, but the underlying notion of unique 
contact URIs still bugs me.

Cheers,
Aki

[1] Paul pointed out the 3pcc scenario in another message, where 
admittedly an offerless INVITE would cause problems.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Jan 2005 09:40:37 -0500

> are used with presence or without presence, e.g., typed in from a 

The problem isn't with offerless INVITE - it is with the interaction of 
offerless invite with forking. Both features frequently present problems 
on their own, and in combination things get even worse.

However, when I have no information about the AoR I am inviting, my 
expectations can't be very high. I have explicitly said that I want the 
callee to make me an offer. So if the offer is one I don't like, I must 
deal with that.

However, when I am a presence watcher, my expectations are higher. I 
have specific information from the tuple I have selected, that voice 
should be available from the address specified in the tuple. So if I 
send an offerless invite I should have a reasonable expectation that the 
returned offer will include audio. Getting an offer for chess instead 
should be surprising.

Even so, in a lot of cases this scenario will indeed do something 
reasonable. As long as all the forked calls return 1xx responses with 
offers, and don't answer too quickly, the caller will have a chance to 
cancel the ones that don't match expectations. But this rules out any 
auto-answer applications that answer on the first ring, at least in 
forking situations.

You suggest not sending an offerless invite. But whenever there is a 
3pcc involved there is a bootstrapping problem - it doesn't inherently 
know what to offer without asking one end or the other. While there is 
paranoia about B2BUAs and hence 3PCC within the sip wg, there are a lot 
of very interesting applications (such as various forms of 
click-to-dial) that can be built using this technique. We really don't 
want to break it.

A better solution in some of these cases would be to change how forking 
works. If the forking were replaced by redirection to multiple targets 
(so that the caller can do the forking locally), or if all forks were 
permitted to proceed to completion, then this wouldn't be a problem. But 
that is a discussion for another day.

Until then, I see no better alternative than to go ahead, living with 
the limitations. They will cause problems in some cases, and we will 
then be forced to deal with them. At least we will know where to expect 
them, and will know some work-arounds for them.

For you guys that don't want to use GRUUs, I think you could find an 
alternative with properties that are sufficient for your needs. For 
instance, you mignt consider adding a grid parameter to the AoR in each 
tuple, explicitly identifying the service.

	Paul

> Cheers,
> Aki
> 
> ext Paul Kyzivat wrote:
> 
>>
>>
>> Aki Niemi wrote:
>> ...
>>
>>> These steps should guarantee that the watcher can always make a 
>>> proper selection of which service to invoke. Invoking the service 
>>> then involves more than a simple "clicking the contact", since in the 
>>> case of SIP the watcher generally will e.g. construct an SDP offer 
>>> that matches the service that the watcher thinks the tuple is 
>>> describing.  I believe the
>>> utterly broken, and needs to be fixed. One fix could be using GRUUs 
>>> as contacts, but that is not the only fix, and may not even be the 
>>> best one, IMHO.
>>
>>
>>
>> OK, lets investigate how that might work. I think you assume that when 
>> I have selected a tuple, and constructed a request to it, that the 
>> request wll contain attributes of some sort that correlate to the 
>> tuple I selected, and no other. This is a bad assumption.
>>
>> How do you see this working? I guess your assumption is that this is 
>> no problem. If an INVITE arrives at the proxy with an offer for audio 
>> the proxy will send it to voice service, while one with an offer for 
>> chess protocol.
>>
>> would perhaps respond with a 18x with an offer of audio, while the 
>> chess app would respond with a 18x for chess. If so, Bob's UA could 
>> cancel the chess dialog and keep the one with the voice device.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Jan 2005 10:29:50 -0500

Inline.

Aki Niemi wrote:
[snip]
>>> they encounter service tuples with the same contact? I don't think 
>>> so, as long as the watcher does the following:
>>>
>> The point of q-value is not to say "please use this service over 
>> another service". PDM talks about this. If that were true there would 
>> be no point in advertising anything but the highest priority service.
> 

I agree with you both, and don't see what there is to disagree about.

It becomes a problem only if I do something stupid, like decide to use 
your chess service tuple rather than the voice service one because of 
q-values even though I am going to send an invite for voice.

>> This seems like the "and magic happens" step, and is exactly the one 
>> I'm worried about. There is basically no way two watchers are going to 

I don't understand Jonathan's issue here. We long ago agreed on the 
feature based identification of services. You may have a "service" that 
you call X, which is described by features A,B,C,D that it publishes in 
a tuple. I have a service Y that can work with anything having features 
A,B,C. So to me the tuple published by your service X is an instance of 
service Y. The two can communicate, so we are both happy. No magic.

>>> 4) all of the above being equal, folds all identical services 
>>> together (after all they are identical in all ways that have 
>>> relevance to the watcher)
>>>
>>> describing.
>> definitional characteristic is that you need no other context beyond 
>> the URI to use it. I should be able to make a SIP call to that URI 
>> without having seen the presence document at all, and it works to the 
>> degree that SIP itself would allow the call to proceed. Presence might 
>> help optimize by allowing me to select media streams that work out of 
>> the box, for example, but its an optimization not a requirment for 

Here I agree with Jonathan. Elsewhere I pointed out the 3PCC offerless 
invite case. But there are other cases as well. Consider the case where 
you have two tuples containing the same AoR. One is just voice. The 
other is voice+video. Because I have a video phone, and anticipate using 
the video, I choose to call your tuple that has video. But I start out 
with my video disabled because I'm polite and want to ask before using 
it. So my initial invite only contains audio. (If/when I turn on video a 
reinvite will add the video stream.)

But your proxy, thinking itself clever, looks at my offer and decides to 
send it to your audio phone. Now when I try to add video (which I think 
I should expect because your tuple advertised it), the attempt fails 
because you have no video. Yuck!

> that useful.

What is your point? Is this "context" needed in the caller or callee?

If you mean the callee, then yes, it is possible for gruu to be used in 
a way where the grid parameter indexes context stored in the callee, 
with the gruu useless once that context has been forgotten. But that 
isn't always the case. In some cases all that is necessary is that the 
gruu route to the right UA, with no added context necessary at the 
receiving end. (The grid parameter may be irrelevant.) In other cases 
the context needed at the receiving end may be encoded into the grid 
parameter.

If you mean the caller needs context, then isn't that the caller's 
problem? In the situation at hand the caller *has* context: the 
presentity and all the contents of the selected tuple.

> Without one, e.g., going through my call-logs from last 
> or indeed work for any other session than the one made back then.

I recall you brought up this point in private discussion, and I have 
been thinking about it. It is an interesting problem, but one that is in 
no way restricted to presence based calling. It is relevant to many uses 
of GRUU.

In all cases I think the caller has context other than the gruu. We may 
need to find a way to incorporate that into the call so that it may be 
incorporated in call logs.

Another possibility is that we might consider defining an encoding of 
gruus that explicitly exposes the related AoR. This would have to be 
optional, for cases when that info is not intended to be public, but in 
many cases it is not secret information.

> AoR has that property in a sense that it can be expected to work
> independent of time, place and type of session.

Remember that the original motivation for gruu was to ensure that 
transfers get to the right UA. That is still an important property. The 
use of AoR didn't work for that. The problem with call logs is going to 
exist in that scenario too.

Also, I don't understand how you are going to solve the whole range of 
problems that gruus address without using gruus. Are you simply counting 
on there only being a single UAS per AoR in your environment?

> evident in todays UAs that predominantly offer voice-only.

How is this relevant? The watcher will be looking at the tuples to find 
ones that are consistent in capabilities (including media) that it can 
deal with.

>> different have to be able to have the same AoR, but if you have the 
>> same AOR, how can you guarantee that an INVITE to that AOR is properly 

I believe there are problems to be worked out before e2e encryption can 
work in the presence of forking. But in theory the contents of the SDP 
body might not be available to the proxy. Building a system that depends 
on routing that way will rule out support for e2e security.

> GRUU. This seems to be the direction were heading here.

I'm not sure of your point here. When making an offer, the offerer 
should offer whatever media it desires to use at that time. This need 
not include every medium that could be used later in the call, or on 
some other call.

For instance, Alice might have a voice+IM client. With it she can make 
many calls containing IM, but I can only have active voice in a single 
call. She is in a voice call with Bob, but also needs to talk to 
Charlie. So, while still talking to Bob, she looks up Charlie in her 
buddylist, finds a tuple for voice+IM, and makes an IM-only call to it. 
In her IM session with Charlie she starts to fill him in. When her call 
to Bob is over, she adds voice in to the call with Charlie.

	Paul

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 12 Jan 2005 14:45:53 +0100

On Jan 8, 2005, at 6:50 AM, Jonathan Rosenberg wrote:

> Another smarter PUA would include the GRUU in the <contact>, possibly 
> in addition to <i-belong-to> with the AOR.
>
> A dumb composer can always union. A smarter composer can use the 
> service URIs in the <contact> if present, in combination with the 
> <i-belong-to> information to correlate the services together. It could 
> then produce a tuple with the AOR in the <contact> and no 
> <i-belong-to>.
>
> The current contract and meaning of the <tuple> as a service remains 
> as it is in the PDM. However, we now have the case where there is a 
> tuple describing a service that is not directly reachable. The watcher 
> knows a URI through which it might be reached, and can render or 
> combine those together in whatever way it sees fit.
>
> In the future, we could define this dispatcher service so that a 
> watcher could even learn the policy governing how the dispatch is 
> done.
>
> would allow override even for tuples with no contact (as those 
> published from a PUA not supporting gruu).
>
> Is that more palatable?

Yes, I think this is proposal is ok.

/Hisham

---

From: Aki Niemi <[email-masked]>
Date: Fri, 14 Jan 2005 23:40:14 +0200

Inline.

ext Paul Kyzivat wrote:

<snip>

>>> degree that SIP itself would allow the call to proceed. Presence 
>>> might help optimize by allowing me to select media streams that work 
>>> out of the box, for example, but its an optimization not a requirment 
>>> for contacting the URI. If it is, the URI becomes meaningless.
>  
>> I agree, but you sound like you would be in favor of AoR contact over 
>> a GRUU contact here. After all, a GRUU really needs a context to be 
>> all that useful.
> 
> 

Both.

>> Without one, e.g., going through my call-logs from last month, there 
>> is no guarantee that a GRUU used then would work any more, or indeed 
>> work for any other session than the one made back then.
> 
> 

Yes, this is something I've also thought about. It might be a good idea 
to have the presentity include as contact a URI that adds some "magic" 
token into the request. Now while the end result is similar to a GRUU, 
the mechanism would be different.

> on there only being a single UAS per AoR in your environment?

Perhaps I'm not making myself clear. I'm not against putting GRUUs in 
presence documents ever (or using them elsewhere). I'm against making 
this a *mandatory* thing, and basing composer behavior on assuming 
gruuness across the presence documents. There is a big difference.

> ones that are consistent in capabilities (including media) that it can 

Yes, and (usually) constructs a request that is aligned with those 
capabilities. It won't be a simple "clicking the link", as is somehow 
been suggested. We also have things like caller preferences to make 
these choices affect the routing of a call.

>>> same AOR, how can you guarantee that an INVITE to that AOR is 
>>> properly dispatched to the right app depending on where it came from?
>>
>>
>> Aren't you forgetting something here, namely an SDP offer that 
>> (usually [1]) goes along with the INVITE? To me this sounds like we 
>> have systems where dispatching can only work based on Request URI. But 
>> surely you can dispatch using a plethora of other handles, such as 
>> Require-tokens, SDP parameters and Subject-headers, to name a few.
> 
> 

Proxy /= dispatcher, I've never said that. A dispatcher is an element 
that handles "routing" way after the messages have been decrypted.

>> media available to the wathcer, and base service dispatch (whether 
>> done locally at the client or by a proxy) on information "encoded" in 
>> the GRUU. This seems to be the direction were heading here.
> 
> 

Then we agree.

> to Bob is over, she adds voice in to the call with Charlie.

I just don't see these types of scenarios 100% representative of how 
presence will be used. There are other issues as well -- Alice might not 
see that Charlie has both IM+voice, but when in a session, this 
combination is actually present.

The reason we should be certain of 100% representation is that mandating 
the GRUU approach rules out other otherwise valid approaches.

Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jan 2005 01:40:25 -0500

Please read my note that I sent this evening with another potential 
compromise position before reading my response below.

inline.

Aki Niemi wrote:

>>>> without having seen the presence document at all, and it works to 
>>>> the degree that SIP itself would allow the call to proceed. Presence 
>>>> out of the box, for example, but its an optimization not a 
>>>> requirment for contacting the URI. If it is, the URI becomes 
>>>> meaningless.
>>
>>  
>> invite case. But there are other cases as well. Consider the case 
>> where you have two tuples containing the same AoR. One is just voice. 
>> The other is voice+video. Because I have a video phone, and anticipate 
>> using the video, I choose to call your tuple that has video. But I 
>> start out with my video disabled because I'm polite and want to ask 
>> before using it. So my initial invite only contains audio. (If/when I 
>> turn on video a reinvite will add the video stream.)
>>
>> But your proxy, thinking itself clever, looks at my offer and decides 
>> to send it to your audio phone. Now when I try to add video (which I 
>> think I should expect because your tuple advertised it), the attempt 
>> fails because you have no video. Yuck!
>>
>> If you mean the callee, then yes, it is possible for gruu to be used 
>> in a way where the grid parameter indexes context stored in the 
>> callee, with the gruu useless once that context has been forgotten. 
>> But that isn't always the case. In some cases all that is necessary is 
>> that the gruu route to the right UA, with no added context necessary 
>> at the receiving end. (The grid parameter may be irrelevant.) In other 
>> cases the context needed at the receiving end may be encoded into the 
>> grid parameter.
>>
>> been thinking about it. It is an interesting problem, but one that is 
>> in no way restricted to presence based calling. It is relevant to many 
>> uses of GRUU.
>>
>> In all cases I think the caller has context other than the gruu. We 
>> may need to find a way to incorporate that into the call so that it 
>> may be incorporated in call logs.
>>
>> optional, for cases when that info is not intended to be public, but 
>> in many cases it is not secret information.
> 
> 

So you want something with all of the same properties as gruu, but isn't 
the current mechanism? Sounds like you have a beef with GRUU. I'd like 
to understand what it is, and ask that you please bring it up on the sip 
list.

>> transfers get to the right UA. That is still an important property. 
>> The use of AoR didn't work for that. The problem with call logs is 
>> going to exist in that scenario too.
>>
>> problems that gruus address without using gruus. Are you simply 
>> counting on there only being a single UAS per AoR in your environment?
> 
> 

Per my other proposal, if folks agree, the data model will allow this, 
but you really want to be explicit on how the watcher is making a choice 
if its not by URI selection. Otherwise, the meaning of the document is 
ambiguous.

>>> have their preference over which media to use. Surely the watcher 
>>> also has a say in what sort of media to commit to. This may not be 
>>> that evident in todays UAs that predominantly offer voice-only.
>>
>>
>>
>> How is this relevant? The watcher will be looking at the tuples to 
>> find ones that are consistent in capabilities (including media) that 
>> it can deal with.
> 
> 

This is a big, big assumption. It is one I am loathe to hard code into 
the data model, since I do not want to ever specify watcher behavior. If 
you want to tell the watcher that it needs to do something besides 
clicking on a link (like using caller prefs or setting its SDP in some 
way), then PLEASE let us be explicit about it!

>>>>> INVITE offering voice ends up served by a chess application, I 
>>>>> think the system is utterly broken, and needs to be fixed.
>>>>
>>>>
>>>>
>>> have systems where dispatching can only work based on Request URI. 
>>> But surely you can dispatch using a plethora of other handles, such 
>>> as Require-tokens, SDP parameters and Subject-headers, to name a few.
>>
>>
>>
>> I believe there are problems to be worked out before e2e encryption 
>> can work in the presence of forking. But in theory the contents of the 
>> SDP body might not be available to the proxy. Building a system that 
>> depends on routing that way will rule out support for e2e security.
> 
> 

That is one type of dispatcher. I think a proxy is reasonably described 
as a dispatcher as well.

I am starting to believe that there is definitely some merit in a more 
comprehensive description of a generic dispatcher concept in the data 
model. It would allow us to cover several cases:

   1. a proxy with any kind of routing logic
   2. code in the UA that dispatches to "helpers"
   3. getting different versions of some content based on the 
content-language header (hennings example)

The key to all of these working is to allow the dispatcher information 
in the document to explicitly tell the watcher how the dispatch is done. 
If you do that, I dont think it matters much whether the dispatcher is 
actually a proxy, code in a UA, or whatever.

> 
>>> I don't like the idea of making the SDP be a static description of 
>>> all media available to the wathcer, and base service dispatch 
>>> (whether done locally at the client or by a proxy) on information 
>>> "encoded" in the GRUU. This seems to be the direction were heading here.
>>
>>
>>

I do not think we should specify that the watcher should have to adjust 
its offer in any way just because the prescaps in the document says a 
capability is there or not. If dispatch is taking place based on some 
information in the document, we should state it explicitly in the document.

Thanks,
Jonathan R.