News:

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

Main Menu

DigitMap and In/Outbound CallRoute Tutorial

Started by azrobert, January 18, 2013, 11:12:33 PM

Previous topic - Next topic

azrobert

I've helped several people with their dialing rules by suggesting fixes to what they have already done, but never showed the forum how I setup my own dialing rules.  This example follows my coding philosophy. I tried to include the most common requirements.

First, a lot of people don't understand the process.  Here is what happens after a number is dialed.

- The Phone DigitMap validates the number dialed.
  The dialed number can be modified.
  If the number is validated it's passed to the Phone OutboundCallRoute.

- The Phone OutboundCallRoute determines the trunk and makes the call.
  The dialed number can be modified.

Notice there is no mention of the trunk DigitMaps.  The trunk DigitMaps do nothing by themselves. They are only relevant when referred to by the Phone DigitMap or Phone OutboundCallRoute.

Here's what I'm trying to accomplish in this example:

SP1 - 7, 10 or 11 digits numbers. Add local area code to 7 digits.
SP2 - 10 digits numbers with prefix "2".  Strip prefix and replace with "1".  International calls.  
VG3 - 11 digit 1-800 numbers.
LIne - 7 and 10 digit numbers with prefix 9. Strip prefix.  Replace prefix with "1" on 10 digit call. Skip adding country code for  area code "602".  "9" for dial tone on PSTN line.

Setup a user defined DigitMap to only validate and not modify the dialed number for all trunks. I'm naming it "ud1" and it looks like this:
([129]?xxxxxxxxxx|9?xxxxxxx|011xx.|9)

[129]?xxxxxxxxxx validates 10 and 11 digit numbers for all trunks.
9?xxxxxxx validates 7 digit numbers for SP1 and Line.
011xx. validates international calls for SP2.
9  for Line.

Place (Mud1)| at the beginning of the default Phone DigitMap.
If you don't want to create a User Defined DigitMap place the above rules at the beginning of the default Phone DigitMap.

Trunk DigitMaps:
SP1 DigitMap = (1?xxxxxxxxxx|<480>xxxxxxx)
SP2 DigitMap = (<2:1>xxxxxxxxxx|011xx.)
VG3 DigitMap = (18(00|88|77|66|55|44)xxxxxxx)
Line DigitMap = (<9:>602xxxxxxx|<9:1>xxxxxxxxxx|<9:>xxxxxxx|<9:>)

Place the following at the beginning of the default Phone OutboundCallRoute:
{(Mvg3):vg3},{Msp1:sp1},{(Msp2):sp2},{(Mli):li},

All the substitution is accomplished in the Phone OutboundCallRoute by referring back to the Trunk DigitMaps.  Notice that I placed VG3 first.  If I didn't all 1-800 numbers would go out SP1.


For those of you that re-route calls from another ATA/OBiApp  this coding technique incorporates very easily without changing any code. The remote ATA/OBIApp would dial the outgoing number in the same format as the local OBi. Setup Speed Dial #9 on the OBION App to dial "9" to get dial tone on the PSTN line.


SP2 X_InboundCallRoute:
{(userid)>(Mvg3):vg3},{(userid)>(Msp1):sp1},{(userid)>(Msp2):sp2},{(userid)>(Mli):li},{(userid)>:},{ph}

OBiTalk InboundCallRoute:
{(2xxxxxxxx)>(Mvg3):vg3},{(2xxxxxxxx)>(Msp1):sp1},{(2xxxxxxxx)>(Msp2):sp2},{(2xxxxxxxx)>(Mli):li}}

That's it.

To summarize my coding technique:
- The Phone DigitMap only  does validation.  No modifications.
- A trunk's DigitMap only contains rules for its self.
- Refer back to the trunk DigitMaps in the Phone OutboundCallRoute or InboundCallRoutes.
-When you code this way the Phone OutboundCallRoute and all the InboundCallRoutes can use the same DigitMaps.

I'm biased, but I think this config is concise and easy to understand and modify.
You can look at a trunk DigitMap and know exactly what's happening on that trunk.
I'm not saying this is the only way to go.  Ultimately it's the end user that decides which technique is best for his/her requirements.

Disclaimer:
I did not test this config, so please don't beat me up too badly if you find errors.

azrobert

#1
I want to show you how easily this config can be modified for additional requirements.
Say you bought another OBi110 and you wanted each OBi110 to access the other's trunks.

Each OBi will be configured the same except for some minor differences.
Add a second prefix of "1" or "2" to the dialed number.
These would only be used to dial the other OBi110's trunks.
"1" for the OBi110#1 and "2" for the OBi110#2.
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 OBi110#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 OBi110#1's PSTN.  

No changes required for the following:

SP1 DigitMap = (1?xxxxxxxxxx|<480>xxxxxxx)
SP2 DigitMap = (<2:1>xxxxxxxxxx|011xx.)
VG3 DigitMap = (18(00|88|77|66|55|44)xxxxxxx)
Line DigitMap = (<9:>602xxxxxxx|<9:1>xxxxxxxxxx|<9:>xxxxxxx|<9:>)
SP2 X_InboundCallRoute:
{(userid)>(Mvg3):vg3},{(userid)>(Msp1):sp1},{(userid)>(Msp2):sp2},{(userid)>(Mli):li},{(userid)>:},{ph}
OBiTalk InboundCallRoute:
{(2xxxxxxxx)>(Mvg3):vg3},{(2xxxxxxxx)>(Msp1):sp1},{(2xxxxxxxx)>(Msp2):sp2},{(2xxxxxxxx)>(Mli):li}
Phone OutboundCallRoute:
{(Mvg3):vg3},{Msp1:sp1},{(Msp2):sp2},{(Mli):li},
ud1 user defined DigitMap:
([129]?xxxxxxxxxx|9?xxxxxxx|011xx.|9)

Make the following changes:

Speed Dial 21 =  PP(ob200100001)
Speed Dial 22 =  PP(ob200100002)

create another user defined DigitMap "ud2":
(<2:22*>1xxxxxxxxxx|(<2:22*>2xxxxxxxxxx|<2:22*> 9xxxxxxx|<2:22*>9)

Place (Mud2)| at the beginning of the  Phone DigitMap.

That's four lines of code for both OBi110s to have access to the other's trunks.
I didn't allow 7 digit dialing on SP1 or 1xxxxxxxxxx on PSTN.
These didn't make sense.
I didn't allow international calls because rule "<2:22*>011xx." could match a domestic number.  Coding more of the number would solve that problem.
Speed Dials 9 and 29 must be blank so "9" and "29" can be dialed to access PSTN dial tone on both OBis.
Different Speed Dials might have to be defined on OBi110#2 to ring remote devices.

I could have used 1 Speed Dial, so both OBis would use the same SD to access each other.
I did it this way in case you wanted to add more devices.
Each OBi would have its own speed dial.

I know I'm breaking my rule of no modifications in the Phone DigitMap, but rules are meant to be broken. LOL

These are the config differences between OBis:
OBi110#2 would use a different area code in its SP1 DigitMap for 7 digit dialing.
It would use prefix "1" and Speed Dial 21  to access OBi110#1. The User Defined DigitMap "ud2" would be changed to reflect this.
Speed Dials 9 and 19 must be blank so "9" and "19" can be dialed to access PSTN dial tone on both OBis.

BIG Disclaimer:
I only have one OBi110, so I could not test this configuration.
I have never done a config like this.
This is my understanding how accessing another OBi's resources work.

ianobi

azrobert,

A very interesting post. The good clear explanation of how the Phone Port DigitMap and OutboundCallRoutes work will be helpful to many users.

Using ud2 as a "look-up table" is interesting. It allows for each OBi to have a plain number, 1, 2, 3 etc, but each can be allocated almost any speed dial number.

As you say, there's always more than one way to do things with OBi configuring, but it's good to feed off each others' ideas.

Ostracus

Quote from: ianobi on January 19, 2013, 03:28:29 AM
As you say, there's always more than one way to do things with OBi configuring, but it's good to feed off each others' ideas.

BRAAAINS! ;D

azrobert

I did not know how an OBION App could dial "9".  I have since figured it out and have updated my post.  Just setup Speed Dial#9 to dial "9".

I have a question.  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?  How would you ring the other port without calling the PSTN number pointing to it?

Judging by the number of responses I received, not too many people were impressed by my post.  I suppose someone with a working device would not reconfigure even if they liked my coding technique.  I don't think I would.

Anyway, I hope my effort helps a least one person out there.

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.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

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

QuoteIn 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}

QuoteJudging 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

#9
Quote from: ianobi on January 25, 2013, 02:55:35 AM
QuoteIn 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.

azrobert

Quote from: ianobi on January 25, 2013, 02:55:35 AM

QuoteJudging 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  :)

There a number of people on this forum that are WOWed by anything you post.

I guess I'm a bit jealous.


ianobi

QuoteI think you misunderstood my question.
This happens to me a lot   :)

Back to the 202:

As you know the default OBiTALK InboundCallRoute is ph,ph2 so if you call just its OBiTALK number, say 500123456, both phones ring. If you change the InboundCallRoute to:
{(Mcot)>111:ph1},{(Mcot)>222:ph2},{ph,ph2}

Then in the calling OBi setup Speed dials:
slot 30 is pp(ob500123456)
slot 31 is 30*111
slot 32 is 30*222

Then from the calling OBi Phone Port, or any OBiON/OBiAPP which uses the calling OBi as a gateway, dial:
**9500123456 calls OBi 500123456 phones 1 and 2
31# calls OBi 500123456 phone 1
32# calls OBi 500123456 phone 2

The calling OBi number is in "cot".

Using my OBi110 setup I have tried this as far as I can proving all the formats. Maybe someone with a 202 would test it out.

QuoteFYI I just ordered another OBi110, so now I can do my own remote testing.  I couldn't resist the $39.99 sale at NEWEGG.
This is a good idea for testing. I did the same when there was an offer on. I still get confused switching between screens configuring two Obi110s at the same time. More brain cells needed   :D

carl

Quote from: ianobi on January 25, 2013, 02:55:35 AM
QuoteIn 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}

QuoteJudging 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  :)

Obi really spent some effort to make it really difficult for us, in spite of all the pleas. Right, cherry picking. I could win the lottery, buy another Obi or two to play with, pay somebody accepting my test calls and calling me round the clock and maybe, just maybe,in a few months i will have the expertise of RonR. But I cannot afford that, nor can I afford to buy an equipped  garage and start fixing my truck myself. So for the time being, I will have to keep on cherry picking . :)

Ostracus

Quote from: carl on January 26, 2013, 01:44:19 PM

Obi really spent some effort to make it really difficult for us, in spite of all the pleas.

The problem isn't that the Obi's contain concepts and ideas we all couldn't understand (eventually). It's both lack of information in general, or concepts poorly spelled out.

mrjoe

#14
You may find my previous setup interesting.

http://www.obitalk.com/forum/index.php?topic=4036.msg28744#msg28744

By the way Congratulations ianobi on reaching your 500th post and becoming a 'Hero Member'

ianobi

mrjoe,

Thanks! Your digit maps have always provided some interesting challenges, which we can all learn from. Only another 4000 posts to go to catch up with RonR  :D

azrobert

#16
I always thought the Trunk Group was used to select an alternate trunk when a trunk can't handle the call, therefore I never looked at them.

This is a very clever way of using trunk groups.

But, I don't understand how mrjoe's configuration works.

mrjoe's config:
QuoteTrunk1:
TrunkList: vg6,vg4,vg7,li1,vg3,vg8,sp1,sp2,vg1
DigitMap: ((Mvg6)|(Mvg4)|(Mvg7)|(Mli)|(Mvg3)|(Mvg8)|(Msp1)|(Msp2)|(Mvg1))

Digit Maps:
(UK SP)-Mvg4: (<0191>4xxxxxx|<0161>7xxxxxx|0[13]xxxxxxxxx|02[1-9]xxxxxxxx|07xxxxxxxxx)


I'm assuming Phone primary line = Trunk Group1 and 4xxxxxx is dialed.

The Phone DigitMap's Mpli points to the Trunk Group1's DigitMap which contains Mvg4 and rule <0191>4xxxxxx validates the number.  The number is changed to 01914xxxxxx.

The phone OutboundCallRoute points to Trunk Group1 which contains vg4, but Mvg4's rule <0191>4xxxxxx does not match because the number was already changed to 01914xxxxxx and the call fails.

I obviously don't understand Trunk groups, mrjoe would know if his config worked or not.  Could someone explain where I'm going wrong.

mrjoe

Hi Azrobert,

The Trunk Group acts as one big rule that goes trough the dial plan of each Trunk from left to right.  The Mvg/Msp is just a reference (like User Digit Maps)

It is just like a regular dial plan, the only difference is each reference also contains routing information.

If you read the rest of the post you will see why I resorted to this particular way of routing rather than using <**2>xxxx etc.

mrjoe

QuoteI always thought the Trunk Group was used to select an alternate trunk when a trunk can't handle the call, therefore I never looked at them.

In my case the trunk cannot handle the call as it is not contained in its own dial plan.  So it goes to the next trunks dial plan and so on....


What I found out that can help people the most is that there is really no need to you S2/S4 for shorter number that match.

All you do is put the longer numbers first!

For example if you have (xxxxxxx|xxxx) or (1234567|1234) if you dial 1234 the Obi will skip the reference to the  first series of digits and put the call through immediately.

The usual way is to put (1234S4|1234567) this would delay the system for 4 seconds to allow it to check if anymore digits are dialed.

azrobert

mrjoe,

Thanks for the Trunk Group explanation. I'm still not sure I totally understand them. I just have to define a Trunk Group and play with it to see how it functions.

Also, thank you for the digit timer tip.  I've already changed my configuration.