Subject: RE: [Sip] SIP instance identifiers

From: "Brian Stucker" <[email-masked]>
Date: Mon, 16 Feb 2004 09:57:20 -0600

Johnathan,

I'm not opposed to the client ID being transported in the registration
contact,
but seeing as there were two drafts that already discuss that, I didn't see
much point in rehashing it again in my draft. =)

I believe there are some important points that you're leaving out. 

Besides being client generated (which reduces the requirements for
generating
the ID) there are advantages to NOT mandating that the ID be expressed only 
as a parameter in the contact of a registration. 

The idea behind the GUID (and hence the lack of a specific usecase in the
-00 version of the document) is that it can be used for other activities. 
I'm not opposed to communicating the ID in a contact parameter as well as
a regular header, I just don't view transporting it in a contact header
as being always necessary or desirable depending on what you want to do
with it.

Sending it as a header allows for some interesting behavior to occur on 
non-registration requests:

- Can be used to eliminate duplicate subscriptions due to client's state
being wiped out (ie. ignore the callid/tags of an existing subscription
if the client ID matches the client ID of that subscription [and the other
information about the subscription is the same]).
- Can be used to identify the client sending a request across networks
where no other identifier is easily obtainable (NATs and the such), or 
BBUAs are present in the network.
- Can be used to identify the source of state information being pushed
into the network (presence update, etc). This is one area where conveying
the information in a contact seems a little cumbersome. The request may 
not be sent to the registrar, and a contact may otherwise be completely 
unnecessary.

In the cases where registration behavior is controlled, it requires a change
to the registrar in order to capture the appropriate behavior that should be
taken wrt a client ID. Therefore, including the information as a header or
in the contact seems moot to me as either mechanism can easily be made to 
work. Perhaps there's a usecase I'm not considering?

Additionally, I believe that there needs to be some convergence on the
approach
taken by generating the identifier itself. The mechanism that is suggested 
in your draft seems to rely upon a server to generate the unique identifier,

whereas in the other two drafts, it is the client that generates the 
unique identifier. I believe there are advantages to each. 

Regards,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Sunday, February 15, 2004 7:48 PM
To: [email-masked]
Subject: [Sip] SIP instance identifiers

Folks,

We have three drafts this round that all propose a way to define an 
instance identifier for a UA:

http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt
http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.tx
t
http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt

all three are similar. Mine uses a contact header field parameter, and 
uses the callee capabilities framework to enable caller preferences 
routing based on instance iDs. Cullen also uses a contact parameter, but 
not within the callee caps framework. Brian defines a header field.

I think we generally understand the requirement here, though it would 
probably be good to obtain use cases to be sure. The design choice is 
where to include this parameter, and this represents the difference 
between the three approaches.

I tend to prefer a Contact URI parameter over a header. My main reason 
for that is REGISTER requests. If a register request has multiple 
contacts, which contact does the instance identifier apply to? As a 
header field, it would be hard to know. If you make it a contact header 
field parameter, its no problem. Those header field parameters could 
also then be used in the Contact in INVITE/200 SUB/NOT, etc.

Then, the question is whether to use a regular Contact header field 
parameter as Cullen has done, or a callee cap parameter as I have done? 
The callee cap approach allows for caller preferences to be applied to 
routing to a specific instance. Now, a good question is whether such a 
thing is needed or even a good idea, if we have GRUU as the ideal way to 
route to a UA instance. I can go either way, but welcome thoughts on the 
topic.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Feb 2004 15:53:56 -0500

inline.

> as being always necessary or desirable depending on what you want to do

I think the key thing we need to do first is figure out what it is we 
want to do with it (i.e., requirements!). I am principally interested in 
its usage with GRUU. In that usage, it is necessary to be carried in the 
contact header.

> information about the subscription is the same]).

I'm not sure this is good behavior though. Its perfectly fine to have 
two subscriptions to the same thing from the same UA instance. If the 
state is wiped out and the client sends a second subscription, the first 
will either time out, or if the server sends a NOTIFY, the NOTIFY will 
time out or generatea a 481, both of which terminate the first 
subscription. This behavior seems fine.

> BBUAs are present in the network.

OK, but whats the use case?

> not be sent to the registrar, and a contact may otherwise be completely

OK, this is a fair point. There does appear to be a need in PUBLISH 
(more in pidf I think) for having a unique identifier of the source of 
the publication.

> work. Perhaps there's a usecase I'm not considering?

If you put it in a header, you would need to include additional 
parameters to correlate it to the specific Contact in a registration 
that it applies to. This can work, but its messy and unnecessary if you 
include the guid in the contact directly.

> in your draft seems to rely upon a server to generate the unique 

No, the instance ID is generated by the client. I just don't say how. I 
think there are specs that give guidance on generating unique IDs. I 
couldnt find an rfc reference, maybe it was somewhere else, but this is 
well-trod territory. I dont think our requirements for unique 
identifiers are different than anyone elses.

> unique identifier. I believe there are advantages to each.

I think the client has to generate it always.

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Feb 2004 07:31:28 -0800

I can imagine cases where we might want to be able to route by the instance
ID. I think the +sip.instance approach is a better than the general contact
header I proposed. It provides more options for routing and has no
disadvantages.

Cullen

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Feb 2004 12:11:21 -0600

Based on the discussion of "routing" based on instance identifiers, I 
think we may be getting involved in triggerwork that may become more 
complex than is actually required, because we're all reasoning from 
secondary positions. So I'd like to take a step back and consider how we 
got here, and what we think we're trying to accomplish.

I see four high-level cases around request routing that illustrate 
different aspects of this discussion.

1) General case: We wish to address a request to an AOR, such that any 
contact at that AOR might respond. This is basic 2543-type routing behavior.

2) Capability case: We wish to address a request to an AOR, such that 
any contact capable of satisfying the request in a way that we like 
might respond. This behavior is brought out in callee-caps and 
caller-preferences and the accept/supported/required syntax of 3261.

3) Followups to a specific instance: We have previously done something 
(such as case 1 or 2) such that the operation of interest has resolved 
to a specific contact instance associated with an AoR, and we wish 
subsequent operations (for example, a transfer) to reach that same 
specific contact instance, even if that specific contact instance is 
hidden behind an indirection layer (firewall, anonymizer, etc.). As I 
understand it, this is the heart of the GRUU concept.

4) Selection of a specific instance in an initial request: We have a 
request that we wish to reach one specific instance of a contact 
associated with an AoR. It has been proposed that we accomplish this by 
binding some sort of instance tag to the AoR. It has been proposed that 
we use some sort of URI convention (like the msuri), +based 
subaddressing, or that we use a header convention for binding the 
instance tag to the AoR. To my knowledge, we haven't really described 
the requirement or use case for reaching a specific instance on an 
initial request, but I can think of several offhand (including diagnostics).

It seems evident that there is a huge overlap between the requirements 
of 3 and 4. Indeed, I think #3 (GRUU) came out of early ideas I had on 
using a REGISTER-response extension to assign an instance-AoR to a 
Contact. It would appear that IF each contact for an AoR were to have an 
associated GRUU, and that knowledge of those GRUU assigments were 
available to a requestor, that the requester could use the 
target-specific GRUU to achieve the use cases I currently imagine for #4.

What am I missing here?

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Feb 2004 23:58:01 -0500

inline.

Dean Willis wrote:

> secondary positions. So I'd like to take a step back and consider how
> we got here, and what we think we're trying to accomplish.
> 
> 1) General case: We wish to address a request to an AOR, such that 
> any contact at that AOR might respond. This is basic 2543-type 
> routing behavior.

Well, I prefer 3261-style, but yes.

> caller-preferences and the accept/supported/required syntax of 3261.

Right.

> 
> 3) Followups to a specific instance: We have previously done 
> something (such as case 1 or 2) such that the operation of interest 
> has resolved to a specific contact instance associated with an AoR, 
> and we wish subsequent operations (for example, a transfer) to reach 
> that same specific contact instance, even if that specific contact 
> instance is hidden behind an indirection layer (firewall, anonymizer,
>  etc.). As I understand it, this is the heart of the GRUU concept.

Yes.

> associated with an AoR.

My proposal of using a callee capabilities parameter for instance ID
would accomplish that. However, I am not sure that its really useful, to
be honest. How would the caller know the instance ID ahead of time? Any
kind of mechanism that can transfer the instance ID could transfer the
GRUU instead, and a GRUU will be much, much, much better.

It has been proposed that we accomplish this by
> binding some sort of instance tag to the AoR. It has been proposed 
> that we use some sort of URI convention (like the msuri), +based 
> subaddressing,

I wasnt proposing that. The +sip.instance is the convention used by
callee caps for identifying Contact header parameters that are subject
to the specification.

> It seems evident that there is a huge overlap between the 
> requirements of 3 and 4.

Yes.

> Indeed, I think #3 (GRUU) came out of early ideas I had on using a 
> REGISTER-response extension to assign an instance-AoR to a Contact. 
> It would appear that IF each contact for an AoR were to have an 

Right, this is exactly what I am saying above as well.

Dean later writes, in response to Brian:
> So you see a requirement to uniquely identify a specific SIP endpoint
>  OUTSIDE of the domain of SIP routing, such that this identification 
> can support further applications?
> 
> Use cases here might include:
> 
> 1) billing -- "Alice called Bob from phone ID000001 through gateway 
> ID3344555 on Tuesday, March 1, 2011"

I do not understand the need for a globally unique instance ID to
support billing, and would be very scared of fraud issues.

> 
> 2) Debugging -- "This request was responded to by node IDYIYIOHIHIUH,
>  which is a Barfia model 9995 phone running Finux 21.05A and the
> Vocal user agent release 89.6"

I'm not sure I understand the specific value gleaned from the instance
ID in this case.

> Another approach is to limit the expression of identity herein to
> that subset of identify which is expressly describable using SIP,
> which makes it analogous to the SIP routing mechanisms underlying the
> concepts of AoR, asserted identity, and verified/vouchsafed identity
> in the various documents that touch on those concepts. In other
> words, we restrict ourselves to the namspace of SIP AoRs.

Well said.

-Jonathan R.