Hi!
Currently I have users stored in DB with lower case letters. But I want to allow my user to use upper case letters as well. But this does not work as avp_db_load is case sensitive. Is there a way to handle avp_db_load case insensitive?
thanks klaus
Hello,
On 10/17/07 16:10, Klaus Darilion wrote:
Hi!
Currently I have users stored in DB with lower case letters. But I want to allow my user to use upper case letters as well. But this does not work as avp_db_load is case sensitive. Is there a way to handle avp_db_load case insensitive?
is it postgres behind? AFAIK, mysql does ignore case comparison -- although I may be wrong!
The issue comes from the database server, the value is passed as it is gotten from the message. It is hard to predict what is the form in database, upper case, lower case, mixed. Maybe the database server can be configured to do ignore case string comparison.
Cheers, Daniel
thanks klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Daniel!
Daniel-Constantin Mierla wrote:
On 10/17/07 16:10, Klaus Darilion wrote:
Currently I have users stored in DB with lower case letters. But I want to allow my user to use upper case letters as well. But this does not work as avp_db_load is case sensitive. Is there a way to handle avp_db_load case insensitive?
is it postgres behind? AFAIK, mysql does ignore case comparison -- although I may be wrong!
Yes it is postgres but AFAIK SQL queries are per default always case sensitive.
Here is the query from avp_db_load when the SIP request has sip:KLAUS.darilion@example.com in the From URI:
select value,attribute,type from conference_extension where username='KLAUS.darilion' AND domain='example.com' AND attribute='106'
As you see it is "username='string'" and a "=" comparison is case sensitive. For example in registrar module there is a module parameter for case insensitive lookups which will convert the strings into lower case for all SQL queries.
The problem is also with dbaliases module: if a user calls John.Doe@domain instead of john.doe@domain (which is the alias) it won't work:
select username,domain from dbaliases where alias_username='JohnDoe' AND alias_domain='example.com'
As you see the keys used by dbaliases module are the RURI.
The issue comes from the database server, the value is passed as it is gotten from the message. It is hard to predict what is the form in database, upper case, lower case, mixed. Maybe the database server can be configured to do ignore case string comparison.
I think the only solution would be to have a case_sensitive parameter (like in registrar module) in all relevant modules.
What do you think?
regards klaus
Klaus Darilion writes:
Yes it is postgres but AFAIK SQL queries are per default always case sensitive.
if i remember correctly, this does not hold for mysql = operator.
Here is the query from avp_db_load when the SIP request has sip:KLAUS.darilion@example.com in the From URI:
select value,attribute,type from conference_extension where username='KLAUS.darilion' AND domain='example.com' AND attribute='106'
As you see it is "username='string'" and a "=" comparison is case sensitive.
in order to make that comparison case sensitive, you need to add "binary" or something like that to the expression.
-- juha
Juha Heinanen wrote:
Klaus Darilion writes:
Yes it is postgres but AFAIK SQL queries are per default always case sensitive.
if i remember correctly, this does not hold for mysql = operator.
You are right. I've tested it and mysql indeed compares case insensitive. In postgresql you have to use ILIKE for case insensitive string comparison.
Any ideas how we can make this consistent for openser?
regards klaus
On 10/19/07 11:09, Klaus Darilion wrote:
Juha Heinanen wrote:
Klaus Darilion writes:
Yes it is postgres but AFAIK SQL queries are per default always
case > sensitive.
if i remember correctly, this does not hold for mysql = operator.
You are right. I've tested it and mysql indeed compares case insensitive. In postgresql you have to use ILIKE for case insensitive string comparison.
Any ideas how we can make this consistent for openser?
I am not sure if previously proposed solution is good (to set a parameter and convert all queries to upper/lower case). There will be a lot of impact in the source code and some fields should not changed, some should. As the standards say the addresses are case insensitive, a solution has to be found, just that is not a straight one. Perhaps, the quickest one is to be able to set in postgres module what operator to be used for string comparison, although is not the cleanest one.
Cheers, Daniel
regards klaus
I think the fundemental error here is you look up users by URI as opposed to a unique identifier. -jiri
At 15:10 17/10/2007, Klaus Darilion wrote:
Hi!
Currently I have users stored in DB with lower case letters. But I want to allow my user to use upper case letters as well. But this does not work as avp_db_load is case sensitive. Is there a way to handle avp_db_load case insensitive?
thanks klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
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.
So, I do not see any fundamental error here, given the subject of the discussion.
Cheers, Daniel
At 15:10 17/10/2007, Klaus Darilion wrote:
Hi!
Currently I have users stored in DB with lower case letters. But I want to allow my user to use upper case letters as well. But this does not work as avp_db_load is case sensitive. Is there a way to handle avp_db_load case insensitive?
thanks klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 2) translation of normaized names into unambiguous unique ids - failure to do is is likely to caused difficulties with aliases (domain aliases, user aliases, combination of both) 3) doing subsequent operations using ids.
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/
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
- 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@domain we have to find a way to make step 1.
What about having AVP-translations for converting to lower/upper case?
regards klaus
- translation of normaized names into unambiguous unique ids
- failure to do is is likely to caused difficulties with aliases (domain aliases, user aliases, combination of both)
- doing subsequent operations using ids.
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/
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@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/
Jiri Kuthan schrieb:
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@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).
Hi Jiri!
In Openser 1.2 there were introduced "Pseude Variables transformation". Thus, my idea was to add another transformation, e.g. $ru{s.lower}
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.
Yes - this is still possible. But this module option is only available in registrar module, this it does not help with alias_db module or avp_db_load.
regards klaus
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
- 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
- translation of normaized names into unambiguous unique ids
- failure to do is is likely to caused difficulties with aliases (domain aliases, user aliases, combination of both)
- doing subsequent operations using ids.
I don't understand why username@domain is not unique enough?
According to RFC 3261 section 19.1.4, SIP usernames are case sensitive, so you actually shouldn't convert them to upper/lower-case. And user/domain aliases is a different issue since it always involves some kind of alias mapping lookup.
/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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
In MySQL see:
http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html
One solution would be to define the table or particular column in question with a case sensitive character set mapping, for example:
CHARACTER SET latin1 COLLATE latin1_bin
Regards, Norm
Christian Schlatter 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
- translation of normaized names into unambiguous unique ids
- failure to do is is likely to caused difficulties with aliases
(domain aliases, user aliases, combination of both) 3) doing subsequent operations using ids.
I don't understand why username@domain is not unique enough?
According to RFC 3261 section 19.1.4, SIP usernames are case sensitive, so you actually shouldn't convert them to upper/lower-case. And user/domain aliases is a different issue since it always involves some kind of alias mapping lookup.
/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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Norman Brandinger wrote:
In MySQL see:
http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html
One solution would be to define the table or particular column in question with a case sensitive character set mapping, for example:
CHARACTER SET latin1 COLLATE latin1_bin
Hi Norman!
This way I can make MYsql case sensitive. Do you also know a trick to make postgresql case insensitive?
regards klaus
It doesn't appear that there is an easy trick.
http://www.redhat.com/docs/manuals/database/RHDB-7.1-Manual/sql/functions-ma...
From the above link:
The keyword ILIKE can be used instead of LIKE to make the match case insensitive according to the active locale. This is not in the SQL standard; it is a PostgreSQL extension.
Regards, Norm
ps. I'm a little disappointed in the tone of the recent discussion on this topic.
Klaus Darilion wrote:
Norman Brandinger wrote:
In MySQL see:
http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html
One solution would be to define the table or particular column in question with a case sensitive character set mapping, for example:
CHARACTER SET latin1 COLLATE latin1_bin
Hi Norman!
This way I can make MYsql case sensitive. Do you also know a trick to make postgresql case insensitive?
regards klaus
At 17:34 19/10/2007, Christian Schlatter wrote:
I don't understand why username@domain is not unique enough?
sometimes it is christian@domain.com, sometimes christian.schlatter@domain.com, sometimes it is christian.schlatter@.domain.org or even worse you can take your spouses' name and from day D you begin to be christian.blair@domain.org, and your company gets acquired and you become christian.blair@oracle.com. (Which clients without DNS/SRV can try to reach as christian.blair@sip.oracle.com, and those who pay extra respect to you using capital letters as Christian.Blair@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.
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.
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan wrote:
At 17:34 19/10/2007, Christian Schlatter wrote:
I don't understand why username@domain is not unique enough?
sometimes it is christian@domain.com, sometimes christian.schlatter@domain.com, sometimes it is christian.schlatter@.domain.org or even worse you can take your spouses' name and from day D you begin to be christian.blair@domain.org, and your company gets acquired and you become christian.blair@oracle.com. (Which clients without DNS/SRV can try to reach as christian.blair@sip.oracle.com, and those who pay extra respect to you using capital letters as Christian.Blair@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, but isn't this more of a database specific thing? 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@domain.org or christian.blair@oracle.com.
You're raising a good point, but I think identity management should not be done in the SIP proxy.
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.
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
Christian Schlatter schrieb:
Jiri Kuthan wrote:
At 17:34 19/10/2007, Christian Schlatter wrote:
I don't understand why username@domain is not unique enough?
sometimes it is christian@domain.com, sometimes christian.schlatter@domain.com, sometimes it is christian.schlatter@.domain.org or even worse you can take your spouses' name and from day D you begin to be christian.blair@domain.org, and your company gets acquired and you become christian.blair@oracle.com. (Which clients without DNS/SRV can try to reach as christian.blair@sip.oracle.com, and those who pay extra respect to you using capital letters as Christian.Blair@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, but isn't this more of a database specific thing? 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@domain.org or christian.blair@oracle.com.
Hi Christian!
Is LDAP case sensitive?
regards klaus
Klaus Darilion wrote:
Christian Schlatter schrieb:
Jiri Kuthan wrote:
At 17:34 19/10/2007, Christian Schlatter wrote:
I don't understand why username@domain is not unique enough?
sometimes it is christian@domain.com, sometimes christian.schlatter@domain.com, sometimes it is christian.schlatter@.domain.org or even worse you can take your spouses' name and from day D you begin to be christian.blair@domain.org, and your company gets acquired and you become christian.blair@oracle.com. (Which clients without DNS/SRV can try to reach as christian.blair@sip.oracle.com, and those who pay extra respect to you using capital letters as Christian.Blair@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, but isn't this more of a database specific thing? 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@domain.org or christian.blair@oracle.com.
Hi Christian!
Is LDAP case sensitive?
Hi Klaus,
This depends on the LDAP matching rule in use. E.g. for H.350 SIPIdentitySIPURI the matching rule is 'caseExactMatch' which means that SIP URI lookups are done case sensitive.
SIPIdentitySIPURI is further described at http://metric.it.uab.edu/vnet/cookbook/v2.1/node140.html#SECTION073161000000...
/Christian
regards klaus
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@domain is not unique enough?
sometimes it is christian@domain.com, sometimes christian.schlatter@domain.com, sometimes it is christian.schlatter@.domain.org or even worse you can take your spouses' name and from day D you begin to be christian.blair@domain.org, and your company gets acquired and you become christian.blair@oracle.com. (Which clients without DNS/SRV can try to reach as christian.blair@sip.oracle.com, and those who pay extra respect to you using capital letters as Christian.Blair@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@domain.org or christian.blair@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
-- Jiri Kuthan http://iptel.org/~jiri/
Christian Schlatter 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
- translation of normaized names into unambiguous unique ids
- failure to do is is likely to caused difficulties with aliases
(domain aliases, user aliases, combination of both) 3) doing subsequent operations using ids.
I don't understand why username@domain is not unique enough?
According to RFC 3261 section 19.1.4, SIP usernames are case sensitive, so you actually shouldn't convert them to upper/lower-case. And user/domain aliases is a different issue since it always involves some kind of alias mapping lookup.
Yes, RFC 3261 says case sensitive - but if my domain has the policy to have case insensitive usernames, but domains are also case insensitive, then you can save lots of support tickets. E.g. there are many users which configure their clients with sip:Name.Surename@domain instead of sip:name.surname@domain (or vice versa).
regards klaus
At 18:33 19/10/2007, Klaus Darilion wrote:
Yes, RFC 3261 says case sensitive - but if my domain has the policy to have case insensitive usernames, but domains are also case insensitive, then you can save lots of support tickets. E.g. there are many users which configure their clients with sip:Name.Surename@domain instead of sip:name.surname@domain (or vice versa).
Just to make it clear -- that's not an RFC3261 bug -- the interop reasoning is you can't change things you don't "own", what you do about your own stuff nobody cares. You can't forward a@other.domain to other domain as A@other.domain because you don't know if the other domain is case-sensitive or not. If you translare klaus.darilion to kd or KD or whatever localy, you don't conflict with the RFC -- making URIs more "accurate" to get them to the proper recepient is the key role of a proxy server.
-jiri
regards klaus
-- Jiri Kuthan http://iptel.org/~jiri/
At 16:34 19/10/2007, Klaus Darilion wrote:
Jiri Kuthan wrote:
I think the fundemental error here is you look up users by URI as opposed to a unique identifier. -jiri
Hi Jiri!
How do you find out the UUID from an URI?
Not sure what the openser's best recommended way is, but a short look at the data structures tells me that the ID is part of the subscribers structure...
subscriber.xml:
<column id="id"> <name>id</name> <type>unsigned int</type>
So it is just about looking at the manuals where the lookup is actually being done. I was guessing the id lookup to be part of auth module but haven't find it there, some folks with better knowledge of the openser diffs will hopefuly help to navigate to the right place.
-jiri
klaus
-- Jiri Kuthan http://iptel.org/~jiri/
On Friday 19 October 2007, Jiri Kuthan wrote:
How do you find out the UUID from an URI?
Not sure what the openser's best recommended way is, but a short look at the data structures tells me that the ID is part of the subscribers structure...
subscriber.xml:
<column id="id"> <name>id</name> <type>unsigned int</type>
So it is just about looking at the manuals where the lookup is actually being done. I was guessing the id lookup to be part of auth module but haven't find it there, some folks with better knowledge of the openser diffs will hopefuly help to navigate to the right place.
Hello Jiri, Klaus,
the unique id is at the moment not used in the auth_db module. The username and if wanted additionally the domain is used for db lookup.
Cheers,
Henning
-
Christian Schlatter -
Daniel-Constantin Mierla -
Henning Westerholt -
jh＠tutpro.com -
Jiri Kuthan -
Klaus Darilion -
Norman Brandinger