SOLVED Regex failing on inbound call

[Ian@ITEL7]

Hi All,

I have a puzzling issue. I have just added a new trunk to our instance of Fusion and added in the destinations for the DID however the regex seems to be failing even though it matches. Please see the log excerpt below. I have tested both of the regex configurations on regex101.com and they are valid and work to the caller_destination number. Any ideas as to what could be causing this failure?


dd9db055-c8ea-40ac-af50-b0f450c50f4b 2021-05-28 11:55:41.623461 [DEBUG] mod_dptools.c:1685 SET sofia/external/61490085736@siptrunk.connectyou.net.au [caller_destination]=[61731800576]
dd9db055-c8ea-40ac-af50-b0f450c50f4b Dialplan: sofia/external/61490085736@siptrunk.connectyou.net.au parsing [public->61731800576] continue=false
dd9db055-c8ea-40ac-af50-b0f450c50f4b Dialplan: sofia/external/61490085736@siptrunk.connectyou.net.au Regex (FAIL) [61731800576] destination_number(0731800576) =~ /^(61731800576)$/ break=on-false

2b058fe6-b53c-4226-950c-1f71eeb9b4b2 2021-05-28 11:34:53.243396 [DEBUG] mod_dptools.c:1685 SET sofia/external/61490085736@siptrunk.connectyou.net.au [caller_destination]=[61731800576]
2b058fe6-b53c-4226-950c-1f71eeb9b4b2 Dialplan: sofia/external/61490085736@siptrunk.connectyou.net.au parsing [public->731800576] continue=false
2b058fe6-b53c-4226-950c-1f71eeb9b4b2 Dialplan: sofia/external/61490085736@siptrunk.connectyou.net.au Regex (FAIL) [731800576] destination_number(0731800576) =~ /^\+?61?(731800576)$/ break=on-false

 

[Adrian Fretwell]

Your regex will not match a destination number that begins with a zero (0). So 07310800576 will not match.

I'm not sure exactly what you are trying to achieve because I,m not looking at the regex in the context of the rest of your inbound route but the following should get you somewhere near:

^\+?(?:61)?0?(731800576)$

Here's what is going on:
^ asserts the beginning of the line/string
\+? \ escapes the special character + so \+ matches exactly + and then the ? makes the match optional (0 or 1 times).
(?:61) creates a non capturing group containing 61 the following ? makes it optional.
0 matches exactly 0 the following ? makes it optional.
(731800576) is the first capturing group which means that 731800576 will become the contents of the $1 variable.
$ asserts the end of the line.

I hope this helps.

 

[Ian@ITEL7]

Your regex will not match a destination number that begins with a zero (0). So 07310800576 will not match.

I'm not sure exactly what you are trying to achieve because I,m not looking at the regex in the context of the rest of your inbound route but the following should get you somewhere near:

^\+?(?:61)?0?(731800576)$

Here's what is going on:
^ asserts the beginning of the line/string
\+? \ escapes the special character + so \+ matches exactly + and then the ? makes the match optional (0 or 1 times).
(?:61) creates a non capturing group containing 61 the following ? makes it optional.
0 matches exactly 0 the following ? makes it optional.
(731800576) is the first capturing group which means that 731800576 will become the contents of the $1 variable.
$ asserts the end of the line.

I hope this helps.

Hi Adrian,

The 0 is only in the description of number and not in the regex section. Please see the snapshot.

The destination is set by [caller_destination]=[61731800576]. This is what is received by the sip trunk in the invite message. I have set up the destination 2 ways to capture this ( not at the same time as to not cause a conflict ). As you can see in the first one the regex is ^(61731800576)$ to capture the full number and the second is ^\+?61?(731800576)$ to capture the 9 digit number with a prefix of +61 whether present or not. In either case the regex fails for this number, the other numbers that are set up the same way for inbound work fine.

Like I said I copied the exact regex that is shown and tested it on regex101.com and confirmed it is correct for the number I am trying to match, It is strange that this inbound route is failing whilst others that are configured the same work fine.

 

[Adrian Fretwell]

Like I said I copied the exact regex that is shown and tested it on regex101.com and confirmed it is correct for the number I am trying to match,

You need to test it again properly

^\+?61?(731800576)$ Will not make +61 optional, it will not match 731800576. It will match 6731800576. Like I said before you need something like (?:61)? to make the 61 optional.

The 0 (zero) is not just in the description if it were then FreeSWITCH would not be trying to match against it in your log:
"destination_number(0731800576) =~ /^(61731800576)$/ break=on-false"

 

[Ian@ITEL7]

You need to test it again properly

^\+?61?(731800576)$ Will not make +61 optional, it will not match 731800576. It will match 6731800576. Like I said before you need something like (?:61)? to make the 61 optional.

The 0 (zero) is not just in the description if it were then FreeSWITCH would not be trying to match against it in your log:
"destination_number(0731800576) =~ /^(61731800576)$/ break=on-false"

Hi Adrian,

How do you explain all of other inbound destinations that I have constructed in the exact same manner that operate correctly?

Here is one of the other inbound routes that is build in the same way and works correctly. The difference with this is its destination, instead of an extension it hits a call flow.

63210516-479e-4be0-8a42-5adf1c62003f 2021-05-31 19:10:53.783408 [DEBUG] mod_dptools.c:1685 SET sofia/external/61490085736@siptrunk.connectyou.net.au [caller_destination]=[61731800339]

63210516-479e-4be0-8a42-5adf1c62003f Dialplan: sofia/external/61490085736@siptrunk.connectyou.net.au parsing [public->731800339] continue=false
63210516-479e-4be0-8a42-5adf1c62003f Dialplan: sofia/external/61490085736@siptrunk.connectyou.net.au Regex (PASS) [731800339] destination_number(61731800339) =~ /^\+?61?(731800339)$/ break=on-false

regards
Ian

 

[Adrian Fretwell]

Your second screenshot has country code populated. And the debug output shows the match testing against the number with the prefix:

"destination_number(61731800339) =~ /^\+?61?(731800339)$/ break=on-false"

Your regex is still wrong if you want to make the +61 completely optional.

 

[Ian@ITEL7]

Your second screenshot has country code populated. And the debug output shows the match testing against the number with the prefix:

"destination_number(61731800339) =~ /^\+?61?(731800339)$/ break=on-false"

Your regex is still wrong if you want to make the +61 completely optional.

Don't mind me.... talk about going off half cocked!

I compared the inbound calls from a working trunk with this new one and the invite message was different. I checked and saw that they were registered on a different server with our supplier. When I changed over the server it worked as expected providing the full number of 61731800576 and not 0731800576. Turns out the other server just provided the 10 digit number.

PEBKAC!