Hello All,
I'm having trouble getting lcr to work properly. I am not sure what to use for wild card matching.
In 1.1 i was using PREFIX 4____ ( 4 followed by 4 underscores) and "from_uri" with value %.
Now, in 1.2 I changed the from_uri to be empty (by updating from_uri="") but lcr is not able to match on 5 digit numbers starting with 4. It works if i actually put a 5 digit extension. LCR module documentation mentions regex use for "from_uri" but says nothing about the prefix field
Another problem for me is the change in db tables usr_preferences and subscriber. All tables are created using openser_mysql reinit command
usr_preferences has "modified" field changed to "last_modified".
Subscirber table in 1.2 (no serweb or additional tables;
' +------------------+------------------+------+----- +---------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------------+------------------+------+----- +---------------------+----------------+ | id | int(10) unsigned | | PRI | NULL | auto_increment | | username | varchar(64) | | MUL | | | | domain | varchar(128) | | | | | | password | varchar(25) | | | | | | first_name | varchar(25) | | | | | | last_name | varchar(45) | | | | | | email_address | varchar(50) | | | | | | datetime_created | datetime | | | 0000-00-00 00:00:00 | | | ha1 | varchar(128) | | | | | | ha1b | varchar(128) | | | | | | timezone | varchar(128) | YES | | NULL | | | rpid | varchar(128) | YES | | NULL | | | phone | varchar(15) | YES | | NULL | | +------------------+------------------+------+----- +---------------------+----------------+
subscriber in 1.1
+-------------------+--------------+------+-----+--------------------- +-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+--------------+------+-----+--------------------- +-------+ | phplib_id | varchar(32) | | UNI | | | | username | varchar(64) | | PRI | | | | domain | varchar(128) | | PRI | | | | password | varchar(25) | | | | | | first_name | varchar(25) | | | | | | last_name | varchar(45) | | | | | | phone | varchar(15) | | | | | | email_address | varchar(50) | | | | | | datetime_created | datetime | | | 0000-00-00 00:00:00 | | | datetime_modified | datetime | | | 0000-00-00 00:00:00 | | | confirmation | varchar(64) | | | | | | flag | char(1) | | | o | | | sendnotification | varchar(50) | | | | | | greeting | varchar(50) | | | | | | ha1 | varchar(128) | | | | | | ha1b | varchar(128) | | | | | | allow_find | char(1) | | | 0 | | | timezone | varchar(128) | YES | | NULL | | | rpid | varchar(128) | YES | | NULL | | | domn | int(10) | YES | | NULL | | | uuid | varchar(64) | YES | | NULL | | +-------------------+--------------+------+-----+--------------------- +-------+
Installing serweb tables seems to add the missing fields in subscriber.
I dont know if this is desired behavior or not. In any case I think this should be mentioned on the openser 1.1.x to v1.2.x migration doc.
Thanks.
Juha,
we want only 5 digit numbers to match when prefixed with a 4. Not any length. Was pattern matching remove from lcr in 1.2? /a
...... Original Message ....... On Thu, 7 Jun 2007 07:29:50 +0300 "Juha Heinanen" jh@tutpro.com wrote:
zm23 writes:
In 1.1 i was using PREFIX 4____ ( 4 followed by 4 underscores) and "from_uri" with value %.
prefix is just prefix, i.e., in your case 4. from uri is regular expression, in your case you can use NULL value.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Alan Crosswell writes:
we want only 5 digit numbers to match when prefixed with a 4. Not any length. Was pattern matching remove from lcr in 1.2?
alan,
i'm not sure if there was in 1.1 pattern matching on prefix. i just checked from the code and looks like % was added to the prefix in the mysql query:
... AND '%.*s' LIKE CONCAT(%.*s.%.*s, '%%')
which would mean a match on any length of uri user. at least readme didn't indicate any pattern matching on prefix:
139 Table lcr contains prefix of user part of Request-URI, From 140 URI, gateway group id, and priority. From URI can contain 141 special characters % and _ matching any number of any 142 characters and any one character, respectively, if db_mod 143 parameter is set to 0. If db_mod parameter is set to 1, then 144 From URI is a regular expression.
-- juha
Yes, 1.1 has pattern matching on prefix despite the lack of documentation. It does a SQL match or regex match just like on the from URI. We've used this extensively here for the last year. /a
Juha Heinanen wrote:
Alan Crosswell writes:
we want only 5 digit numbers to match when prefixed with a 4. Not any length. Was pattern matching remove from lcr in 1.2?
alan,
i'm not sure if there was in 1.1 pattern matching on prefix. i just checked from the code and looks like % was added to the prefix in the mysql query:
... AND '%.*s' LIKE CONCAT(%.*s.%.*s, '%%')
which would mean a match on any length of uri user. at least readme didn't indicate any pattern matching on prefix:
139 Table lcr contains prefix of user part of Request-URI, From 140 URI, gateway group id, and priority. From URI can contain 141 special characters % and _ matching any number of any 142 characters and any one character, respectively, if db_mod 143 parameter is set to 0. If db_mod parameter is set to 1, then 144 From URI is a regular expression.
-- juha
Alan Crosswell writes:
Yes, 1.1 has pattern matching on prefix despite the lack of documentation. It does a SQL match or regex match just like on the from URI. We've used this extensively here for the last year.
if you have included chars in the prefix that have special meaning in mysql LIKE expression, then you may have gotten regexp behavior, but that has not been intentional.
it would be lot of work to add regexp support to the current caching implementation. the main reason is that regexps need to be compiled and compilation cannot be made to use shared memory.
-- juha
Yes, we used SQL like patterns. I guess we'll have to look at re-implementing some of what we were using LCR for in openser.cfg code since it was a really convenient way to do a table-drive dial plan. /a
Juha Heinanen wrote:
Alan Crosswell writes:
Yes, 1.1 has pattern matching on prefix despite the lack of documentation. It does a SQL match or regex match just like on the from URI. We've used this extensively here for the last year.
if you have included chars in the prefix that have special meaning in mysql LIKE expression, then you may have gotten regexp behavior, but that has not been intentional.
it would be lot of work to add regexp support to the current caching implementation. the main reason is that regexps need to be compiled and compilation cannot be made to use shared memory.
-- juha
Juha, Thanks for your resoponse. I am a bit confused. How is LCR using regex for "from_uri" ?
Would it be relatively easier to provide the option for db mode again?
Zahid Mehmood writes:
Would it be relatively easier to provide the option for db mode again?
i don't remember the details anymore, but db mode didn't support some other feature that we have in caching mode. but the main reason for dropping db mode was performance, which got very poor (because of mysql LIKE) when number of gw/lcr entries got bigger.
-- juha
Adding regex support for prefix shouldn't be very hard. Unfortunately, right now I'm busy with some other stuff, but maybe latter on I can work on it.
Regards, Ovidiu Sas
On 6/7/07, Juha Heinanen jh@tutpro.com wrote:
Zahid Mehmood writes:
Would it be relatively easier to provide the option for db mode again?
i don't remember the details anymore, but db mode didn't support some other feature that we have in caching mode. but the main reason for dropping db mode was performance, which got very poor (because of mysql LIKE) when number of gw/lcr entries got bigger.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Ovidiu Sas writes:
Adding regex support for prefix shouldn't be very hard. Unfortunately, right now I'm busy with some other stuff, but maybe latter on I can work on it.
ovidiu,
it would be nice if you had time to do it. the code is getting quite long and complex already so maintainability might start getting an issue though.
-- juha
Hi Juha,
I will see if I can slip it in for 1.3. Just ping me if you hear nothing from me in the next ... let's say ... two months.
-ovi
On 6/7/07, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
Adding regex support for prefix shouldn't be very hard. Unfortunately, right now I'm busy with some other stuff, but maybe latter on I can work on it.
ovidiu,
it would be nice if you had time to do it. the code is getting quite long and complex already so maintainability might start getting an issue though.
-- juha
Juha, Ovidiu:
Does the LCR implementation in 1.2 search the lcr_routes table in order listed? If so, then we can live without regexps for prefixes. Otherwise we have ambiguity in our dialplan. For instance, we have entries like:
3_____ (in regexp this would be 3[0-9]{4}) 311
If we change this in the lcr_route table to:
311 ... 3 ...
Then we'd be OK, but if the query randomly comes back in the other order which is a function of the SQL select and underlying table structure unless there's an order by some field which is not explicitly shown as being a sequence number we are screwed.
/a
Ovidiu Sas wrote:
Hi Juha,
I will see if I can slip it in for 1.3. Just ping me if you hear nothing from me in the next ... let's say ... two months.
-ovi
On 6/7/07, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
Adding regex support for prefix shouldn't be very hard. Unfortunately, right now I'm busy with some other stuff, but maybe latter on I can work on it.
ovidiu,
it would be nice if you had time to do it. the code is getting quite long and complex already so maintainability might start getting an issue though.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Alan Crosswell writes:
Does the LCR implementation in 1.2 search the lcr_routes table in order listed?
from README:
Matching gateways are then ordered for forwarding purpose (1) according to longest user part match, (2) according to gateway's priority, and (3) randomly.
so if you have in lcr table
311 ... 3 ...
and call goes to r-uri where userpart starts with 311, then the first entry would be selected.
-- juha
alan,
i'm still wondering how your prefix pattern can limit the number of digits in the match, since definitely % (that matches anything of any length) is added automatically to the prefix. otherwise, plain prefixes like 00358 would not work at all.
-- juha
This would be an issue for prefix regex matching. How we determine the best match, since checking the prefix length doesn't make sense anymore?
-ovi
On 6/8/07, Juha Heinanen jh@tutpro.com wrote:
alan,
i'm still wondering how your prefix pattern can limit the number of digits in the match, since definitely % (that matches anything of any length) is added automatically to the prefix. otherwise, plain prefixes like 00358 would not work at all.
-- juha
Ovidiu Sas writes:
This would be an issue for prefix regex matching.
i was referring to alan's current setup.
How we determine the best match, since checking the prefix length doesn't make sense anymore?
it would still need to be on the longest match of any regexp and may get tricky.
-- juha
Hi Juha,
I know that you were referring to Alan's setup. I was just pointing out that regex has this issue in general.
Let's consider the following example: a call to a 1800 number. The destination is 18001231234 and in the lcr table we have the following two prefixes: 1. ^18[01234567] 2. ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a shorter length.
-ovi
On 6/8/07, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
This would be an issue for prefix regex matching.
i was referring to alan's current setup.
How we determine the best match, since checking the prefix length doesn't make sense anymore?
it would still need to be on the longest match of any regexp and may get tricky.
-- juha
A solution to consider is to do first match rather than longest match and make it explicitly incumbent upon the person entering data into LCR tables to put things in the right order (by adding a sort column). This is analogous to Cisco access list entires for example. Basically you need to extend the openserctl UI by just adding another column....
/a
Ovidiu Sas wrote:
Hi Juha,
I know that you were referring to Alan's setup. I was just pointing out that regex has this issue in general.
Let's consider the following example: a call to a 1800 number. The destination is 18001231234 and in the lcr table we have the following two prefixes:
- ^18[01234567]
- ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a shorter length.
-ovi
On 6/8/07, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
This would be an issue for prefix regex matching.
i was referring to alan's current setup.
How we determine the best match, since checking the prefix length doesn't make sense anymore?
it would still need to be on the longest match of any regexp and may get tricky.
-- juha
Ovidiu Sas writes:
Let's consider the following example: a call to a 1800 number. The destination is 18001231234 and in the lcr table we have the following two prefixes:
- ^18[01234567]
- ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a shorter length.
you can always add dots to (2) to make it longer if you want. dial plans also need to be sensibly designed.
-- juha
Hi Juha,
Pls. check the regex prefix patch available here: http://sourceforge.net/tracker/index.php?func=detail&aid=1736696&gro...
I kept the impact on the existing mode of operation as low as possible. I performed a few tests and everything was working fine in my environment.
Regards, Ovidiu Sas
On 6/8/07, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
Let's consider the following example: a call to a 1800 number. The destination is 18001231234 and in the lcr table we have the following two prefixes:
- ^18[01234567]
- ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a shorter length.
you can always add dots to (2) to make it longer if you want. dial plans also need to be sensibly designed.
-- juha
Just a thought. How about the following idea: 1. Before compiling the regex, change it the following way: prefix -> ^(prefix).*$ 2. Match the called number to all the provisioned prefixes. 3. The "best" match amongst the matched regexes is the one where the length of the substring matched to the first subpattern (part of the regex in the parentheses) is the longest.
The drawback of this approach is that it is necessary to always try to match against all the prefixes, so, if it is necessary to support many prefixes then it is not a good idea.
Anatoly.
Hi Juha,
I know that you were referring to Alan's setup. I was just pointing out that regex has this issue in general.
Let's consider the following example: a call to a 1800 number. The destination is 18001231234 and in the lcr table we have the following two prefixes:
- ^18[01234567]
- ^18[0-2]01
The second prefix is a better match for the 1800 number, but it has a shorter length.
-ovi
On 6/8/07, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
This would be an issue for prefix regex matching.
i was referring to alan's current setup.
How we determine the best match, since checking the prefix length doesn't make sense anymore?
it would still need to be on the longest match of any regexp and may get tricky.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Didn't say it was perfect. Just trying to document our dialplan and make it clear to mere mortals who have to deal with it. A better plan would be to use anchored regexps.
Specifically, the longest match issue is a problem which is why I forced the length in 1.1 LCR.
31123 is dialed. Does this match the 3____ prefix or the 311 prefix In 1.2 LCR it would match 311 which is the longer prefix now.? /a
Juha Heinanen wrote:
alan,
i'm still wondering how your prefix pattern can limit the number of digits in the match, since definitely % (that matches anything of any length) is added automatically to the prefix. otherwise, plain prefixes like 00358 would not work at all.
-- juha
Alan Crosswell writes:
31123 is dialed. Does this match the 3____ prefix or the 311 prefix.
in 1.1 db mode your prefix 3____ is actually 3____%. if you dial 31123, it would match 3____% because it is longer match than 311. in 1.2, if you have 3 and 311, 31123 would match 311 because it is longer.
-- juha
Yes, my point exactly
...... Original Message ....... On Fri, 8 Jun 2007 19:24:20 +0300 "Juha Heinanen" jh@tutpro.com wrote:
Alan Crosswell writes:
31123 is dialed. Does this match the 3____ prefix or the 311 prefix.
in 1.1 db mode your prefix 3____ is actually 3____%. if you dial 31123, it would match 3____% because it is longer match than 311. in 1.2, if you have 3 and 311, 31123 would match 311 because it is longer.
-- juha
On Thursday 07 June 2007 21:21, Zahid Mehmood wrote:
Would it be relatively easier to provide the option for db mode again?
You can get the same -and more- functionality by using db_query, creating a list of destinations in the format and avp that next_gw() expects. ie sip:|0@destination;transport=udp which can be stored directly in the db or use a CONCAT or similar to create it from separate fields.
modparam("lcr", "gw_uri_avp", "1400") modparam("lcr", "ruri_user_avp", "1402")
if not avp_db_query("SELECT uri FROM pstn_gw WHERE '$(fU{s.escape.common})' LIKE callerid ORDER BY callerid DESC", "$avp(i:1400)") { INFO("Can't find PSTN gateways"); sl_send_reply("500", "Cannot load gateways"); return; } next_gw(); t_relay(); ...
Performance will be very dependent on the complexity of the query.
Alex Hermann writes:
Would it be relatively easier to provide the option for db mode again?
You can get the same -and more- functionality by using db_query, creating a list of destinations in the format and avp that next_gw() expects. ie sip:|0@destination;transport=udp which can be stored directly in the db or use a CONCAT or similar to create it from separate fields.
it this is acceptable, i would prefer using it rather than increasing complexity of lcr module. it also occurred to me that making prefix a regular expression, may break backwards compatibility.
-- juha
Hi Juha,
With respect to backward compatibility I was thinking about adding a new module parameter: 'prefix_mode'. The "prefix_mode' can have two values: - the default value: 'prefix' (backward compatible) - new value: 'regex'
-ovi
On 6/8/07, Juha Heinanen jh@tutpro.com wrote:
Alex Hermann writes:
Would it be relatively easier to provide the option for db mode again?
You can get the same -and more- functionality by using db_query, creating a list of destinations in the format and avp that next_gw() expects. ie sip:|0@destination;transport=udp which can be stored directly in the db or use a CONCAT or similar to create it from separate fields.
it this is acceptable, i would prefer using it rather than increasing complexity of lcr module. it also occurred to me that making prefix a regular expression, may break backwards compatibility.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Ovidiu Sas writes:
With respect to backward compatibility I was thinking about adding a new module parameter: 'prefix_mode'. The "prefix_mode' can have two values:
- the default value: 'prefix' (backward compatible)
- new value: 'regex'
ok. can you also avoid regexp compilation and matching is prefix_mode = 'prefix'?
-- juha
Yes. That would be the purpose of the new flag.
-ovi
On 6/8/07, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
With respect to backward compatibility I was thinking about adding a new module parameter: 'prefix_mode'. The "prefix_mode' can have two values:
- the default value: 'prefix' (backward compatible)
- new value: 'regex'
ok. can you also avoid regexp compilation and matching is prefix_mode = 'prefix'?
-- juha
Thank you everyone who responded to my lcr question. Really appreciate your help.
I was wondering if someone could comment on the second part of my email relating to DB schema changes.
Another thing that i noticed is that subscriber table gets the additional (missing compared to v1.1) fields when I install serweb tables. In v1.1 these fields were present without installing serweb tables.
-
Alan Crosswell -
Alex Hermann -
Anatoly Pidruchny -
jh＠tutpro.com -
Ovidiu Sas -
Zahid Mehmood -
zm23