#595 usrloc stores username in lowercase in "location" table

[Asgaroth]

I am trying to integrate Kamailio (1.5.3-notls) into our existing
database structure using a view for the subscriber table and using the
location table to store the registration information.

I am successfully able to register a phone using this method.

One of our requirements is to set an "outboundproxy" and
"outboundproxyport" parameter in the location table for a particular sip
account (username). I am trying to do this with the sqlops module.

What I have come across though is that when the registration information
is saved to the location table the username is stored in lower case. So
when my sqlops query is run against the username it does not match.

For example, in the subscriber table I have view defined that for my
user account returns the following information:

-------------
select * from subscriber where username = 'BruceNW9440';
username | domain | password | ha1
| ha1b
-------------+---------------+------------+----------------------------------+----------------------------------
BruceNW9440 | 10.10.10.10 | 00minger00 |
1f2d688f65be04a61cab36a1fb3f426a | 6529d45f5c418daf35be7b3dd4a858cb
(1 row)
-------------

Now, if I check the above against the location table:

--------------
select * from location where username = 'BruceNW9440';

0 rows returned
--------------

If I run the same query using "brucenw9440" as the username (lowercase)
then the correct information is returned.

I have the following log line in my kamailio configuration script:

xlog("L_INFO","Username: $au, OutboundProxy: $Ri, OutboundProxyPort: $Rp");

The details of this log appear correct when it is logged:

Dec 9 14:21:03 ibis /opt/kamailio/sbin/kamailio[16972]: [ID 197553
local0.info] Username: BruceNW9440, OutboundProxy: 10.10.10.10,
OutboundProxyPort: 5060

However, when my sqlopt query is run it does not find a match because of
the incorrect case:

sql_query("bfl", "UPDATE location SET outboundproxy = '$Ri',
outboundproxyport = '$Rp' WHERE username = '$au'", "res");

I've had a read through the usrloc module documentation and I cannot
seem to find a reference to any options that will preserve the case. I
also cannot find if there is a parameter to save('location') that will
preserve the case. I cant seem to find a reference to the save()
function on the wiki. I must be missing something small.

[Iñaki Baz Castillo]

According to RFC 3261 BNF grammar, the username part of a SIP URI is case sensitive, this is:

sip:alice@domain.org != sip:Alice@domain.org

but domain part is case insensitive so:

sip:alice@domain.org == sip:alice@DOMain.ORG

So if 'usrloc' forces lowcase that's not correct (IMHO).

[Asgaroth]

Just for further information, here is the logic in the main route of the kamailio script that is causing the problem, I thought I would add it in so you can see where I am trying to execute the update. The actual authentication is processed prior to this section.

if (is_method("REGISTER"))
{
if (!save("location")) {
sl_reply_error();
} else {
xlog("L_INFO","Username: $au, FromUser: $fu, OutboundProxy: $Ri, OutboundProxyPort: $Rp");
sql_query("bfl", "UPDATE location SET outboundproxy = '$Ri', outboundproxyport = '$Rp' WHERE username = '$au'", "res");
}
exit;
}

[Henning Westerholt]

I can confirm that usrloc stores the name in lowercase, even if its in upper case in the subscriber table. This is probably a bug.

For the other thing, the reported case sensitivity in the query against the location table, this is defined from the database that is used. So if you would e.g. switch to mysql, all your queries would be case insensitive. So i changed the bug title to be mirror this.

[Nobody/Anonymous]

There is a parameter to control case sensitivity:
http://kamailio.org/docs/modules/1.5.x/registrar.html#id2491689

[Henning Westerholt]

I can confirm that setting the mentioned parameter fixes the usrloc insertion.

From the location table, parameter set to 0:

| testaccount.33 | 2009-12-10 16:47:21 | sip:Testaccount.33@XXXXX:5060 | sipp running on XXXXX

with parameter set to 1:

| Testaccount.33 | 2009-12-10 16:48:10 | sip:Testaccount.33@XXXXXX:5060 | sipp running on XXXXX

Therefore i think its not a bug in the module, only a configuration and database issue.