Help with outgoing international call routing
dhobi:
It's starting to make some sense now.
My current (and default) Phone DigitMap is:
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|**1(Msp1)|**2(Msp2)|**9(Mpp)|(Mpli))
So you are saying it works to put my mapping rules in the SP1 (Primary Line in my case) DigitMap because it's referenced by the last entry in the Phone DigitMap above "(Mpli)"?
Would it be equivalent to define a user DigitMap and just reference it in the Phone DigitMap?
Would your approach where I put the rules in the SP1 DigitMap prevent me from explicitly forcing an int'l call through SP1 by dialing **1 in front of the number?
RonR:
Quote from: dhobi on February 23, 2012, 08:32:58 pm
So you are saying it works to put my mapping rules in the SP1 (Primary Line in my case) DigitMap because it's referenced by the last entry in the Phone DigitMap above "(Mpli)"?
Yes. Occurrences of pli in DigitMaps and OutboundCallRoutes are replaced by the PrimaryLine value (sp1/sp2/li/pp).
Quote from: dhobi on February 23, 2012, 08:32:58 pm
Would it be equivalent to define a user DigitMap and just reference it in the Phone DigitMap?
You can add a User Defined DigitMap reference to the PHONE Port DigitMap and OutboundCallRoute if applicable.
The change I proposed to the SP2 DigitMap is so that all calls routed to SP2 in any way transform '+' and 011 to 00 (I assume the SP2 service provider wants all calls prefixed with 00).
If you add a User Defined DigitMap of (<**2>(011|00|+)xx.) to the PHONE Port DigitMap instead of doing the redirection on the PrimaryLine DigitMap, it's not clear what the result would be when you dial 011, as the User Defined DigitMap rule is an equal match to the 011 rule in the SP1 and SP2 DigitMaps (you'll have two 011 rules matching, one adding **2 and the other not). What the DMP does in this case is not spelled out and the result could be position dependent.
Quote from: dhobi on February 23, 2012, 08:32:58 pm
Would your approach where I put the rules in the SP1 DigitMap prevent me from explicitly forcing an int'l call through SP1 by dialing **1 in front of the number?
The SP1 DigitMap will be referenced if no **1 is used and the PrimaryLine is SP1 Service OR if **1 is used regarless of the PrimaryLine setting.
dhobi:
Quote
The change I proposed to the SP2 DigitMap is so that all calls routed to SP2 in any way transform '+' and 011 to 00 (I assume the SP2 service provider wants all calls prefixed with 00).
It definitely does not accept 011, but I think + works. It doesn't matter, 00 works all the time, so the mapping is fine.
Quote
If you add a User Defined DigitMap of (<**2>(011|00|+)xx.) to the PHONE Port DigitMap instead of doing the redirection on the PrimaryLine DigitMap, it's not clear what the result would be when you dial 011, as the User Defined DigitMap rule is an equal match to the 011 rule in the SP1 and SP2 DigitMaps (you'll have two 011 rules matching, one adding **2 and the other not). What the DMP does in this case is not spelled out and the result could be position dependent.
I thought it stopped at the first match, so if I put the user defined DigitMap first in the Phone Port DigitMap it might work.
Quote
Quote from: dhobi on February 23, 2012, 08:32:58 pm
Would your approach where I put the rules in the SP1 DigitMap prevent me from explicitly forcing an int'l call through SP1 by dialing **1 in front of the number?
The SP1 DigitMap will be referenced if no **1 is used and the PrimaryLine is SP1 Service OR if **1 is used regarless of the PrimaryLine setting.
It sounds like I will not be able to force using SP1 for int'l calls for cases where SP2 is down and I'm willing to pay more by using SP1. Or am I missing something here?
RonR:
Quote from: dhobi on February 23, 2012, 09:46:01 pm
It definitely does not accept 011, but I think + works. It doesn't matter, 00 works all the time, so the mapping is fine.
I just tested it here and 011 does work. There is a small anomaly, however. If you dial 011 + 5 digits, it matches the <8835100>xxxxxxxx rule that allows dialing just the last 8 digits of an iNum number. That rule has to go and you will have to dial the entire 15 digits of an iNum number:
Service Porviders -> ITSP Profile A -> General -> DigitMap:
(<1aaa>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|1xxxxxxxxxx|<**2>(011|00|+)xx.|8835100xxxxxxxx)
Quote from: dhobi on February 23, 2012, 09:46:01 pm
I thought it stopped at the first match, so if I put the user defined DigitMap first in the Phone Port DigitMap it might work.
Evaluation of the PHONE Port OutboundCallRoute stops at the first match. Evaluation of the PHONE Port DigitMap stops when there are no more candidates for a match, an interdigit timout occurs, or a terminating # is dialed.
Quote from: dhobi on February 23, 2012, 09:46:01 pm
It sounds like I will not be able to force using SP1 for int'l calls for cases where SP2 is down and I'm willing to pay more by using SP1. Or am I missing something here?
That is a tradoff of the simpler approach. If you need full flexibility, this should do it:
Service Porviders -> ITSP Profile A -> General -> DigitMap:
(<1aaa>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|1xxxxxxxxxx|011xx.|8835100xxxxxxxx)
where aaa is your local area code.
Service Porviders -> ITSP Profile B -> General -> DigitMap:
(<+:00>xx.|<011:00>xx.|00xx.)
Physical Interfaces -> PHONE Port -> DigitMap:
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|**1(Msp1)|**2(Msp2)|
**8(Mli)|**9(Mpp)|(Mintl)|(Mpli))
Physical Interfaces -> PHONE Port -> OutboundCallRoute:
{([1-9]x?*(Mpli)):pp},{(<#:>|911):li},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},
{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mintl):sp2},{(Mpli):pli}
User Defined Digit MapX
Label : intl
DigitMap : ((011|00|+)xx.)
dhobi:
OBI Support emailed me and they suggested that I use OutboundCallRoute with a simple rule that I set first. Sounds like the easiest thing to do for a very simple setup such as I have.
Navigation
[0] Message Index
[#] Next page
[*] Previous page