Subject: [Sip] RE: Abstraction: SIP instance identifiers requirements

From: "Brian Stucker" <[email-masked]>
Date: Wed, 18 Feb 2004 01:44:04 -0600

> -----Original Message-----

<< SNIP >>

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

If the particular network implementation only hands out the ID to trusted
nodes, this is no less safe than our current authentication mechanisms IMHO.
I don't forsee using the ID as a "bill to" number, but it could be used to
help correlate billing records as a call goes through the system, in which 
case it does not matter what that value is, just that it's consistient from
hop to hop.

If you're scared of fraud issues, think about what happens when you send an
INVITE into a system with a Referred-By of some unsuspecting third-party
user
of that system. =) Much worse problem that exists today. You probably won't 
get a free call, but you might make some interesting international calls
before anyone figures out what's going on.

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

It survives BBUAs for one. Probably not the best use case, but may be
interesting for future thought. System admins will probably love to have
a consistient identifier throughout the system identifying what a 
particular endpoint did throughout a request or requests.

The specific use cases I had in mind were to recover from client crashes
where it's undesirable, and network policy to limit resource usage. For 
instance, duplicate subscriptions to the same resource for the same
event package from the same client instance. Sure, sometimes it might 
make sense (can't think of one, but let's assume that there is a case). 
That still represents network resources (ie. resources associated with
storing that subscription and handling it on state changes for that
event) and the network might not want to allow duplicates by its own
policy (tough crapola client, you only get so much). An instance ID
makes this very simple to deal with. Otherwise you're at the mercy of
the client, or the server has to guess which subscriptions it has no more
resources to handle and should eliminate.

Same goes for registrations which was pointed out on another thread. If
a client is stateless enough that it can't remember an old contact after
crashing, it may still be able to come up with a GUID that the server can
then use to figure out to eliminate the now defunct elder contact in
favor of the newer one.

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

If we take that approach then how do we solve the problems I've stated
above that exist today? How do we solve problems with generating meaningful
identifiers for clients in the reginfo+xml message body, and cpim-pidf 
message bodies? How do I determine all PUBLISHes are from a particular 
user agent when it's contact information and other aspects of the PUBLISH 
may vary over long periods of time? 

We're going to have to solve these other issues. We're going to need to 
know which client is generating these requests. It's a similar problem
space,
and with or without GRUUs, these problems are still going to exist and will
eventually need to be tackled.

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