DigitMap and In/Outbound CallRoute Tutorial
QBZappy:
Quote from: azrobert on January 18, 2013, 11:17:47 pm
Dialing remains the same for local trunks on both OBi110s.
OBi110#1 can call out on the OBi110#2's SP1 by dialing "214085551212" or 295551212 to make a local call on OBi100#2's PSTN.
OBi110#2 can call out on the OBi110#1's SP1 by dialing "114085551212" or 195551212 to make a local call on OBi100#1's PSTN.
I think it would be difficult to call using the OBi100's PSTN trunk. Maybe that was a typo.
azrobert:
Yes, it was a typo and has been corrected.
Is that all you have to say?
azrobert:
A common way people config their OBi's is to add a "**x" prefix to the dialed number in the Phone DigitMap (usually referring back to the Primary DigItMap), then the default Phone OutboundCallRoute strips the "**x" prefix and makes the call.
This is a two step process where the Phone DigitMap verifies the number, makes any needed modifications to the number and determines the trunk. The default OutBoundCallRoute just strips the "**x" prefix and makes the call.
If this is the only thing the OBi is doing I have NO problem with this method. In fact it can make the config very easy.
I think there is problem if you use the InboundCallRoutes to reroute calls. There is no two step process, only the InboundCallRoute. Therefore, you have to come up with a different process. This makes the config more complicated.
My method uses a separate user defined Phone DigitMap that only verifies the dialed number. The DigitMap portion of the Phone OutboundCallRoute rules re-verifies the dialed number, makes any modifications and determines the trunk. Then the Phone OutboundCallRoute makes the call. You have to add a new rule for every trunk to the Phone OutboundCallRoute.
Since the DigitMaps does basically everything, you can use the same process for the Trunk InboundCallRoute as the Phone OutboundCallRoutes.
If you look at my config all the trunks use the same DigitMaps as the Phone OutboundCallRoute rules. IMHO this makes the config easier and any modifications easier.
Assume there is a new requirement for SP1. Only the SP1 DigitMap has to be modified and maybe the user defined DigitMap. The InboundCallRoutes would automatically be updated because they refer back to the SP1 DigitMap.
I hope I didn't put everyone to sleep.
ianobi:
Quote
In my example the OBION App could dial PP(ob200.....) to ring the Phone Port on the OBi110, but what if the device was an OBi202. Which Phone Port would ring or would both?
azrobert - I don't have an OBi202 to try this, but rules such as these on an InboundCallRoute should work:
{(Mcot)>111:ph1},{(Mcot)>222:ph2}
Quote
Judging by the number of responses I received, not too many people were impressed by my post.
I think there are two sets of users here: One set just wants it to work as they want; others, like us, want to do that, understand how it all works and make the OBi devices do things that others have yet to think of.
I think other users cherry pick parts of our posts that suit their particular needs. This is fair enough, it's how I started, mostly picking bits out of RonR posts :)
azrobert:
Quote from: ianobi on January 25, 2013, 02:55:35 am
Quote
In my example the OBION App could dial PP(ob200.....) to ring the Phone Port on the OBi110, but what if the device was an OBi202. Which Phone Port would ring or would both?
azrobert - I don't have an OBi202 to try this, but rules such as these on an InboundCallRoute should work:
{(Mcot)>111:ph1},{(Mcot)>222:ph2}
I think you misunderstood my question.
If the OBION APP dialed PP(290....) from a speed dial calling an OBi110, PH1 would ring.
You are not passing any data to test.
If the target is an OBi202 you can't test for a string to route the call to a particular phone, so which phone would ring?
I also don't have an OBi202. Just being curious.
FYI I just ordered another OBi110, so now I can do my own remote testing. I couldn't resist the $39.99 sale at NEWEGG.
Navigation
[0] Message Index
[#] Next page
[*] Previous page