[sr-dev] rfc: unique id for profiles

[Jan Janak]

On Tue, Mar 13, 2012 at 04:53, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Hello,
>
> from the last IRC devel meetings discussions, one topic was about adding an
> unique id field per user profiles, with the decision to bring it to mailing
> lists for broader audience.
>
> That will help to reference easier across records. At this moment, the most
> relationships are via (username) or (username,domain) when use_domain=1,
> bringing some complexity.
>
> The main reasons I came up to this were:
> - in the perspective of gruu implementation for usrloc, with global
> addresses, an unique (opaque) id seem to simplify things, no matter SIP
> address of the user changes or not -- the public gruu id can be different
> than the internal one, though

Yes. Also, being able to deal with changing SIP addresses is not
strictly GRUU specific. This comes in handy in other situations, for
example, when a user wishes to change his/her SIP identifier as result
of spam or other changes.

Having a unique ID that never changes then makes it possible to
correlate records across tables even in such situations. This is
useful, for example, for acc records.

> - it will open a new group of K and S modules for merging, S using unique
> ids mostly everywhere

Generally, S uses uid to identify users and did to identify domains.
The uid is supposed to be unique and never to change, regardless of
what SIP URIs the user represented by the uid uses.

We even use the same concept for domains, where each "virtual" domain
is represented by did and can have multiple domains assigned to it.
You may want to consider this as well. if you do I should let you know
that choosing "did" as the name of the field was a bad idea (I didn't
know it had another meaning in the PSTN world at that time).

> Moving towards it will be done gradually, keeping backward compatibility for
> a while. The first steps will be to add new column in few tables
> (subscriber, location), the username/domain columns will stay there forever
> in most of the cases, they will become additional info over the time (e.g.,
> primary sip address in subscriber).

In some cases, e.g., the location table, you'll need to keep them
around anyway because some of the operations done on contacts need to
work only on contacts for a specific Address of Record (AOR).

> From the point of view of filling up the column, can be as simple as setting
> it to username at domain, or generate some unique string with tools out there.

Yes. Keeping this flexible would also make it possible to obtain such
unique identifiers from an existing 3rd party database, for example,
when you're integrating a SIP server into existing infrastructure for
a customer.

> Overall, there will be a bit more db space used at the benefit of reduced
> complexity in the code. Jason Penton mentioned that IMS architecture relies
> also on unique ids.
>
> Looking forward to comments, alternatives, etc ... sr-users community was
> cc-ed because it is not strictly technical discussion/decision.

Feel free to look into the S database schema for an example. That
schema adopted this approach for pretty much all tables. I'm not
saying you should do it the same way though, there may be better ways.
If you have any questions regarding what's being done there, send me
an email.

With uids in the database, the question how to map SIP URIs to uids
(and vice versa) and where to keep them while a SIP message is being
processed comes to mind.

-Jan

>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla
> Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
> http://www.asipto.com/index.php/kamailio-advanced-training/
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev