17 Oct
2007
17 Oct
'07
9:10 a.m.
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
18 Oct
18 Oct
10:35 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
3:39 p.m.
Hi Daniel!
Daniel-Constantin Mierla wrote:
On 10/17/07 16:10, Klaus Darilion wrote:
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.
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.
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
19 Oct
19 Oct
12:58 a.m.
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
4:09 a.m.
Juha Heinanen wrote:
Klaus Darilion writes:
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
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.
6:10 a.m.
On 10/19/07 11:09, Klaus Darilion wrote:
Juha Heinanen wrote:
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
Klaus Darilion writes:
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? 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.
regards
klaus
6:35 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
Jiri Kuthan http://iptel.org/~jiri/
6:52 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
7:19 a.m.
At 12:52 19/10/2007, Daniel-Constantin Mierla wrote:
On 10/19/07 13:35, Jiri Kuthan wrote:
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.
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.
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/
10:37 a.m.
Jiri Kuthan wrote:
At 12:52 19/10/2007, Daniel-Constantin Mierla wrote:
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
On 10/19/07 13:35, Jiri Kuthan wrote:
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 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. 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/
12:34 p.m.
At 16:37 19/10/2007, Klaus Darilion wrote:
Jiri Kuthan wrote:
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.
At 12:52 19/10/2007, Daniel-Constantin Mierla
wrote:
Thus, regardless if your setup is based on UUIDs or username@domain we have to find a way
to make step 1. On 10/19/07 13:35, Jiri Kuthan wrote:
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 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 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/
22 Oct
22 Oct
7:31 a.m.
Jiri Kuthan schrieb:
At 16:37 19/10/2007, Klaus Darilion wrote:
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}
Jiri Kuthan wrote:
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.
At 12:52 19/10/2007, Daniel-Constantin Mierla
wrote:
Thus, regardless if your
setup is based on UUIDs or username@domain we have to find a way to make step 1. 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 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.
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
19 Oct
19 Oct
11:34 a.m.
Jiri Kuthan wrote:
At 12:52 19/10/2007, Daniel-Constantin Mierla wrote:
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
On 10/19/07 13:35, Jiri Kuthan wrote:
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. 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.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users 
11:56 a.m.
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:
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
On 10/19/07 13:35, Jiri Kuthan wrote:
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. 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.
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.
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
12:35 p.m.
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
12:52 p.m.
It doesn't appear that there is an easy trick.
http://www.redhat.com/docs/manuals/database/RHDB-7.1-Manual/sql/functions-m…
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
12:20 p.m.
At 17:34 19/10/2007, Christian Schlatter wrote:
I don't understand why username@domain is not
unique enough?
sometimes it is christian(a)domain.com, sometimes christian.schlatter(a)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(a)domain.org, and your company
gets acquired and you become christian.blair(a)oracle.com. (Which clients without
DNS/SRV can try to reach as christian.blair(a)sip.oracle.com, and those who pay
extra respect to you using capital letters as Christian.Blair(a)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.
--
Jiri Kuthan http://iptel.org/~jiri/ 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
12:46 p.m.
Jiri Kuthan wrote:
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
At 17:34 19/10/2007, Christian Schlatter wrote:
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(a)domain.org or christian.blair(a)oracle.com.
You're raising a good point, but I think identity management should not
be done in the SIP proxy.
I don't understand why username@domain is not
unique enough?
sometimes it is christian(a)domain.com, sometimes christian.schlatter(a)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(a)domain.org, and your company
gets acquired and you become christian.blair(a)oracle.com. (Which clients without
DNS/SRV can try to reach as christian.blair(a)sip.oracle.com, and those who pay
extra respect to you using capital letters as Christian.Blair(a)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.
--
Jiri Kuthan http://iptel.org/~jiri/ 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
22 Oct
22 Oct
7:34 a.m.
Christian Schlatter schrieb:
Jiri Kuthan wrote:
Hi Christian!
Is LDAP case sensitive?
regards
klaus
At 17:34 19/10/2007, Christian Schlatter wrote:
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(a)domain.org or christian.blair(a)oracle.com. I don't understand why username@domain is not
unique enough?
sometimes it is christian(a)domain.com, sometimes
christian.schlatter(a)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(a)domain.org, and
your company
gets acquired and you become christian.blair(a)oracle.com. (Which
clients without
DNS/SRV can try to reach as christian.blair(a)sip.oracle.com, and those
who pay
extra respect to you using capital letters as
Christian.Blair(a)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.
11:58 a.m.
Klaus Darilion wrote:
Christian Schlatter schrieb:
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#SECTION07316100000…
/Christian
Jiri Kuthan wrote:
Hi Christian!
Is LDAP case sensitive? At 17:34 19/10/2007, Christian Schlatter wrote:
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(a)domain.org or
christian.blair(a)oracle.com. I don't understand why username@domain is not
unique enough?
sometimes it is christian(a)domain.com, sometimes
christian.schlatter(a)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(a)domain.org, and
your company
gets acquired and you become christian.blair(a)oracle.com. (Which
clients without
DNS/SRV can try to reach as christian.blair(a)sip.oracle.com, and those
who pay
extra respect to you using capital letters as
Christian.Blair(a)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.
regards
klaus
23 Oct
23 Oct
6:52 a.m.
At 18:46 19/10/2007, Christian Schlatter wrote:
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
Jiri Kuthan wrote:
yes.
At 17:34 19/10/2007, Christian Schlatter wrote:
Ok, this makes sense e.g. for foreign key relationships, I don't understand why username@domain is not
unique enough?
sometimes it is christian(a)domain.com, sometimes
christian.schlatter(a)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(a)domain.org, and your company
gets acquired and you become christian.blair(a)oracle.com. (Which clients without
DNS/SRV can try to reach as christian.blair(a)sip.oracle.com, and those who pay
extra respect to you using capital letters as Christian.Blair(a)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. 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(a)domain.org or
christian.blair(a)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. Your're right though that this is a matter of local
policy.
/Christian
--
Jiri Kuthan http://iptel.org/~jiri/
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(a)openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>--
>Jiri Kuthan http://iptel.org/~jiri/
19 Oct
19 Oct
12:33 p.m.
Christian Schlatter wrote:
Jiri Kuthan 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).
regards
klaus
At 12:52 19/10/2007, Daniel-Constantin Mierla
wrote:
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. On 10/19/07 13:35, Jiri Kuthan wrote:
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. 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.
12:45 p.m.
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(a)other.domain to other domain as A(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/
12:41 p.m.
At 16:34 19/10/2007, Klaus Darilion wrote:
Jiri Kuthan wrote:
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
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? klaus
--
Jiri Kuthan http://iptel.org/~jiri/
22 Oct
22 Oct
9:39 a.m.
On Friday 19 October 2007, Jiri Kuthan wrote:
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
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.
6103
days inactive
6109
days old
25 comments
7 participants
participants (7)
-
Christian Schlatter -
Daniel-Constantin Mierla -
Henning Westerholt -
jh＠tutpro.com -
Jiri Kuthan -
Klaus Darilion -
Norman Brandinger