My personal preference is to route 911 direct from the Phone Port OutboundCallRoute. This avoids any possible conflicts or delays in the digitmaps:
Physical Interfaces > PHONE Port 1/2 > OutboundCallRoute:
{911:sp2},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**9:>(Mpp)):pp},{(Mpli):pli}
Quote<1?:**21>613xxxxxxx|<1?:**21>815xxxxxxx
This is logical and follows the rules in the AdminGuide precisely. However, I have tried this myself and found a problem. Here is what I posted:
QuoteI tried to have smaller/neater digit maps by using a rule such as 1?800xxxxxxx (1 or no 1 followed by 800 etc). This works fine in a digit map on its own. However, when sharing a digit map with rule 1xxxxxxxxxx even if you dial 18002345678 the Digit Map Processor will use rule 1xxxxxxxxxx as the best match. It seems that "1" always takes precedence over "1?"
Of course, the OP will not have any problem if they don't dial the "1".
In my config, 911 is routed as described above. I don't know if FPL needs the "1" or not. If it does then the ITSP A digitmap would be:
Service Providers > ITSP Profile A > General > DigitMap:
(<**21>613xxxxxxx|<**21>815xxxxxxx|<**2>1613xxxxxxx|<**2>1815xxxxxxx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
Sorry to raise such obscure points in this post, but these things can have you going around in circles for days - as I well know