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

ver 1.5.x
modules (357)

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 | | 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:,
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

    Asgaroth - 2009-12-10

    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")) {
    } 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");

  • Henning Westerholt

    • summary: Case sensitivity in usrloc "location" table --> usrloc stores username in lowercase in "location" table
  • 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.

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

  • Henning Westerholt

    • assigned_to: nobody --> henningw
    • status: open --> closed-invalid

Log in to post a comment.