Help setting up call routes for OBi202

[jadog]

I have an OBi202 and have attempted to configure using OBi Expert (unsuccessfully). I have the following service providers currently setup to point to Phone port 1:

SP1 - Anveo
SP2 - Flowroute
SP3 - DIDLogic
SP4 - Google Voice

Anveo of course is my primary service provider. Since Flowroute provides free 800 (toll-free) service, I would like to configure it to be automatically used for any outbound 800 numbers. Then DIDLogic has the best international rates I could find, so I would like to use that for any outbound international calls. Then finally, I don't use Google Voice often, but would like to be able to dial 9 and this would cause the outbound call to use GV. So to re-iterate it would look like the following:

SP1 - Anveo |  Primary provider. Only used to dial 800 numbers and international if SP2 and SP3 fail.
SP2 - Flowroute  |  Used to call 800 numbers
SP3 - DIDLogic  |  Used to call international numbers
SP4 - Google Voice  |  Used when first dialing 9


The current DigitMap below (for the ITSP Providers) is the default and the same for all four providers. Do I need to modify this?

Code Select Expand


(*xx|1xxxxxxxxxx|<1260>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*]@@.)


The current OutboundCallRoute is the default for Phone 1:

Code Select Expand

{911:sp1},{933:sp1},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<#:>):ph2},{(<**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}

I added the below code to the front of the OutboundCallRoute for the international calls on SP3 and toll free calls on SP2.

{(011xx.):sp3},{(18(00|88|77|66|55|44)xxxxxxx):sp2},{

What do I need to add here to be able to dial 9 to get Google Voice to work on SP4?

[azrobert]

You need to dial "9" as a prefix on a 10 digit number.

In the ITSP A DigitMap change 1xxxxxxxxxx to [19]xxxxxxxxxx
This plus the Phone DigitMap is used to validate all dialed numbers.
(Mpli) in the Phone DigitMap points to the Primary Line's (ITSP A) DigitMap.
Now a number like 94805551212 will be validated.

Add {(<9:>xxxxxxxxxx):sp4} to the outbound route.
GV doesn't require a "1" prefix.
If you want it use {(<9:1>xxxxxxxxxx):sp4}

If you want to have automatic failover to SP1, you need to setup a trunk group. This will require changes to all your trunk DigitMaps.

[jadog]

Thanks for the excellent explanation! Though I'm not sure I fully understand the ITSP DigitMap change. If I use [19]xxxxxxxxxx, won't that allow for dialing 900 numbers? I don't really want that.

I understand that GV doesn't require the "1" prefix. So if I use it with {(<9:>xxxxxxxxxx):sp4} at the front, what happens if does dial a the "1" prefix? If I use the second option, wouldn't that allow for both and thus preventing possible user error?

You have me intrigued with the mention of the possibility of setting up as a trunk group for use with failover. Can you point me to some guides on how to do this? I did a search on this forum and came back with very little. From what I did read however, it would seem that the failover isn't instant. In other words, if a call fails with one provider, it may take more than a minute or two for it to re-route. Maybe I didn't read correctly, but that's what I understood.

[azrobert]

You can implement this in different ways. The way I chose is to dial 9 followed by 10 digits. If you also want to allow dial 9 followed by 11 digits, you will need another rule. Let me know if you want this. You can also try setting this up yourself. Post what you did and I'll check for errors.

Rule [19]xxxxxxxxxx is checking for "1" or "9" followed by 10 digits, so this doesn't add 900 numbers. Your current rules 1xxxxxxxxxx or <1>[2-9]xxxxxxxxx will allow 900 numbers. There are a couple ways to block 900 numbers. One is to add another rule in the outbound route like this:
{([19]900xxxxxxx):}
This will route 900 numbers to nowhere. If you are adding rules for 9 followed by 11 digits, don't forget to block 900 numbers.

I don't know a good guide on trunk groups. They work differently than the normal OBi processing. The failover normally takes 32 seconds, but there are ways to speed up the process. Today is turkey day at my sister-in-law's and I have to start to get ready, so I don't have time now. I'll write something when I get back.

[jadog]

Thanks for taking time out of a likely busy Thanksgiving day to help me. You rock! I'll play around with the settings you recommended and report back in a few days. Happy Thanksgiving to you and your family!!!

[azrobert]

Phone DigitMap: Current Default

Phone outbound route:
{([19]900xxxxxxx):},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<#:>):ph2},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**9:>(Mpp)):pp},{(Mpli):pli}

Phone Primary Line: Trunk Group 1

ITSP A DigitMap:
(911|933|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.S3)

ITSP B DigitMap:
(18(00|88|77|66|55|44)xxxxxxx)

ITSP C DigitMap:
(011xx.S3)

ITSP D DigitMap:
(<9:>xxxxxxxxxx|1xxxxxxxxxx)

Voice Services -> Gateways and TGs -> Trunk Group 1
Trunk List: sp2,sp3,sp1,sp4
DigitMap: ((Msp1)|(Msp2)|(Msp3)|9xxxxxxxxxx)

Voice Services -> SP1, SP2 and SP3 Service: X_NoRegNoCall: Checked

Service Providers ITSP A, B and C -> SIP -> TimerB: 10000

TGs use a 3 step process to route calls.

1st the Phone DigitMap validates the dialed number.
(Mpli) points to the primary line which is TG1  DigitMap.
TG1 points to ITSP A, B and C DigitMaps and 9xxxxxxxxxx
All these DigitMaps should validate all numbers.

In the outbound route {(Mpli):pli}
(Mpli) points to TG1 DigitMap and pli points to TG1
If the dialed number matches a rule in the TG1 DigitMap, TG1 gets control.

TG1 will process the trunks in the trunk list left to right.
If the call fails in the 1st trunk, processing will move to the next trunk.
The call can fail in 2 ways, the trunk is down or the dialed doesn't match the corresponding DigitMap.

If you dial an international number:
The 1st trunk in the list is SP2.
The dialed number doesn't match a rule in ITSP B DigitMap, so the processing moves to SP3.
The dialed number matches a rule in ITSP C, so the call is routed to SP3.
If the trunk is down, processing will move to SP1.
The dialed number matches a rule in ITSP A, so the call is routed to SP1.

Each trunk in the trunk list uses its corresponding DigitMap. This can't be changed. This is different than the normal outbound route process where you can compare the dialed number to virtually anything to route the call to a trunk.

I didn't use (Msp4) in the TG1 DigitMap.
If I did, rule <9:>xxxxxxxxxx would remove the "9" prefix during the phone DigitMap processing.
When the outbound route processes the dialed number, it will be 10 digits and be routed to SP1, not SP4.

When X_NoRegNoCall is enabled the call will immediately failover when the trunk is not registered to the provider.
It is my understanding (I might be wrong) that the OBi might think the trunk is still registered when the trunk is down. There is a registration period and the OBi might not know the trunk is down until the registration period expires and the OBi tries to re-register. In this case the OBi will wait 32 seconds (defined in TimerB) before it failovers. I changed TimerB to 10 seconds. You can probably make it less.

I removed all the **1 thru **4 processing in the outbound call route. You can remove any other rules you're not using. You can do the same in the phone DigitMap.

Disclaimer:
No guaranty the above is error free.

[jadog]

Wow! This is incredibly helpful. I'll give it a try as soon as I have a chance and I'll report back. Thanks again for the help!!

[jadog]

Ok, so I finally found the time to try this. However, after configuring the settings as you have laid out, it seems to only ever route through SP1, even though I'm dialing 800 numbers or international (011) numbers. When I try to dial 9 before a number so that it will use GV, it gives the message "The number you have dialed has not been recognized...". I made the changes from the OBI device IP address rather than using the Obi Expert. Do I need to do it both places? Any thoughts on what else I might be doing wrong? I've rebooted the device multiple times.

[azrobert]

I made the changes from the OBI device IP address rather than using the Obi Expert. Do I need to do it both places?

You must make these modifications in OBi Expert. If you make these changes via the local interface, OBiTalk will overlay the changes with the previous configuration.
If you want to use the local interface, you must disable OBiTalk Auto Provisioning. When Auto Provisioning is disabled you won't be able to use OBiTalk to make configuration changes. In other words, you can only use 1 method to configure you OBi. 

[jadog]

Then that sounds like my problem. I'll make the change in OBi Expert and report back.

[jadog]

Awesome! Everything seems to be working now except for Google Voice. I still get the message "The number you have dialed has not been recognized..." when I dial a 9 followed by 10 digits. I also tried using 9 followed by 11 digits (using the 1 prefix), and it was the same as well.

[azrobert]

The GV calls should be a 9 followed by 10 digits.
Please check the Call History to see where the GV call is routed.
Log into the OBi202 via the local interface.
Click Status then Call History.
I suspect the call is being routed to SP1 (Anveo).
If I'm right, did you remove the default rule xx. from the ITSP A DigitMap?

[jadog]

I checked the call history and it is indeed being routed to SP1. Below is what I have for the ITSP A DigitMap:

(911|933|1xxxxxxxxxx|<1260>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|011xx.S3)

Do I need to change it?

[azrobert]

It looks good.
What does the call history show as the number going out SP1?
Did it truncate a digit from the right?
Please post your Phone Port DigitMap.

[jadog]

Here is the call from history:

From PH1   To SP1(93367813962)

Nothing truncated. Below is the Phone1 digit map. This is the default original one and I did not edit.

([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|##|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))

[azrobert]

I don't see the problem.
There isn't a rule in the ITSP A DigitMap that will match an 11 digit number beginning with "9", so it shouldn't get routed to SP1.
It does have a rule that will match 933, but it shouldn't match an 11 digit number starting with 933.
Try dialing a number that doesn't begin with 933 and see what happens.

[jadog]

Same thing. Here's the log.

From PH1   To SP1(92608441605)

Ok, how about this instead. Not sure if it's possible, but can we adjust the failover so that SP1 fails over to SP4? In other words if Anveo has a disruption in service, it will failover to GV. That's basically the only reason I have GV setup anway. Then I can always still use the **4 in front to force it through instead of the 9.

[azrobert]

Anveo is already setup to failover to GV. ITSP A and D both have a rule to match 11 digits. When dialing 11 digits the TG will process the trunk list left to right. It will match 1xxxxxxxxxx in ITSP A first and try to route the call to SP1. If SP1 fails, the TG will try the next entry in the trunk list (SP4). It will match 1xxxxxxxxxx in ITSP D and try to route the call to SP4. The config I gave you will only failover 11 digit numbers. 10 digits will also work because it will be converted to 11 digits before this process begins. If you want to failover international calls, add 011xx.S3 to the ITSP D DigitMap.

I removed the **4 code because I didn't think you would need it. Instead of adding back **4, let's try to fix the 9 prefix by processing it outside of the TG.

Use the following Phone Outbound Route:
{([19]900xxxxxxx):},{(<9:1>xxxxxxxxxx):sp4},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<#:>):ph2},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**9:>(Mpp)):pp},{(Mpli):pli}

Now try 9 followed by 10 digits.

[jadog]

Ok, so that works perfectly and the call was routed through Google Voice. What does that mean?

[azrobert]

The call is routed to the TG by the last rule in the outbound route, {(Mpli):pli}
pli points to the Primary Line, so the above rule gets translated to: {(Mtg1):tg1}
TG1 wasn't processing GV calls correctly, so I fixed the problem by adding another rule before the last rule to process GV calls outside the TG.

I can only think of 3 possibilities:
1. I don't see the coding error
2. I don't understand how trunk groups work
3. There is a bug in the firmware

What firmware level are you running?
If you're not at the current firmware level, you can try upgrading.