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

[Cullen Jennings <[e-mail]>]

This email is sort of irrelevant but I'm sending it anyways :-)

A few year back, I wrote
http://www.softarmor.com/wgdb/docs/draft-jennings-sipping-instance- 
id-00.txt

and it had some use cases for why one might need a long term stable  
identifier for a device. I think theses still hold. We need something  
and it needs to survive reboots of a device. You are right it does  
not matter who generates the ID but the UA needs to store it. Cookies  
were discussed but rejected due to worries about if there was AT&T  
IPR on them.

I originally proposed something "simple" to generate - I'm a big fan  
of large random numbers. Others were less comfortable with large  
random numbers and wanted something algorithmically guaranteed to be  
unique by some sort of delegated assignment - like MAC or OIDs. Most  
devices had MAC addresses or an equivalent sort of identifier. I  
wrote something for MAC plus something for things without a MAC. It  
was looking less simple. There were problems with the multiple phones  
on one MAC that added more complexity. Pretty soon, I was reinventing  
UUID. UUID covered everything we needed and encompassed a huge set of  
existing arguments on the subject. If you remove any part of UUID,  
there is some use case that gets broken. It may be that the use case  
is bogus but none the less the argument goes on.

Anyways, I think we needs something and I can't imagine anything much  
simpler than what we have right now.



On Aug 8, 2006, at 1:49 PM, 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...)

Side issue but I think they would usually just hardcode in reg-id of  
1 for the first one, 2 for second and so on. Some devices store only  
their MAC and the configuration system uses that to know what data to  
hand down to them. I have seen some systems where the config handed  
to the phone is based only on the which ethernet port in the switch  
the device was connected to. Some residential ethernet to the home  
systems do this so that if my neighbor plugs in his phone at my  
house, it becomes my phone. In theory these systems would not need to  
really store anything.

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

of course close to none of them do :-)

>
> Cheers,
> Aki
>
>
> _______________________________________________
> 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

_______________________________________________
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