2 Jul
2009
2 Jul
'09
10:13 p.m.
Hi...
Normally, dial plans are based on some sort of mask. For example, in
Brazil, local fix destination have all 8 digits and start with [2-5]
(mask [2-5][0-9]{7}), local mobile numbers have also 8 digits, but start
with [6-9] (mask [6-9][0-9]{7}); so all local numbers mask would be
[2-9][0-9]{7}... I could continue but You got the idea... ;)
Well, what I'm trying to find is a way to use this kind of definition in
place of (or as) the 'prefix' field, either from LCR or CR module.
The advantages are that with this, not only prefix are matched, but also
some sanity checks, like length, can be done in a single step.
Is this a new feature or is there a way to accomplish this?
Edson.
3 Jul
3 Jul
1 a.m.
Edson - Lists writes:
Normally, dial plans are based on some sort of mask.
For example, in
Brazil, local fix destination have all 8 digits and start with [2-5]
(mask [2-5][0-9]{7}), local mobile numbers have also 8 digits, but start
with [6-9] (mask [6-9][0-9]{7}); so all local numbers mask would be
[2-9][0-9]{7}... I could continue but You got the idea... ;)
Well, what I'm trying to find is a way to use this kind of definition in
place of (or as) the 'prefix' field, either from LCR or CR module.
in lcr module prefix is a string of characters. you thus cannot combine
any sanity checks with it, but need to do those separately.
-- juha
3:56 a.m.
El Viernes, 3 de Julio de 2009, Edson - Lists escribió:
Hi...
Normally, dial plans are based on some sort of mask. For example, in
Brazil, local fix destination have all 8 digits and start with [2-5]
(mask [2-5][0-9]{7}), local mobile numbers have also 8 digits, but start
with [6-9] (mask [6-9][0-9]{7}); so all local numbers mask would be
[2-9][0-9]{7}... I could continue but You got the idea... ;)
Well, what I'm trying to find is a way to use this kind of definition in
place of (or as) the 'prefix' field, either from LCR or CR module.
The advantages are that with this, not only prefix are matched, but also
some sanity checks, like length, can be done in a single step.
Is this a new feature or is there a way to accomplish this?
I'd really like to see some mechanism to make routing decisions based on RURI
username itself, rather than just no its prefix. Sure it could be a good
feature.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
9:37 a.m.
Iñaki Baz Castillo writes:
I'd really like to see some mechanism to make
routing decisions based
on RURI username itself, rather than just no its prefix. Sure it
could be a good feature.
lcr module works on longest prefixes of r-uri username (= telephone
number). it was tried once operate on regular expressions, but it was
not a good idea. if you want something else than longest prefixes,
check if some other module (like drouting or cr) could provide that.
-- juha
10:01 a.m.
New subject: LCR/CR and prefix mask (REGEX?) [moved to SR-Users]
I looked around... CR uses the same approach that LCR on prefix
definitions (or, at least the README don't say/explain that it's
different). So I went to look on REGEX module...
Iñaki, this module has Your signature... let me ask You what exactly are
this REGEX groups? Could I use something like:
- Use RURI and recover associated "REGEX-group number";
- Ask LCR or CR to look for routes to prefix="REGEX-group number";
- proceed routing fail-over as usual...
Edson
Juha Heinanen escreveu:
Iñaki Baz Castillo writes:
I'd really like to see some mechanism to make
routing decisions based
on RURI username itself, rather than just no its prefix. Sure it
could be a good feature.
lcr module works on longest prefixes of r-uri username (= telephone
number). it was tried once operate on regular expressions, but it was
not a good idea. if you want something else than longest prefixes,
check if some other module (like drouting or cr) could provide that.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
10:06 a.m.
New subject: [SR-Users] LCR/CR and prefix mask (REGEX?) [moved to SR-Users]
Hello,
you can try a combination of dialplan and dispatcher module. With
dialplan you can match using regexp, return dispatcher group via
attributes, convert it to integer and use it as dispatcher set.
Cheers,
Daniel
On 07/03/2009 04:01 PM, Edson - Lists wrote:
I looked around... CR uses the same approach that LCR
on prefix
definitions (or, at least the README don't say/explain that it's
different). So I went to look on REGEX module...
Iñaki, this module has Your signature... let me ask You what exactly
are this REGEX groups? Could I use something like:
- Use RURI and recover associated "REGEX-group number";
- Ask LCR or CR to look for routes to prefix="REGEX-group number";
- proceed routing fail-over as usual...
Edson
Juha Heinanen escreveu:
--
Daniel-Constantin Mierla
http://www.asipto.com/
Iñaki Baz Castillo writes:
_______________________________________________
sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users I'd really like to see some mechanism to make
routing decisions based
on RURI username itself, rather than just no its prefix. Sure it
could be a good feature.
lcr module works on longest prefixes of r-uri username (= telephone
number). it was tried once operate on regular expressions, but it was
not a good idea. if you want something else than longest prefixes,
check if some other module (like drouting or cr) could provide that.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:47 p.m.
New subject: LCR/CR and prefix mask (REGEX?) [moved to SR-Users]
El Viernes, 3 de Julio de 2009, Edson - Lists escribió:
I looked around... CR uses the same approach that LCR
on prefix
definitions (or, at least the README don't say/explain that it's
different). So I went to look on REGEX module...
Iñaki, this module has Your signature... let me ask You what exactly are
this REGEX groups? Could I use something like:
If the module doc is not self explanatory I should improve it :)
- Use RURI and recover associated "REGEX-group
number";
No, it's not the purpose. It let you matching a pv against any regular
expression in the group number passed as second parameter.
However you could get the desired behaviour as follows:
---- regex file ------------------------------
### National fixed numbers in Spain
[0]
^[89]\d{8}$
^(\+|00)34[89]\d{8}$
### National mobile numbers in Spain
[0]
^6\d{8}$
^(\+|00)346\d{8}$
### International numbers
[0]
^(\+|00)\d{8,}$
-------------------------------------------
Config file:
-----------------------------------------
if pcre_match_group("$rU", 0)
$var(group) = 0; # National fixed numbers in Spain
else if pcre_match_group("$rU", 1)
$var(group) = 1; # National mobile numbers in Spain
else if pcre_match_group("$rU", 2)
$var(group) = 2; # International numbers
[do something with $var(group)]
------------------------------------------
--
Iñaki Baz Castillo <ibc(a)aliax.net>
1:48 p.m.
Iñaki Baz Castillo escreveu:
El Viernes, 3 de Julio de 2009, Edson - Lists
escribió:
Thanks Iñaki... this is something that's very close in functionality of
what I'm looking for...
Indeed, if I insert this code just before the routing decision block and
use $var(group) as desired RURI in CR/LCR call, it should work...
I still have to work around fails and re-routing issues, but let see how
far I can go with this approach...
Edson.
I looked around... CR uses the same approach that
LCR on prefix
definitions (or, at least the README don't say/explain that it's
different). So I went to look on REGEX module...
Iñaki, this module has Your signature... let me ask You what exactly are
this REGEX groups? Could I use something like:
If the module doc is not self explanatory I should improve it :)
- Use RURI and recover associated
"REGEX-group number";
No, it's not the purpose. It let you matching a pv against any regular
expression in the group number passed as second parameter.
However you could get the desired behaviour as follows:
---- regex file ------------------------------
### National fixed numbers in Spain
[0]
^[89]\d{8}$
^(\+|00)34[89]\d{8}$
### National mobile numbers in Spain
[0]
^6\d{8}$
^(\+|00)346\d{8}$
### International numbers
[0]
^(\+|00)\d{8,}$
-------------------------------------------
Config file:
-----------------------------------------
if pcre_match_group("$rU", 0)
$var(group) = 0; # National fixed numbers in Spain
else if pcre_match_group("$rU", 1)
$var(group) = 1; # National mobile numbers in Spain
else if pcre_match_group("$rU", 2)
$var(group) = 2; # International numbers
[do something with $var(group)]
------------------------------------------
3:01 p.m.
El Viernes, 3 de Julio de 2009, Edson - Lists escribió:
You could use LCR after getting the $var(group) and use that value as LCR
"from_user" field (lcr table) in order to select the gateways in order of
preference. This is: configure in LCR some gateways (failover and redundancy
based on LCR priority and weigh) for each $var(group) value, which would match
the "from_user" field.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
No, it's
not the purpose. It let you matching a pv against any regular
expression in the group number passed as second parameter.
However you could get the desired behaviour as follows:
---- regex file ------------------------------
### National fixed numbers in Spain
[0]
^[89]\d{8}$
^(\+|00)34[89]\d{8}$
### National mobile numbers in Spain
[0]
^6\d{8}$
^(\+|00)346\d{8}$
### International numbers
[0]
^(\+|00)\d{8,}$
-------------------------------------------
Config file:
-----------------------------------------
if pcre_match_group("$rU", 0)
$var(group) = 0; # National fixed numbers in Spain
else if pcre_match_group("$rU", 1)
$var(group) = 1; # National mobile numbers in Spain
else if pcre_match_group("$rU", 2)
$var(group) = 2; # International numbers
[do something with $var(group)]
------------------------------------------
Thanks Iñaki... this is something that's very close in functionality of
what I'm looking for...
Indeed, if I insert this code just before the routing decision block and
use $var(group) as desired RURI in CR/LCR call, it should work...
I still have to work around fails and re-routing issues, but let see how
far I can go with this approach...
4 p.m.
Iñaki Baz Castillo escreveu:
El Viernes, 3 de Julio de 2009, Edson - Lists
escribió:
You could use LCR after getting the $var(group) and use that value as LCR
"from_user" field (lcr table) in order to select the gateways in order of
preference. This is: configure in LCR some gateways (failover and redundancy
based on LCR priority and weigh) for each $var(group) value, which would match
the "from_user" field.
exactly what I thought... :) but I'll have to wait.... my test
environment (VM-Server) is corrupted... willl be back only Monday... :'(
No,
it's not the purpose. It let you matching a pv against any regular
expression in the group number passed as second parameter.
However you could get the desired behaviour as follows:
---- regex file ------------------------------
### National fixed numbers in Spain
[0]
^[89]\d{8}$
^(\+|00)34[89]\d{8}$
### National mobile numbers in Spain
[0]
^6\d{8}$
^(\+|00)346\d{8}$
### International numbers
[0]
^(\+|00)\d{8,}$
-------------------------------------------
Config file:
-----------------------------------------
if pcre_match_group("$rU", 0)
$var(group) = 0; # National fixed numbers in Spain
else if pcre_match_group("$rU", 1)
$var(group) = 1; # National mobile numbers in Spain
else if pcre_match_group("$rU", 2)
$var(group) = 2; # International numbers
[do something with $var(group)]
------------------------------------------
Thanks Iñaki... this is something
that's very close in functionality of
what I'm looking for...
Indeed, if I insert this code just before the routing decision block and
use $var(group) as desired RURI in CR/LCR call, it should work...
I still have to work around fails and re-routing issues, but let see how
far I can go with this approach...
5672
days inactive
5672
days old
9 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Edson - Lists -
Iñaki Baz Castillo -
jh＠tutpro.com