[OpenSER-Users] case sensitivity with avp_db_load

[Jiri Kuthan]

At 16:37 19/10/2007, Klaus Darilion wrote:
>Jiri Kuthan wrote:
>>At 12:52 19/10/2007, Daniel-Constantin Mierla wrote:
>>
>>>On 10/19/07 13:35, Jiri Kuthan wrote:
>>>>I think the fundemental error here is you look up users by URI as opposed to a unique identifier. -jiri
>>>> 
>>>Well, the issue remains, how you lookup the unique id. You need to do it via username and/or parts of the sip message. You can load avps or do any other operations using unique ID in openser, for some time now, that  is not an issue. Apart of that, there are other values that are used in the config or modules, that may, or may not require case insensitive comparison and one cannot assign unique id for each.
>>What I consider a proper behaviour is 1) getting usernames into a normalized string form (%-escapes, upper/lower-case, local
>>   naming policies, internatilization, ettc., etc.)
>>   - failure not to do so is likely to result in mismatch
>
>Thus, regardless if your setup is based on UUIDs or username at domain we have to find a way to make step 1.

Yes. Partially, that's domain policy (such as ignoring case or not), partialy that's
protocol thing (e.g. escape codes)

Still, it is just the step one which deal with letter canonization, in the next
level canonization of the whole names is due.

>What about having AVP-translations for converting to lower/upper case?

Not sure what you mean -- a function like bring_to_lowercase($uri.username) ....
it may be actually reasonable to bring this canonization step in scripting as
opposed in some module parameters (I generally like a more explicite way of
expressing the policy).

Anyhow -- just to solve your specific mini-problem, it would be worth looking
if there is a case-sensitive option in usrloc/registrar in openser. It used to 
be in SER and chance is good openser has inherited in. In SER the option was
removed from registrars/usrloc since they operate over IDs and URI->id functions 
are today hirdwired case-insensitive, even though it is not the best reflection
of it being actually a subject to administrative policy. I would favor doing it
out of script as you suggest better.

-jiri




--
Jiri Kuthan            http://iptel.org/~jiri/