Blocked call routes Digit maps

[hapollo]

(!1(24[26]|26[48]|284|345|441|473|649|664|721|758|767|784|8[024]9|86[89]|[89]76|900)xxxxxxx|1xxxxxxxxxx)

The other day, a family member managed to call Nassau, Bahamas with their fat fingers. Instead of dialing NYC 212, they dialed 242 which was surprising since I thought we had 242 blocked in my digit maps above.

Does the 2nd set (1xxxxxxxxxx) negate the first set and allow all 11 digit calls to go thru?

Anyone have a good digit maps that blocks such 3 digit non 011 international calls?

Afraid to test by trial and error with digit maps since a wrong parentheses somewhere can allow a call to go through resulting in charges!

[restamp]

You might try adding an S0 to the end of your barring rule (or both rules, for that matter, to speed up normal call placement:

(!1(24[26]|26[48]|284|345|441|473|649|664|721|758|767|784|8[024]9|86[89]|[89]76|900)xxxxxxxS0|1xxxxxxxxxxS0)

[hapollo]

Thanks for the suggestion but never had an issue with call speed of connections with this setup in over 5 yrs. As soon as the last digit is dialed, phone rings immediately.

Problem is with it actually connecting to number prefix I thought was in the call block list.

[restamp]

Problem is with it actually connecting to number prefix I thought was in the call block list.

Add the first S0 to the end of your barring rule and let us know if it corrects the above problem.

[azrobert]

I don't see the problem. The OBi will use the best match rule and "!1242xxxxxxx" is a better match than "1xxxxxxxxxx". The sequence of the rules don't matter.

You can test and avoid charges by temporarily routing the call to the OBiTalk network. If you are routing the call to the primary route, change Phone Port outbound call route rule "{(Mpli):pli}" to "{(Mpli):pp}". If the call is rejected in the Phone Port digit map, you will get a busy. If the call is routed to OBiTalk, it will fail and you will also get a busy. If the call fails in the Phone outbound route, you get a message "No routes available". Check the call history to see if the call is routed to ObiTalk. Only calls routed will show in the history, so calls rejected by "!" will not show in the history. I would start testing with only rule "!1242xxxxxxx".

I don't use the "!" operand, but I did some testing a long time ago.  If I remember correctly the not operand doesn't actually reject the call, it is treated as a non-match.

If you have the following:
{(Msp2):sp2},{(Mpli):pli}

If you get a match in Msp2 with a "!", it will be treated as a non-match and the call won't be routed to SP2. Processing continues and if you get a match in Mpli the call will be routed to the primary line.

If the "not" rule is copied into the Phone Port digit map by rule "(Mpli)", the call should be rejected there and the outbound call route won't be processed.

Edit:
If you can't get this to work, you can use another method. Add the following to the beginning of the Phone outbound route:
{(1(24[26]|26[48]|284|345|441|473|649|664|721|758|767|784|8[024]9|86[89]|[89]76|900)xxxxxxx):}

[restamp]

As I see it, hapollo has two rules in his dialstring that both go from Partially Matched to Exactly Matched when a barred eleven digit number is entered.  The DMP is supposed to select the best match, which one would logically think is the barring rule.  But, maybe it doesn't consider a paren-ed string of specified digits to be a better match than a simple 'x'.  If the S0 doesn't stop the process in its tracks once the barred rule becomes an exact match, hapollo might also try the following kludge:

(!1(24[26]|26[48]|284|345|441|473|649|664|721|758|767|784|8[024]9|86[89]|[89]76|900)[2-9]xxxxxx|1xxxxxxxxxx)

which (may?) introduce another literal which would cause the barring rule to be adjudicated the better match and be selected over his second rule.

I'm curious if either of these correct his problem.

[hapollo]

Turns out the family member was traveling overseas and used the Obion App and called in thru Obitalk 1SD which had a different Digitmaps route. To resolve this I moved the original barred calls Digit maps to a User Defined Digit Maps and now referenced the User Defined Digit Map (Mbarred) in all Obitalk, SPs and VGs Digit Maps

Thanks for all the input.

Add the first S0 to the end of your barring rule and let us know if it corrects the above problem.

Not sure what S0 has anything to do with this. It is my understanding S0 just speeds up call connections when xx. is used, which my Digit Maps does not even have. In the absence of S(n), when blank, it defaults to S0 as per the Obi Digitmaps administrator guide Page 9

The notation S0, S1, S2, S9 gives digit timer values of 0, 1, 2 and
9 seconds respectively; S is equivalent to S1; S0 is the same as “blank”. You can concatenate multiple S elements together if you need more than 9s timeout, such as S9S5 for a 14s timeout.