RE: [Sip] SIP instance identifiers

["Brian Stucker" <[e-mail]>]

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:[e-mail]]
Sent: Sunday, February 15, 2004 7:48 PM
To: [e-mail]
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
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip