I typed this in response to a post by MichiganTelephone in the Feature Request sub-forum, and having typed it, realised it probably belonged more over here than over there. Given the evolving capabilities of the OBi110 (and OBi100, presumably), I thought this might be a useful discussion starter for people's approaches and thoughts on configuring the dialplans for these devices. Below I've outlined my current approach, which is working well for me, but I recognise that there are probably different philosophies and approaches that could be fruitfully compared and contrasted.
Quote from: MichiganTelephone on March 26, 2011, 07:40:45 PM
The problem is, it's written for programmers, not for users, or at least it seems that way. No offense intended to the guys at Obihai — at least they made the effort to document it, which is more than some other companies have done for their products.
I actually found the admin guide excellent -- one of the better written technical guides I've had the pleasure to read. Technical writers, please take a well-deserved bow.
I don't think you have to be a programmer to figure this stuff out, but I do think it helps to *think* like a programmer (at least in some ways).
The relationship between the various digitMaps and the OutboundCallRoute lists may be a bit opaque at first glance, but I think that once you get the hierarchy, it's quite straightforward, even easy.
The digitMaps are primarily gatekeepers, (or "cops", if you like), that will allow or disallow keystroke patterns (well, digit patterns more properly, I guess) as legal or illegal. They can also do some substitution (e.g., prepending a prefix or swallowing a prefix), but that's the secondary function.
The OutboundCallRoute lists do the real work of allocating the patterns to target ports (or trunks). They can also do substitutions like the digitMaps. So there is some overlap of functionality there, but the choice is not so much right/wrong, but rather, what is simpler to understand and easier to maintain.
The OutbboundCallRoute lists are the closest thing to the old dialplans we are used to thinking about in Linksys/Sipura devices. The idea of separating out the digitMaps from the dialplans seems to be motivated by modularity, and is probably a good thing, but I think until you get how they fit back together, it can potentially be a bit confusing.
In any case, the thing to remember is that for any given port (e.g., the PHONE port), nothing is going to happen until the digitMap for that port gives a key sequence the "OK". Once the key sequence clears the digitMap, it's the outboundCallRouting list's turn to process the key sequence, to determine where it should be directed.
That's pretty much a two step version of the way the system works in a Linksys/Sipura dialplan. So far so good. But the next thing that happens to the dialed sequence of digits is that it gets sent to a target port (say, the LINE port), which has it's own digitMap. So the dialled sequence has to get past this "cop", too.
This is where I suspect a lot of people are having problems getting their head around the interaction of the various digitMaps. But once you realise the order of the way things work, it really becomes straightforward, I think. Making the decision of where to put the gatekeepers is, once again, not so much "right" or "wrong", as simply a case of whatever is simplest and easiest to maintain for your application.
For my application, I found the user defined digitMaps simplified things greatly, because I specifically wanted fairly permissable gatekeeping at the outgoing port level (e.g., li, sp1, sp2), but strict gatekeeping at the incoming ports (ph and aa). So my digitMaps for each port outgoing port are minimal (xx.) type affair (let pretty much anything that ends up being directed to here through), whereas the digitMaps and OutboundCallRoute rules at the incoming ports are detailed and strict.
The detail of specifying things like "what constitutes vaild mobile (cell) phone number" and "what does a local number look like" I've placed in separate user defined digitMaps, so I can (readably) reuse them in various places, namely: a) The ph (PHONE port) digitMap, the ph (PHONE port) OutboundCallRoute list, the aa digitMap and OutboundCallRoute list.
Now, the reason I've decided not to tie these detailed digitMaps to specified outbound ports like SP1,SP2, or the LINE port, is because I potentially will direct *any* type of call to *any* of these ports, depending on what's currently in use and what available. So, I've got a preferred ITSP for my mobile (cell) calls, for example, registered on SP2. But what if I want to make a call and SP2 is not available? I can try either a) using the ITSP that is registered on SP1 (which may not have as good rates for this type of call), or b) by using a gateway configuration (say, gw1), I can try to use the SP1 port with the same ITSP as the one configured and registered on SP2 (which is even better!) But in any case, I want a permissive digitMap on SP1 so I can divert any type of call there if need be. Trunk groups make this all even easier to set-up.
However, not everyone may want, or need, to set things up to be this flexible. For example, a user might have just two ITSPs, they want to use, plus the PSTN line, and they know exactly what types of calls they want to divert and allow through those ITSPs. In this case, it might make sense to put the detailed digitMaps for each type of call in the config for each outgoing port SP1, SP2 and LINE, and not worry about the fancy stuff like user defined digit maps or trunk groups, or the AA.
In short, no one "right" way to set these things up -- and of several possible ways to do the same thing, the choice of which is preferable may be fairly subjective in terms of what is easier to understand and maintain for an individual user. As I said, I was far happier with the transparency and maintainability of my set-up once we got the user-defined digitMaps feature.
Well done, OBiHAI. I'm really enjoying this device, and the increasing power and sophistication of its configurability.
