Subject: RE: [Sip] Question regarding instance ID in GRUU and outbound

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Aug 2006 08:09:45 +0100

Furthermore, a UA that is in the habit of registering in more than one
domain (in support of mobility, hot-desking, or whatever) would need to
remember multiple cookies - gets complicated.

John 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 09 August 2006 22:35
> To: Aki Niemi
> Cc: sip
> Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound
> 
> Aki,
> 
> Can you point to anything wrong with the current approach? The only 
> evidence of a problem that I saw in this discussion was that 
> it would be 
> harder to implement UUID URN than a cookie mechanism. YMMV on 
> that one.
> 
> Consequently, if it aint broke - don't fix it. I am loathe to 
> reopen the 
> whole gruu/outbound design technique without a concrete problem being 
> identified.
> 
> I also think its easier for a server to remember an instance 
> ID to GRUU 
> binding for a long time, than it is for a client to remember 
> its cookie 
> for a long time AND for the server to remember the cookie to GRUU 
> mapping for a long time. GRUU persistence would depend on a client 
> remembering its cookie basically forever. GRUU currently 
> doesn't require 
> persistent storage of any soft state in the client.
> 
> -Jonathan R.
> 
> Aki Niemi wrote:
> 
> > Howdy,
> > 
> > I read GRUU and outbound, and an old nagging concern of 
> mine resurfaced:
> > what the heck do we need the instance ID for?
> > 
> > Seems outbound uses it to guarantee uniqueness of flows in 
> a registrar,
> > but to me it sounds weird that the task of acquiring unique 
> IDs within
> > the registrar's internal state is left to the UA -- after 
> all, browsers
> > don't generally generate cookies themselves but store whatever the
> > website gives them.
> > 
> > To me, a much better approach would be to have the 
> registrar generate
> > and allocate a unique ID (perhaps the 'opaque' used in 
> GRUU?) for the
> > first REGISTER, and whenever a client registers with that 
> ID again, it
> > is deemed the same UA. A REGISTER without an ID would be another UA
> > instance.
> > 
> > Even DHCP clients' leases seem to survive reboots without 
> some weird URN
> > generation, so I don't think that it's unreasonable to 
> require UAs to
> > store their outbound IDs either. I mean, they already have 
> to store the
> > reg-id, no? (Not to mention web cookies...)
> > 
> > And worst case is you need to garbage-collect some stale 
> flows, in case
> > a UA happens to forget its ID, but that you need to be doing in any
> > case.
> > 
> > We chose a similar approach over instance ID in PUBLISH, which uses
> > etags generated by the server to identify uniqueness of publisher
> > instances. With PUBLISH, UAs are also instructed to remember their
> > etags, even across reboots.
> > 
> > Cheers,
> > Aki
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.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
> 

_______________________________________________
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: Aki Niemi <[email-masked]>
Date: Thu, 10 Aug 2006 19:08:15 +0300

> remember multiple cookies - gets complicated.

No more complicated than storing user credentials per AoR (and yes, all
of the UAs I've ever used -- black, soft, hard, mobile, or otherwise --
do this already. 

Plus (I assume you're talking about sip-outbound) I consider the
persistent storage of the flow identifier as only a recommended courtesy
in helping the registrar invalidate flows that would otherwise be left
dangling because of a UA reboot.

Cheers,
Aki
 
-- 
Aki Niemi
Nokia Research Center

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Aug 2006 13:18:54 -0400

Aki,

Another point to make.

I think your model is that, because the UA has a perpetual instance ID, 
it is also the one that generates it. THis need not be the case. I view 
the instance ID a lot like the kinds of device identifiers we see in the 
mobile world. When a provider orders a batch of phones, they each come 
with a unique instance ID burned into firmware at the factory. Those get 
read into a database and when the phones are given to a customer, you 
can establish a link between the instance ID and the subscriber if you 
want.

Consequently, when the REGISTER shows up, this is not some random 
instance ID that would never have been seen. It would have been known by 
the provider well ahead of time.

Of course, the GRUU model also allows for cases where the phone does in 
fact djinn up its own instance ID, for softphones in particular this 
will be a requirement.

Another unrelated point - though you don't necessarily need the 
persistence of the instance ID for sip-outbound, I much prefer the model 
where we define this concept of a UA instance identifier, and then reuse 
that in various places where that property comes in handy. That is 
better than defining similar types of identifiers in each and every 
other protocol that needs something roughly the same.

Thanks,
Jonathan R.

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