Inconsistant results using the same digit maps in Line And AA .Is this a bug?
RonR:
Quote from: larrybob on April 14, 2012, 11:48:49 pm
digitmap "areacode" : (<415>)
digitmap "us" : (1[2-9][0-8]x xxxx|<1>[2-9][0-8]x xxx xxxx|<1>(Mareacode)[2-9][0-8]x xxxx)
This is a rather bizarre US DigitMap. It supports the following formats:
8-digit numbers which start with a 1
10-digit numbers which then have a 1 prepended
7-digit numbers which then have a 1 + areacode prepended
Quote from: larrybob on April 14, 2012, 11:48:49 pm
Digitmap Phone :
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|<**1><011>(Mus)|**8{t=di}(Mli)|**9{t=od}(Mpp)|(Mpli))
Digitmap AA :
([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|<00:$1>|0|<**1><011>(Mus)|**2(Msp2)|**8(Mli)|**9(Mpp)|(Mpli))
You reference the US DigitMap from the main level PHONE Port and Auto Attendant DigitMaps which puts it in direct competition with the LINE Port DigitMap (via Mpli since PrimaryLine is set to PSTN Line), but you don't show the LINE Port DigitMap contents. Assuming the US DigitMap wins, you then prepend the 011 international prefix and redirect it to SP1 with **1. This will bring the SP1 DigitMap into play via the OutboundCallRoute, but you don't show the SP1 DigitMap contents.
Quote from: larrybob on April 14, 2012, 11:48:49 pm
the call should either work or fail in both places, not only work with the phone.
You've never described how the call fails and what, if anything, is shown in Call Status during the call or Call History following the call. It's likely there is a conflict between competing rules and it just happens that, due a slight difference in the way the Digit Map Processor (DMP) is invoked between the PHONE Port and the Auto Attendant, the conflict isn't resolved identically in both cases. You could call that a bug, but it's probably as much your fault for putting the DMP in that position by having conflicts.
This is a good example of why I generally discourage making any significant changes to the main level PHONE Port and Auto Attendant DigitMaps (and OutboundCallRoutes) without a very good reason for doing so. It's really easy to get things tangled up at this level.
I think you need to take a step back and take another look at your overall goals and seek a cleaner approach.
larrybob:
thanks for finding my error in the us digitmap...
I added the correct number of digits :
(1[2-9][0-8]x xxx xxxx|<1>[2-9][0-8]x xxx xxxx|<1>(Mareacode)[2-9][0-8]x xxxx)
so if a 7 digit or 10 digit or 1 plus 10 digit number is called they will all be transformed into a 1 plus 10digit number.
there is no conflict with the line digit map this is it (as I stated it is the default ) :(xxxxxxxS4|1xxxxxxxxxx|xx.)
the SP1 Digitmap is also wide open: (*xx|xx.|(Mipd)|[^*]@@.'@'@@.)
I do not see any conflicts . When the call fails I get a SIT tone and nothing appears in the Call Status or history when the call fails.
I believe that this is the Problem:
In the Calldigit map you can replace the logical <415> with a digit map... in the aa digitmap this replacemet IS NOT ALLOWED and the full "areacode" digit map needs to be written out in full.
This is why if "areacode" is defined as
(<1415>[2-9][0-8]x xxxx)
and "us" defined as:
(1[2-9][0-8]x xxx xxxx|(Mareacode)|<1>[2-9][0-8]x xxxx)
The call will go through using AA
however if "areacode" is :
(<415>)
and "us" defined as :
(1[2-9][0-8]x xxx xxxx|<1>[2-9][0-8]x xxx xxxx|<1>(Mareacode)[2-9][0-8]x xxxx)
The digit map will fail in the AA and nothing will happen.
Either map will work from the phone!( The short definition of "areacode" or the long definition.)
I do not think the problem is due to conflicts, but I will contend that the Digitmap processor treats the AA and phone digitmaps differently. This might not be a bug, but in the least it is not documented.
I think I was getting a little too cute with my code, and will go with the longer digitmap and call that "areacode":
(<1415>[2-9][0-8]x xxxx) . This works in all situations.
Larry
Navigation
[0] Message Index
[*] Previous page