Subject: RE: [Sip] SIP instance identifiers

From: "Brian Stucker" <[email-masked]>
Date: Mon, 16 Feb 2004 15:13:06 -0600

inline some more.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, February 16, 2004 2:54 PM
> To: Stucker, Brian [NGC:B617:EXCH]
> Cc: [email-masked]
> Subject: Re: [Sip] SIP instance identifiers
> 
> 
> inline.
> 
> Brian Stucker wrote:
> 
> > 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.
> 
> 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.
> 

I'm open to a number of requirements, but simply constraining the set of
things we ought to try to tackle simple to what's in GRUU seems to miss
the opportunity to kill multiple birds with one stone. I'd like to see
a solution that encapsulates as many usecases as possible, and I'm not
adverse to the idea of carrying the ID in the contact header itself. I
just don't think that's the ONLY place it makes sense to send 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]).
> 
> 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.

Sometimes it's OK, sometimes it's not. Let's give ourselves the option
to choose when we want this type of behavior (which I would think would
generally be rare considering we'd be sending an extra NOTIFY and holding
onto a subscription for no apparent reason). Using an ID to uniquely 
identify the client can help to reduce unwanted traffic. Is it the only
way it can be done? No. But it is a handy way to do it if we're not
adverse to including this type of information in requests.

> 
> > - 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.
> 
> OK, but whats the use case?

Can be used to correlate requests from the same client where IP
addresses may not be available at all nodes, and the context-matching
information may have been jumbled by a BBUA. Can use useful for matching
up calls to other non-call transactions, etc.

> 
> 
> > - 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.
> 
> 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.
> 

Glad we agree on something. =)

> > 
> > 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?
> 
> 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.
> 

This is a good point. In that case it makes sense to put it into the
contacts for the registration, but once again, I'm not trying to exclude
this option in my draft. It was already discussed elsewhere, so there seemed
no need to go back over it.

> > 
> > 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,
> 
> 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.
> 

True enough. I just wanted to put in some ground-rules so we avoid some
of the troubles that you find in poor implementations of callid/tag
generators
for the SIP stack. Sometimes it's helpful to put a baseline out there so
people
are at a minimum cognizant of what they're getting themselves into that may
not otherwise be obvious to the implementor.

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

Sometimes it makes sense for the server to generate it, especially if the 
server is a trusted third-party and the ID is used for some sort of
non-repudiation
tactic. 

> 
> -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
>

---

From: "Orit Levin" <[email-masked]>
Date: Mon, 23 Feb 2004 13:19:15 -0800

Whatever the overlap in our views is, what is in the scope of this
discussion and what is out of the scope - is a point of view based on
the applications each of us is familiar with.

If we 
- have both the GRUU concept and the GRID concept as URI parameters
- allow a user to allocated its own device identifier (which needs to be
"globally" unique within its AOR scope only)
- allow a Registrar to override the user allocated GRUU and replace it
with Registrar generated value (if required according to local policies)

it will satisfy the requirements of the applications that I am familiar
with.

Orit. 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, February 23, 2004 11:36 AM
To: Orit Levin
Cc: [email-masked]
Subject: Re: [Sip] SIP instance identifiers

Orit Levin wrote:
> I tend to agree with Paul (if I read him correctly).

I think maybe you don't read me as intended, because I don't entirely
agree with you here. (At least if I understand you.)

> I think that GUID and the original GRID parameter are very different 
> things because of their properties (and obviously the resultant usage 
> cases).

If you are talking about the grid=xxx parameter that Jonathan has
proposed be used with GRUUs, then I don't think it has any signficance
to this discussion at all.

> Below is my view on the topic.
> 
> 1. _Global Unique ID:_ GUID IS a very well-known concept. It is used 
> by many applications outside SIP, but I don't see its direct relation 
> to SIP. I am not sure whether we need a dedicated SIP placeholder for
it.
> For PIDF applications, GRUU is enough, in my opinion (see below).

I don't know that anyone is talking about this. But we are talking about
a slightly more restricted concept - a Device ID. Conceivably a device
could use a guid as its device id, but that is largely irrelevant to
this discussion.

> 2. _GRUU format:_ GRUU (not GRID or GUID) is a SIP URI and is very 
> SIPish concept with the properties as defined in the GRUU draft. It IS

> the "SIP Instance Identifier".

The last sentence is debatable. It is *an* endpoint instance identifier
that is sip routable. But it isn't necessarily defined for as long as
the device(s) it references are. And it isn't necessarily bound to the
same device at all times.

I think you may have missed the point that the device id is distinct
from the GRUU, though dependent upon it. Many different GRUUs may share
the same device id. I am proposing that the device id be represented as
a URI, but not necessarily (generally not) a sip uri. Generally I expect
a URN to be used.

> 3. _GRUU signaling and usage:_ GRUU can be allocated either by 
> Registrar, or by UA, or by different means. My point is GRUU 
> identification (i.e. placement and signaling) during session 
> establishment and usage (especially outside the Registrar domain) MUST

> be identical for all cases. Moreover, it MUST be possible for the 
> Registrar domain to conceal the information about the allocation 
> method being used.
> 
> 4. _Registration Procedure:_ We need to standardize the registration 
> procedure for both basic cases: GRUU allocated by Server (done) and 
> GRUU allocated by Client. In my opinion, both cases need to be under 
> the Registration/contact umbrella - which makes them SIP concepts! 
> Whether GRUU value is preserved during client's/server's reboots - it 
> doesn't change the concept. From usability point of view, it would be 
> very nice to keep the value as long as possible. >From the outside 
> user point of view - it doesn't need to know (and doesn't want to 
> know) what the registration durability of its peers is.

Jonathan should probably chime in here. I believe he argues that
typically a UA can't tell whether it can generate its own GRUU, so they
should always be assigned by registrars.

> 5. _Saving Registration Cycles and DB size_: By using GRUU we have the

> ability to contact a specific instance of SIP AOR. Once we point to a 
> specific entity, we MAY also need to point to specific sub-entities 
> inside this GRUU. This will save the registration burden from each of 
> these sub-entities, since they will be covered by GRUU's registration 
> and routing. The original GRID parameters allowed for exactly this 
> functionality. The usage example is a conference factory which 
> generates foci and doesn't need to dynamically REGISTER each of them 
> in order to achieve proper routing. BTW, the concept of "internal 
> routing" to specific logical module inside SIP entity can be 
> generalized, decoupled from GRUU and be defined as a dedicated SIP
header.

Maybe it can be decoupled from GRUU, but I think it must be coupled to a
URL, not a message. So it must be a URL formatting convention and/or a
url parameter. So maybe you could generalize the grid parameter to apply
to all sip/sips urls, rather than coupling it to gruu. I haven't thought
thru where that might be useful.

	Paul

_______________________________________________
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