News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Help with outgoing international call routing

Started by dhobi, February 23, 2012, 11:47:18 AM

Previous topic - Next topic

dhobi

I just got an OBI100 device, read through the manual and I'm having a hard time figuring out how to set up proper call routing. Here's my setup:

SP1 - default, want to use only for US calls
SP2 - want to use only for international calls as SP1 is too expensive for that

For international calls, I wan to be able to dial the following formats from the phone:

011 44 1234567 (where 44 is the country code and used just as an example here)
00 44 1234567
+ 44 1234567

Any of the above I want to be routed to SP2, in other words re-written as **2 00 44 1234567, so I need the following substitutions:
011 --> **2 00
00   --> **2 00
+    --> **2 00  (not sure I really need this plus format, but I'm curious if it can be done)

Could you please help with what changes I need to make and where? I'm not sure about "Phone DigitMap" and "Phone OutboundCallRoute", whether I need to use both of them in conjunction or only one is enough and if so which one.

Also where would I make this change? In the "Setup Wizard" on the device directly or is there a way to do it via the OBITalk interface?

I wish there was an easy wizard to do this as I'm sure it is a very popular scenario.

dhobi

Is there a way to debug the rules, in other words simulate dialing without actually making the phone call just to validate the routing?

I'm thinking that the following OutboundCallRoute rule will do, though I can't test it at the moment:

{((00 | <011:00> | <+:00>)@.):sp2}

Am I on the right track here?



RonR

I prefer to leave the PHONE Port DigitMap and OutboundCallRoute unaltered if at all possible and do the translations on the PrimaryLine's DigitMap.  Try this:


Service Porviders -> ITSP Profile A -> General -> DigitMap:

(<1aaa>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|1xxxxxxxxxx|<**2>(011|00|+)xx.|<8835100>xxxxxxxx|8835100xxxxxxxx)

where aaa is your local area code.


Service Porviders -> ITSP Profile B -> General -> DigitMap:

(<+:00>xx.|<011:00>xx.|00xx.)

dhobi

Nice solution. I didn't know that the primary line's DigitMap gets evaluated first, before the OutboundCallRoute rules. So what's the order?
1. Phone Port DigitMap
2. Primary Line DigitMap (SP1 in my case)
3. OutboundCallRoute
4. Selected SP DigitMap (SP2 in my case)
5. anything else?

I think your approach is a bit more complicated and more error prone for the future if for example I delete SP1 and replace it with a different provider. I'd have to remember to then re-add the rules.

Any reason why modifying the OutboundCallRoute is a bad idea or just a matter of preference?

RonR

Dialing a number from the OBi PHONE Port involves two distinct stages of processing.

The first stage is a digit-by-digit evaluation of the number being dialed.  Evaluation is done on the PHONE Port DigitMap only.  All references to other DigitMaps must be made indirectly from the PHONE Port DigitMap.  The Digit Map Processor (DMP) returns the dialed number when the best matching rule is found, with possible transformation being performed by that matching rule.

The second stage is an evaluation of the number returned by the DMP using the OutboundCallRoute.  The first matching rule found determines which trunk the call is routed through.

There is a tight coupling between the design of the PHONE Port DigitMap and OutboundCallRoute as they typically share the same DigitMap rules.  This is why one must use careful consideration before making any changes at this level.

Making changes to the DigitMaps which have been segregated to individual trunk configuration areas (but indirectly referenced from the PHONE Port DigitMap), keeps things organized and clear what rules are associated with each trunk and actually simplifies future changes.

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.

RonR

Quote from: dhobi on February 23, 2012, 11:38:10 PM
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.

Good luck with it.