Blocked call routes Digit maps
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.
Quote from: restamp on December 19, 2016, 03:02:31 pm
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
Quote
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.
Navigation
[0] Message Index
[*] Previous page