dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
6433
share rss forum feed

RonR

join:2003-10-10
Ash Flat, AR
kudos:6

3 recommendations

Dial Plan Generator for OBi100/110/202

ObiCfg.exe is a Windows program intended to create dial plans for the
OBi100, OBi110, and OBi202 using North American Number Plan (NANP)
rules. Once the desired options have been selected, File -> Save will create
a text file (OBiCfg.txt) containing the necessary configuration settings to
accomplish the requested dialing behavior.

The main window consists of a Phone(s) panel (upper) and a Service
Provider(s) panel (lower). Various options for each applicable Phone may
be selected from the Phone(s) panel, including:

1. Available trunk(s)
2. Primary line trunk
3. 911 trunk and optional redirect number
4. 411 trunk and optional redirect number
5. Auto Attendant support (**0)
6. Configuration support (***)
7. Ad Hoc Gateway support (n*ddddddddddd)
8. Speed Dial support
9. Redirection of international calls to a particular trunk
10. Redirection of 11-digit calls to a particular trunk
11. Redirection of 10-digit calls to a particular trunk
12. Redirection of 7-digit calls to a particular trunk
13. Redirection of toll free calls to a particular trunk
14. Redirection of iNum call to a particular trunk
15. Redirection of SIP URI calls to a particular trunk

Various options for each applicable Service Provider may be selected from
the Service Provider(s) panel, including:

1. Service codes (x11) support
2. User dialing rules support
3. 11-digit dialing support
4. 10-digit dialing support (with option to add '1')
5. 7-digit dialing support (with option to add area code and '1')
6. International (00/011) dialing support
7. iNum dialing support (8835100xxxxxxxx)
8. SIP URI dialing support (with option for IP dialing)
9. Direct access to the LINE port support (#)

Notes:

Changing the 'Device' setting resets all options to default values. Default
values for the currently selected device may be reset by selecting Edit ->
Defaults.

The Service Provider selected as the 'Primary Line' may not be disabled.

The 911/411 'Redirect To:' number must be a valid phone number.

The seven 'Redirect ... Calls To:' options pertain to numbers dialed without
a service route access code (**n). The target trunk and Primary Line trunk
must both support the applicable dialing format. Any transformations (7-
Digit Dialing Add Area Code, 7-Digit Dialing Add '1', and Ten Digit Dialing
Add '1') specifed by the target trunk will be performed.

User rules must be separated by a '|'. No validation is performed.

The 7-digit dialing 'Add Area Code' number must be a valid area code.

A 'Warnings' list is output at that bottom of the OBiCfg.txt file for any
option requests that could not be performed.

Nothing is installed and no modifications are made to Windows by running
OBiCfg.exe. It simply writes out a text file when File -> Save is selected.


Trev
IP Telephony Addict
Premium
join:2009-06-29
Victoria, BC
kudos:6
This seems like a great utility given the frequency of posts asking for help with their OBi dial plan.

I have just a couple questions:
- did you create this?
- any reason for distributing an executable rather than a link to a web app?
--
I represent AcroVoice, a full service Canadian VoIP Provider.
Buy your Obihai ATA shipped from within Canada.

RonR

join:2003-10-10
Ash Flat, AR
kudos:6
said by Trev:

did you create this?

Yes
said by Trev:

any reason for distributing an executable rather than a link to a web app?

It was written as a free-standing Windows application and not as a web app.

OZO
Premium
join:2003-01-17
kudos:2
reply to RonR
Thank you, RonR See Profile. It looks interesting.

I just made the first file. Are those rules (for iNum) somehow different:
<8835100>xxxxxxxx
8835100xxxxxxxx
 
or the first one would be enough?

--
Keep it simple, it'll become complex by itself...

RonR

join:2003-10-10
Ash Flat, AR
kudos:6
said by OZO:

Are those rules (for iNum) somehow different:

<8835100>xxxxxxxx
8835100xxxxxxxx
 
or the first one would be enough?

The second rule accepts a 15-digit number that starts with 8835100. This rule can be used by itself.

The first rule accepts an 8-digit number and prepends 8835100 to it. If this rule is used, the second rule must also be present.

OZO
Premium
join:2003-01-17
kudos:2
Thank you.

So, there is no such thing as an optional sequence of digits and <8835100> means it should not be there at match time, but will be added after that.
--
Keep it simple, it'll become complex by itself...

RonR

join:2003-10-10
Ash Flat, AR
kudos:6

1 recommendation

said by OZO:

So, there is no such thing as an optional sequence of digits and <8835100> means it should not be there at match time, but will be added after that.

(8835100)?xxxxxxxx would mean that 8835100 is optional (0 or 1 occurrences of it), but if you don't enter 8835100, it wouldn't be added for you (the number would remain as xxxxxxxx, which isn't an iNum number).

<8835100>xxxxxxxx does add 8835100 to an 8-digit number, making it into an iNum number. This happens during the DigitMap processing phase in the OBi. The resulting number (8835100xxxxxxxx) is then subjected to the OutboundCallRoute processing phase in the OBi (which uses the same DigitMap), so there must also be an 8835100xxxxxxxx present to match the expanded version.

DaveSin

join:2009-07-17
Great job RonR!! On the OBi110, any reason why VG1, VG2 and VG8 is omitted?

Any plans to rejoin the OBiTalk Forum? You were a great help to me (and many others) in helping me set up our OBi ATA ~ 2 years ago.


WhyADuck
Premium
join:2003-03-05
kudos:1

1 edit
reply to RonR
This tool is great for its intended purpose, but for new users and those inexperienced in the ways of Obihai devices, I just want to point out that if your configuration needs are simple, you are almost always better off using the OBiTalk portal to do your configuration. Not only was that designed by Obihai as the primary way for users to configure their devices, but also if gives you the advantage of being able to reconfigure your device remotely should the need ever arise (such as if you're away from home, your preferred service provider goes belly up, and your spouse wants the phone to work again - if you are using the OBiTalk portal you could deal with that from anywhere in the world that you have an Internet connection).

Even if you do need to enter a more complex dial plan, that can still be done via the OBiTalk portal by using the "Expert Configuration" mode.

I do realize that for a very few people it's something akin to a religious belief to avoid the use of Obihai's user portal, and if someone holds that belief I'm not going to waste any energy trying to convince them otherwise. No one is forcing anyone to use it if they really don't want to; once you buy the device it's entirely your choice as to how you wish to configure it. I'm just posting this for the benefit of new users and those considering the purchase of an Obihai device, who may get the impression that you have to use a tool such as this to configure your dial plan. Unless you want to do something a little bit unusual, the OBiTalk portal probably has a built in configuration that will allow you to do what you want, and it will be easier to use than this tool.

And even if you DO want to do something unusual, this tool may not suffice. For example, it would not handle a dial plan I use, where 7 and 11 digit calls are routed to Google Voice, but most three digit calls (including all n11 calls, not just 911 and 411) are routed to a small Asterisk server (which nowadays can be run on a Raspberry Pi). However, just playing with it would demonstrate how various types of dial plans are constructed, so for that reason alone it's a valuable educational tool. Since I am a Mac user with no Windows box at present it wouldn't help me much personally (although if I really needed it I suspect I could run it using Wineskin Winery) but still it's great that something like this is available!

RonR

join:2003-10-10
Ash Flat, AR
kudos:6
reply to DaveSin
said by DaveSin:

On the OBi110, any reason why VG1, VG2 and VG8 is omitted?

I chose to limit service route access codes to **1/2/3/4/6/7/8/9 with the obvious associations. Allowing VG1/VG2/VG8 also would require going to something like **71, **72, and **73 for the additional VG's, which seemed like overkill with 8 trunks already supported.

RonR

join:2003-10-10
Ash Flat, AR
kudos:6

1 recommendation

reply to WhyADuck
said by WhyADuck:

And even if you DO want to do something unusual, this tool may not suffice. For example, it would not handle a dial plan I use, where 7 and 11 digit calls are routed to Google Voice, but most three digit calls (including all n11 calls, not just 911 and 411) are routed to a small Asterisk server (which nowadays can be run on a Raspberry Pi).

OBiCfg is intended to aid the vast majority of typical users with common everyday needs who don't have the desire or resources to master the OBi's dial plan philosophy and syntax. It attempts to generate the necessary settings to accomplish the most sought after tasks, which the user can copy/paste into the OBi directly or into the OBiTalk web portal, whichever he chooses. Anyone advancing to the level of supporting an Asterisk server probably needs to devote the time and effort to have a fuller understanding of the OBi's inner workings.

Having said that...

Assuming Google Voice is configured on SP1 as the Primary Line and Asterisk is configured on SP2, I believe simply entering <**2>xxx in the User Rules field of SP1 and xxx in the User Rules field of SP2 will cause OBiCfg to generate a configuration that does as you wish, routing 7- and 10-digit calls to Google Voice and 3-digit calls to Asterisk.


WhyADuck
Premium
join:2003-03-05
kudos:1
said by RonR:

OBiCfg is intended to aid the vast majority of typical users with common everyday needs who don't have the desire or resources to master the OBi's dial plan philosophy and syntax.

Huh?!? That is exactly the type of user that could most directly benefit by sticking with the OBiTalk portal, unless you have a rather broad definition of "typical user."

To me, a "typical user" is one that buys an Obihai device with the intent of using it with Google Voice, and/or or one or more of the several service providers directly supported by the OBiTalk portal. In such a case, they basically need to say which provider they are using, fill in a bit of account information associated with the provider and make some simple choices, such as whether they want to enable 7 digit dialing, and if so, what should be the "default" area code. In such a scenario they never need to touch the actual dial plan settings; it's all configured for them, automatically and with little effort.

Where your tool would come in handy is when they want to do something that's not exactly typical, at least for the most common type of purchaser. If we're talking only about participants of this forum, however, then all bets are off. I suspect that the typical reader of this forum is somewhat more advanced than the typical Obihai purchaser, such as the person who buys an Obihai from Amazon or Newegg or a similar retailer, just to get a line or two of phone service in their home or office.

Let's just clarify the distinction between the Obihai devices and some previous devices such as those sold by Cisco, Linksys, Sipura, etc. With those older devices, you absolutely had to configure a dial plan manually. With the Obihai devices, many users can skip that step and just use the OBiTalk portal to set up their devices and be done with it. However, for those that need something more advanced than the dial plan provided by the portal, your tool is a valuable contribution.

QBZappy

join:2012-05-10
reply to RonR
Hey Ron,

Very interesting tool. Thanks.

I've mentioned in the past that your were generous, now I can also say that you are generous to a fault. It looks like DSL got the scoop on this.

Wish I had thought of this!

OZO
Premium
join:2003-01-17
kudos:2
reply to WhyADuck
1. OBiHAI web portal configuration is not compatible with configuration via direct connection to OBi device. One has to choose either one or another, but not both. The later is used to configure OBi to its full potential. And that's one of the reasons, why I'd recommend users to use direct configuration of OBi devices and not OBiHAI web portal. There are others, but I'd prefer to stop here.

2. OBiCfg is a nice tool to make configuration, using advanced features of OBi device. One can explore OBi's features by playing with this tool and I appreciate that. So, WhyADuck See Profile, what's your point? You don't like it? Don't use it... Just simple like that.
--
Keep it simple, it'll become complex by itself...

OZO
Premium
join:2003-01-17
kudos:2
reply to RonR
This tool allows to set digit maps, located in different places. And there are many DigitMap's in OBi's configuration. For example:
1. ITSP Profile X | General contains DigitMap
2. User Settings | User Defined Digit Maps contains multiple DigitMap records
3. Voice Services | Gateways and Trunk Groups, each contains its own DigitMap
4. Physical Interfaces | PHONE Port contains DigitMap
5. Physical Interfaces | PHONE Port contains OutboundCallRoute

And because they play role not only filters to match, but can also modify (add, remove, modify) digits in dialed number, it's important to know the order they come in to play when user dials digits on his phone.

You've mentioned two different processing phases. Are there more and what's the order of processing those DigitMap's in general?

What if one DigitMap refers to another one? For example, DigitMap for ITSP Profile X may contain: ((Mdp)|(Mvms)), where dp and vms are user defined digit maps. And then they can be used in OutboundCallRoute... How they are actually being processed?
--
Keep it simple, it'll become complex by itself...

RonR

join:2003-10-10
Ash Flat, AR
kudos:6

2 recommendations

For a more detailed explanation, you should consult the "OBi Device Administration Guide" starting at page 174 "OBi Call Routing and Digit Map".

In a nutshell...

Technically, the only Digit Map accessed by an OBi when a number is being dialed is the Phone Port DigitMap. Many other Digit Maps typically get accessed also, but that's only due to indirect references to them from the Phone Port DigitMap. In reality, while a number is being dialed and evaluated during phase one, there's effectively one huge Digit Map consisting of the Phone Port DigitMap and all the other Digit Maps referenced indirectly from there. If a Digit Map is not referenced by the Phone Port DigitMap or one of its subordinates, it won't be used during phase one.

The order of rules in Digit Maps is typically not critical. As each digit is entered, the Phone Port DigitMap (and all its subordinates referenced from there) is evaluated looking for a match on the digits accumulated so far. Once a match is found and there can be no further matches, processing of phase one is complete and the dialed number to be processed by phase two is known. The number actually dialed may have been transformed in the process by the matching rule (for example, an area code and/or a '1' may have been added).

Phase two takes the number resulting from phase one and applies it to the Phone Port OutboundCallRoute, one rule at a time. The first rule that matches wins and the call is routed to the trunk or endpoint specified in the matching rule. Each OutboundCallRoute rule typically refers to an individual Digit Map or an explicit value to be matched.


Gershom 1624

@optonline.net
reply to RonR
Thanks [very much] for developing this tool, and for all of the explanatory material.

It is nice that people will have multiple options to program the Obi device.


cb14

join:2013-02-04
Miami Beach, FL
+ 1

OldCoalMiner

join:2004-05-20

1 edit
reply to RonR
Interesting. Thanks for this.

Edit to add: Are you taking additional feature requests? Because there's something I've never figured out how to do on an Obi110 dial plan, but yet is seems simple enough. And have never seen a clear solution on the Obi forums.

Dan_voip

join:2007-01-03
Saint-Hubert, QC
kudos:4
reply to cb14
Nice tool, not sure if I got it right though.
I would like to have NA 10&11 digits and toll free routed to SP1 and I've selected 10 and 11 digits on SP1 tab, that should cover toll free also.
On SP2 I have only user rules selected: 03[3-6]X56XXXX|02156XXXXX and those numbers need to be routed to SP2.
On VG3 I have only a user rule selected: 0[237]xxxxxxxx hoping all numbers not matching the rule on SP2 and matching this rule will be routed to VG3.
From what I see in the file generated I'm not sure SP2 and VG3 will route the desired numbers.

OZO
Premium
join:2003-01-17
kudos:2
reply to RonR
Thank you, RonR See Profile!

RonR

join:2003-10-10
Ash Flat, AR
kudos:6
reply to OldCoalMiner
said by OldCoalMiner:

Are you taking additional feature requests?

I'm willing to listen and consider them.

Mango
What router are you using?
Premium
join:2008-12-25
www.toao.net
kudos:13
Reviews:
·AcroVoice
·Callcentric
·Anveo
reply to OldCoalMiner
said by OldCoalMiner:

there's something I've never figured out how to do on an Obi110 dial plan, but yet is seems simple enough. And have never seen a clear solution on the Obi forums.

Don't keep us in suspense.

RonR

join:2003-10-10
Ash Flat, AR
kudos:6
reply to Dan_voip
said by Dan_voip:

I would like to have NA 10&11 digits and toll free routed to SP1 and I've selected 10 and 11 digits on SP1 tab, that should cover toll free also.
On SP2 I have only user rules selected: 03[3-6]X56XXXX|02156XXXXX and those numbers need to be routed to SP2.
On VG3 I have only a user rule selected: 0[237]xxxxxxxx hoping all numbers not matching the rule on SP2 and matching this rule will be routed to VG3.
From what I see in the file generated I'm not sure SP2 and VG3 will route the desired numbers.

Assuming that SP1 is the Primary Line and that SP2 and VG3 work as desired when you dial their applicable numbers using service route access codes **2 and **3 respectively, you need to add the following User Rules to SP1 in order to have the SP2/VG3 numbers redirected automatically:

<**2>(03[3-6]x56xxxx|02156xxxxx)|<**3>0[237]xxxxxxxx

Ostracus

join:2011-09-05
Henderson, KY
reply to RonR
Dealing with ObiPLUS?

hwittenb

join:2003-12-20
Reviews:
·Future Nine Corp..
reply to RonR
RonR
Thanks for explaining this stuff ....

When does the DigitMap associated with the ITSP Profile get referenced? I've see where people are recommending that some dialing changes/additions/transpositions be made there

You can setup dialing rules in an InboundCallRoute to further bridge an inbound call to an outbound call. Does a call setup there in the InboundCallRoute then also go thru the ITSP Profile DigitMap and then where does it go? Is there any way to direct an inbound call that will be bridged to an outbound call to have different outbound routing based on the number dialed?

RonR

join:2003-10-10
Ash Flat, AR
kudos:6
said by hwittenb:

When does the DigitMap associated with the ITSP Profile get referenced?

Each SPn Service has an X_ServProvProfile setting. If X_ServProvProfile is set to 'A', then that SPn Service uses ITSP Profile A. If X_ServProvProfile is set to 'B', then that SPn Service uses ITSP Profile B. Normally the SP1 X_ServProvProfile is set to 'A' causing (Msp1) to refer to the DigitMap in ITSP Profile A, while the SP2 X_ServProvProfile is set to 'B' causing (Msp2) to refer to the DigitMap in ITSP Profile B. If both SP1 and SP2 use Google Voice accounts, both X_ServProvProfile settings could be set to 'A' causing ITSP Profile A to be used for both SP1 and SP2. In this case, both (Msp1) and (Msp2) would refer to the DigitMap in ITSP Profile A.

said by hwittenb:

You can setup dialing rules in an InboundCallRoute to further bridge an inbound call to an outbound call. Does a call setup there in the InboundCallRoute then also go thru the ITSP Profile DigitMap and then where does it go? Is there any way to direct an inbound call that will be bridged to an outbound call to have different outbound routing based on the number dialed?

InboundCallRoute rules simply bridge an incoming call to the trunk or endpoint specified in the rule that matches. The only DigitMap used is the one specified in the rule (if one is present). InboundCallRoute rules are processed sequentially, stopping on the first rule that matches. For example, {17145551212:sp2(18005551212)} would bridge an incoming call from 17145551212 to an outgoing call to 18005551212 using SP2. {(Mcot):aa} would bridge an incoming call from anyone matching the User Defined DigitMap 'cot' to the Auto Attendant. If the 'cot' DigitMap is (1323xxxxxxx|1213xxxxxxx|1818xxxxxxx), then callers from the 323, 213, and 818 area codes would be bridged to the Auto Attendant.

Selective routing can be accomplished using a series of rules. For example:

{(12135551212|17145551212):sp2(18005551212)},{13035551212:sp1(18185551212)},{ph}

would route calls from 12135551212 or 17145551212 to 18005551212 using SP2 while calls from 13035551212 would be routed to 18185551212 using SP1. Any other caller would be routed to the Phone Port.


WhyADuck
Premium
join:2003-03-05
kudos:1

2 edits
reply to OZO
said by OZO:

1. OBiHAI web portal configuration is not compatible with configuration via direct connection to OBi device. One has to choose either one or another, but not both.

That's correct.

said by OZO:

The later is used to configure OBi to its full potential. And that's one of the reasons, why I'd recommend users to use direct configuration of OBi devices and not OBiHAI web portal. There are others, but I'd prefer to stop here.

Now you are crossing the line from fact to opinion. For some users, including many readers of DSLReports, that may be a good recommendation. For others, especially new users and those who want the most trouble-free experience possible without doing manual configuration, that may not be such a great recommendation.

In a way this is like recommendations on operating systems. One person may recommend Windows, another OS X, another some distro of Linux, and so on. Each person making a recommendation may feel they are right, but what is right for them may not be right for everyone. In this case there are valid reasons for doing it both ways, but in my opinion it boils down to, do you want maximum control or maximum simplicity? If you opt for maximum control you might opt to do manual configuration. If you want maximum simplicity, you'll probably want to use the OBiTalk portal. A lot of users have no desire to manually configure a dial plan, or anything else on their devices, if they don't have to.

said by OZO:

2. OBiCfg is a nice tool to make configuration, using advanced features of OBi device. One can explore OBi's features by playing with this tool and I appreciate that. So, WhyADuck See Profile, what's your point? You don't like it? Don't use it... Just simple like that.

I didn't say I don't like it; in fact if it ran under OS X I'd probably have been playing with it a bit, because it looks interesting. I only said that as written it would not have helped me with the specific configuration I needed, but that's neither here nor there because I already figured out how to do what I needed a long time ago. My point is that a) if your configuration needs are simple you may not need to do anything to the device's dial plan at all, because the OBiTalk portal can take care of that for you, and b) whether you use this tool or not, you have the option of using or not using the OBiTalk portal for configuration. You don't need to give up the capability to remotely reconfigure your device or use the simple configuration options of the portal just because you want to play with the dial plan - you can always do that through the portal's expert configuration mode. Or not, if you feel you have reasons not to.

You have some issue with telling users and potential users about all their options, or making clear what's fact and what's opinion or personal choice? Anyway thanks to RonR for making this available. I'm sure it will help those people who do wish to futz with their dial plans.

Stewart

join:2005-07-13
kudos:26
reply to hwittenb
said by hwittenb:

Is there any way to direct an inbound call that will be bridged to an outbound call to have different outbound routing based on the number dialed?

Yes, but it depends on your provider(s) and their settings.

If you have e.g. a DID from Anveo on SP1 and one from Future-Nine on SP2, you would simply set X_InboundCallRoute differently for SP1 and SP2.

If you have two DIDs from Anveo on an OBi202 SP1, one business and one personal, and you want the business number to ring PH1 and the personal number to ring PH2, you could set SP1 X_InboundCallRoute to
{>121255510000:ph1},{>12125551234:ph2},{ph1,ph2}
You could of course use external destinations instead of, or in addition to, ph1 and ph2. For this to work, the provider must send the DID number in the SIP URI.

If calls to the OBi come directly from a source that can send an arbitrary number (IP phone, another ATA, PBX, etc.), then on an OBi110, you might use something like
{>1(212|646)xxxxxxx:li},{>1xxxxxxxxxx:sp1},{sp2}
which would send calls to the 212 and 646 areas via the Line port, other North America calls via SP1, and all other calls via SP2.

OldCoalMiner

join:2004-05-20
reply to RonR
I was thinking a check box for second dialtone with **x, for when an SPx is not directly associated to PHx. That seemed hard to figure out when I first started using an Obi, it's buried deep away in the documentation.

I have one more that will add/describe when more time allows.