[OpenSER-Users] case sensitivity with avp_db_load

Jiri Kuthan jiri at iptel.org
Tue Oct 23 12:52:21 CEST 2007


At 18:46 19/10/2007, Christian Schlatter wrote:
>Jiri Kuthan wrote:
>>At 17:34 19/10/2007, Christian Schlatter wrote:
>>
>>>I don't understand why username at domain is not unique enough?
>>sometimes it is christian at domain.com, sometimes christian.schlatter at domain.com,
>>sometimes it is christian.schlatter at .domain.org or even worse you can take your spouses'
>>name and from day D you begin to be christian.blair at domain.org, and your company
>>gets acquired and you become christian.blair at oracle.com. (Which clients without
>>DNS/SRV can try to reach as christian.blair at sip.oracle.com, and those who pay
>>extra respect to you using capital letters as Christian.Blair at sip.oracle.com)
>>The implication to sanity of data in usrloc, accounting and other tables is immense
>>if you don't bring those to a common denominator. Any change to any name becomes
>>a real pain. The point is names do changes, use of numbers is designed to make
>>relations between tables invariable.
>
>Ok, this makes sense e.g. for foreign key relationships, 

yes.

>but isn't this more of a database specific thing?


Well, I have though of it from SER angle with mysql usage and can't easily relieve myself
from that viewpoint and may be a bit confused too -- how do you think a database-centric 
model would look like?

I understand that for example the case-sensitive bit can be set as part of DB scheme
definition -- is that the kind of things you have on your mind?

In which case a counter-argument would be, that case-sensitiviness is a matter of local
policy (i.e. app) which is more dynamic (e.g. per-domain) than schema definition is.
How would a DB-specific way of dealing with things handle multiple aliases?
(cs|christian|....)?

If that's it, what is the division line between app's and databases responsibility?

> We are using our university's LDAP based identity management system to manage SIP accounts, and openser accesses this system directly through H.350. Our assumption is that the SIP proxy shouldn't care about identity management at all, so it doesn't care if it is christian.blair at domain.org or christian.blair at oracle.com.

I'm not sure what it means it doesn't care.... who does resolve aliases
for users (cristian|cs) and domains (.net|.com) so that whatever comes out
of it can be matched to for example accounting data? who take care of
case-sensitivness?


>You're raising a good point, but I think identity management should not be done in the SIP proxy.

Actually what is "identity managment" -- it became a bit too popular expresssion
so that its meaning is a bit fluid to me... anyhow, I will be thankful for any hints.
Identity is indeed very important.



>>>According to RFC 3261 section 19.1.4, SIP usernames are case sensitive, so you actually shouldn't convert them to upper/lower-case. 
>>That's a protocol thing. An example implication is that you shall not forward SIP request
>>to other domains whilst changing the URI.
>>However, if you are processing a request for your domain, you own the username and the way
>>you process it is subject to your policy. You can use an LDAP alias to expand to
>>other URI, you can do call-forwarding by rewriting the URI to something completely
>>else, you can expand a speed-dial to a full URI, you can do anything you desire
>>with the username you own. I personally prefer to ignore case, but the key point
>>is you are allowed to and should set a coherent policy on how you deal with names.
>
>I had to find out the hard way that asterisk is treating SIP usernames case sensitive which lead to the decision that it is the safest to handle SIP usernames case sensitive everywhere.

It is actually a reasonable policy (at least from my POV), but a policy should not be hardwired in code.

-jiri


>Your're right though that this is a matter of local policy.
>
>/Christian
>
>>>And user/domain aliases is a different issue since it always involves some kind of alias mapping lookup.
>>That's the separate things following the same scheme indeed. If you don't want to
>>do a data migration story on any name change, use IDs, for example UUIDs.
>>-jiri
>>
>>>/Christian
>>>
>>>>See above inline for what happens when you do it other ways. In any case
>>>>that's how unambiguous behaviour shall be achieved in a "water-proof" way.
>>>>
>>>>>So, I do not see any fundamental error here, given the subject of the discussion.
>>>>looking up user data by his username as opposed to by id is just very poor idea,
>>>>let's face it. (those familiar with unix may find too that usernames are used
>>>>as input/output user-interface thing, but the OS actually operates over numbers)
>>>>The funny part is that getting things right is apparently not a big deal in this
>>>>case, but getting it wrong can cause big headaches.
>>>>I am not sure though what of it is coding and what of it is configuration thing in openser, I'm sure some will know.
>>>>-jiri
>>>>
>>>>
>>>>--
>>>>Jiri Kuthan            http://iptel.org/~jiri/
>>>>
>>>>_______________________________________________
>>>>Users mailing list
>>>>Users at openser.org
>>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>--
>>>Jiri Kuthan            http://iptel.org/~jiri/
>
>
>
>--
>Jiri Kuthan            http://iptel.org/~jiri/





More information about the Users mailing list