6 Sep
2010
6 Sep
'10
1:46 p.m.
Hi all,
I'm tryting to implement a E164 normalizer using the dialplan module,
by now I have 3 simple rules:
dpid priority matchop matchex matchlen subsex replaceex attributes
0 1 1 (00|\+)([1-9][0-9]+) 0 (00|\+)([1-9][0-9]+) \2
0 1 1 ([5-9][0-9]{8}) 0 ([5-9][0-9]{8}) 34\1
The first rule 'it's supposed' to remove + or 00 from full qualified E164
numbers,
the seccond rule 'should' add 34 as prefix to all 'valid' spanish numbers,
they was
running on some little test I did, but when try to put them on pre-production enviroment
I get strage results.
I call dp_translate as dp_translate("0","$rU/$rU");
And this what I get :
Input RURI Output RURI
900XXXXXX(a)dom.tld XXXXXX(a)dom.tld
And the quetion is why?, are my match rules wrong? why subex and matchex must be the
same?
Best regards.
--
Raul Alexis Betancor Santana
Dimension Virtual S.L.
6 Sep
6 Sep
7:06 p.m.
On 06.09.2010 13:46, rabs(a)dimension-virtual.com wrote:
dpid priority matchop matchex matchlen subsex
replaceex attributes
0 1 1 (00|\+)([1-9][0-9]+) 0 (00|\+)([1-9][0-9]+) \2
0 1 1 ([5-9][0-9]{8}) 0 ([5-9][0-9]{8}) 34\1
The first rule 'it's supposed' to remove + or 00 from full qualified E164
numbers,
the seccond rule 'should' add 34 as prefix to all 'valid' spanish
numbers, they was
running on some little test I did, but when try to put them on pre-production enviroment
I get strage results.
I call dp_translate as dp_translate("0","$rU/$rU");
And this what I get :
Input RURI Output RURI
900XXXXXX(a)dom.tld XXXXXX(a)dom.tld
I'd suppose that both rules match this RURI and since they have the same
priority the first one applies.. (00|\+) matches 00 in any part of the
string, so leading 9 is simply discarded and you get XXXXXX.
Try putting it as ^(00|\+)([1-9][0-9]+) and ^([5-9][0-9]{8}) to
designate start of the string.
--
Sincerely,
Andrew Pogrebennyk
8 Sep
8 Sep
12:02 p.m.
On Lunes 06 Septiembre 2010 17:06:41 Andrew Pogrebennyk escribió:
On 06.09.2010 13:46, rabs(a)dimension-virtual.com
wrote:
Umm .. it doesn't work, let see:
mysql> select * from dialplan;
+----+------+----+----------+------------------------+-----------+------------------------+----------+-------+
| id | dpid | pr | match_op | match_exp | match_len | subst_exp
| repl_exp | attrs |
+----+------+----+----------+------------------------+-----------+------------------------+----------+-------+
| 1 | 0 | 1 | 1 | ^(00|\+)([1-9][0-9]+)$ | 0 | ^(00|\+)
([1-9][0-9]+)$ | \2 | |
| 2 | 0 | 1 | 1 | ^([5-9][0-9]{8})$ | 0 | ^([5-9]
[0-9]{8})$ | 34\1 | |
+----+------+----+----------+------------------------+-----------+------------------------+----------+-------+
DEBUG: dialplan [dialplan.c:217]: integer value
DEBUG: dialplan [dialplan.c:238]: searching 7
DEBUG: dialplan [dialplan.c:326]: input is +34900XXXXXX
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:329]: no matching rule
DEBUG: dialplan [dialplan.c:331]: could not translate +34900XXXXXX
with dpid 0
Any hit about that? ... If I test the regex in rubular.com it's ok
--
Raúl Alexis Betancor Santana
Dimensión Virtual
dpid priority matchop matchex matchlen subsex
replaceex attributes
0 1 1 (00|\+)([1-9][0-9]+) 0 (00|\+)([1-9][0-9]+) \2
0 1 1 ([5-9][0-9]{8}) 0 ([5-9][0-9]{8}) 34\1
The first rule 'it's supposed' to remove + or 00 from full qualified E164
numbers, the seccond rule 'should' add 34 as prefix to all 'valid'
spanish numbers, they was running on some little test I did, but when
try to put them on pre-production enviroment I get strage results.
I call dp_translate as dp_translate("0","$rU/$rU");
And this what I get :
Input RURI Output RURI
900XXXXXX(a)dom.tld XXXXXX(a)dom.tld
I'd suppose that both rules match this RURI and since they have the same
priority the first one applies.. (00|\+) matches 00 in any part of the
string, so leading 9 is simply discarded and you get XXXXXX.
Try putting it as ^(00|\+)([1-9][0-9]+) and ^([5-9][0-9]{8}) to
designate start of the string.
12:14 p.m.
On Miércoles 08 Septiembre 2010 10:02:14 Raúl Alexis Betancor Santana
escribió:
On Lunes 06 Septiembre 2010 17:06:41 Andrew
Pogrebennyk escribió:
Maybe something related to the slash symbol? ... because the second rule works
ok.
DEBUG: dialplan [dialplan.c:217]: integer value
DEBUG: dialplan [dialplan.c:238]: searching 7
DEBUG: dialplan [dialplan.c:326]: input is 657XXXXXX
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:334]: found a matching rule 0xb50e67e0: pr 1,
match_exp ^([5-9][0-9]{8})$
DEBUG: dialplan [dialplan.c:335]: input 657421473 with dpid 0 => output
34657XXXXXX
Best regards
--
Raúl Alexis Betancor Santana
Dimensión Virtual
On 06.09.2010 13:46, rabs(a)dimension-virtual.com
wrote:
Umm .. it doesn't work, let see:
mysql> select * from dialplan;
+----+------+----+----------+------------------------+-----------+---------
---------------+----------+-------+
| id | dpid | pr | match_op | match_exp | match_len |
| subst_exp repl_exp | attrs |
+----+------+----+----------+------------------------+-----------+---------
---------------+----------+-------+
| 1 | 0 | 1 | 1 | ^(00|\+)([1-9][0-9]+)$ | 0 | ^(00|\+)
([1-9][0-9]+)$ | \2 | |
| 2 | 0 | 1 | 1 | ^([5-9][0-9]{8})$ | 0 | ^([5-9]
[0-9]{8})$ | 34\1 | |
+----+------+----+----------+------------------------+-----------+---------
---------------+----------+-------+
DEBUG: dialplan [dialplan.c:217]: integer value
DEBUG: dialplan [dialplan.c:238]: searching 7
DEBUG: dialplan [dialplan.c:326]: input is +34900XXXXXX
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:329]: no matching rule
DEBUG: dialplan [dialplan.c:331]: could not translate +34900XXXXXX
with dpid 0
Any hit about that? ... If I test the regex in rubular.com it's ok dpid priority matchop matchex matchlen subsex
replaceex attributes
0 1 1 (00|\+)([1-9][0-9]+) 0 (00|\+)([1-9][0-9]+) \2
0 1 1 ([5-9][0-9]{8}) 0 ([5-9][0-9]{8}) 34\1
The first rule 'it's supposed' to remove + or 00 from full qualified
E164 numbers, the seccond rule 'should' add 34 as prefix to all
'valid' spanish numbers, they was running on some little test I did,
but when try to put them on pre-production enviroment I get strage
results.
I call dp_translate as dp_translate("0","$rU/$rU");
And this what I get :
Input RURI Output RURI
900XXXXXX(a)dom.tld XXXXXX(a)dom.tld
I'd suppose that both rules match this RURI and since they have the same
priority the first one applies.. (00|\+) matches 00 in any part of the
string, so leading 9 is simply discarded and you get XXXXXX.
Try putting it as ^(00|\+)([1-9][0-9]+) and ^([5-9][0-9]{8}) to
designate start of the string. 
16 Sep
16 Sep
11:35 a.m.
On 9/8/10 11:14 AM, Raúl Alexis Betancor Santana wrote:
On Miércoles 08 Septiembre 2010 10:02:14 Raúl Alexis
Betancor Santana
escribió:
if you try a number starting with 00 does it match?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
On Lunes 06 Septiembre 2010 17:06:41 Andrew
Pogrebennyk escribió:
Maybe
something related to the slash symbol? ... because the second rule works
ok.
DEBUG: dialplan [dialplan.c:217]: integer value
DEBUG: dialplan [dialplan.c:238]: searching 7
DEBUG: dialplan [dialplan.c:326]: input is 657XXXXXX
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:334]: found a matching rule 0xb50e67e0: pr 1,
match_exp ^([5-9][0-9]{8})$
DEBUG: dialplan [dialplan.c:335]: input 657421473 with dpid 0 => output
34657XXXXXX
On 06.09.2010 13:46, rabs(a)dimension-virtual.com
wrote:
Umm .. it doesn't work, let see:
mysql> select * from dialplan;
+----+------+----+----------+------------------------+-----------+---------
---------------+----------+-------+
| id | dpid | pr | match_op | match_exp | match_len |
| subst_exp repl_exp | attrs |
+----+------+----+----------+------------------------+-----------+---------
---------------+----------+-------+
| 1 | 0 | 1 | 1 | ^(00|\+)([1-9][0-9]+)$ | 0 | ^(00|\+)
([1-9][0-9]+)$ | \2 | |
| 2 | 0 | 1 | 1 | ^([5-9][0-9]{8})$ | 0 | ^([5-9]
[0-9]{8})$ | 34\1 | |
+----+------+----+----------+------------------------+-----------+---------
---------------+----------+-------+
DEBUG: dialplan [dialplan.c:217]: integer value
DEBUG: dialplan [dialplan.c:238]: searching 7
DEBUG: dialplan [dialplan.c:326]: input is +34900XXXXXX
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:300]: regex operator testing
DEBUG: dialplan [dp_repl.c:329]: no matching rule
DEBUG: dialplan [dialplan.c:331]: could not translate +34900XXXXXX
with dpid 0
Any hit about that? ... If I test the regex in rubular.com it's ok dpid priority matchop matchex matchlen subsex
replaceex attributes
0 1 1 (00|\+)([1-9][0-9]+) 0 (00|\+)([1-9][0-9]+) \2
0 1 1 ([5-9][0-9]{8}) 0 ([5-9][0-9]{8}) 34\1
The first rule 'it's supposed' to remove + or 00 from full qualified
E164 numbers, the seccond rule 'should' add 34 as prefix to all
'valid' spanish numbers, they was running on some little test I did,
but when try to put them on pre-production enviroment I get strage
results.
I call dp_translate as dp_translate("0","$rU/$rU");
And this what I get :
Input RURI Output RURI
900XXXXXX(a)dom.tld XXXXXX(a)dom.tld
I'd suppose that both rules match this
RURI and since they have the same
priority the first one applies.. (00|\+) matches 00 in any part of the
string, so leading 9 is simply discarded and you get XXXXXX.
Try putting it as ^(00|\+)([1-9][0-9]+) and ^([5-9][0-9]{8}) to
designate start of the string.
5184
days inactive
5194
days old
4 comments
4 participants
participants (4)
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
rabs＠dimension-virtual.com -
Raúl Alexis Betancor Santana