S0, DigitMaps, and OutboundCallRoutes

[MB..]

Could someone clarify for me the placement of the S0 option in a DigitMap?

I have both PSTN and SP1 set up to accept North American and international numbers, and the intention is to automatically route some calls via SP1 when they will be substantially cheaper than calling via PSTN. A user digit map Mvoip (itself defined in terms of other user defined digit maps) describes these cases.

As well as the North American pattern rules, the LINE digit map has a catch-all rule to accept any set of numbers.

1. Can S0 be placed as the last element of a rule in any digit map, including user defined maps?

2. Can it be placed in the OutboundRoutingMap (as in the two cases below), or is its use confined to the DigitMaps associated with LINE/SP1/SP2?

Code:

({(<#:>|[2-9]11S0):li},{**0:aa},{***:aa2},{(Mvoip)S0:sp1},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}

3. Also where is the best place to  put substitutions (such as 0<11:44>441..  which gives a lower cost routing on numbers starting 011441... )? Should they be in the OutboundCallRoute, in the DigitMap for a service provider?


Thanks for your help

[RonR]

In my opinion, it's generally a bad idea to start modifying the PHONE Port DigitMap and OutboundCallRoute.  Instead, you should make every effort to accomplish your goal(s) in the ITSPx and LINE Port DigitMap's.

S0 is a DigitMap modifier and should not be used in an OutboundCallRoute.

Assuming you have SP2/ITSPB configured as your VoIP provider, I would recommend you either put the rules you currently have in the voip USER Defined DigitMap in ITSPB -> DigitMap, or set  ITSPB -> DigitMap to (Mvoip).

The changes you've made to the OutboundCallroute are unlikely to give you the desired results.

Substitutions should also be done in the DigitMap appropriate to the trunk they are associated with (i.e. ITSPB -> DigitMap if SP2/ITSPB is your VoIP provider).

[MB..]

RonR, Thanks for your swift reply.

I don't have much option other than to modify the OutboundCallRoute / PHONE port DigitMap as one of the objectives is to make the phone behave like a POTS phone, but with least cost routing. (That way I can keep my wife happy!)

I'll try stripping the S0 out of the OutboundCallRoute (perhaps they were being ignored as it worked with them there).

[RonR]

I don't have much option other than to modify the OutboundCallRoute / PHONE port DigitMap as one of the objectives is to make the phone behave like a POTS phone, but with least cost routing. (That way I can keep my wife happy!)

I don't know why you say that.  The least cost routing can be accomplished in the ITSPx DigitMap with no modifications to the PHONE Port DigitMap and OutboundCallRoute.  Why do you think you can't accomplish the subsitutions you need in ITSPx?

[RonR]

If you'd like to give me the exact routing criteria you'd like to have followed between the PSTN and VoIP provider, I'll try to give you an example.

[MB..]

I'm trying to retain the option to force SP1 or LINE on any call.

The basic set up I am aiming for:

Overseas (011) and normal long distance (1) calls go via SP1
Local calls (area code 613), 1-800/877/866/855 calls go via LINE
311/411/811/911 (i.e. [2-9]11) calls go via LINE
*98 goes to LINE
*97, 4443, 4747, 068xxxx, *75xx , 10x go to SP1
# forces LINE, followed by any number
**1 forces SP1 (with secondary dial tone), followed by any valid SP1 number (as above)
***, **0 Auto Attendant, as in the default set up.
Any other combination of *xx. or xx. not mentioned above goes to LINE
SP2, ObiTalk currently unused.

And for good measure, 01144[12]xxxxxxxxx? gets rewritten to use an 04444 prefix when using SP1 (voip.ms) , to force voip.ms to use premium routing, which is cheaper than value routing in this case.

I think I've got it working (except for the 1-8XX numbers which I forgot about), but only with changes to the Phone port/ OutboundCallRoute.

The approach I've taken is to add (Msp) to the Phone DigitMap, and create a Mvoip DigitMap which defines what should be routed to SP1 rather than LINE. the Mvoip digit map is then included as a rule in the OutboundCallRoute: {(Mvoip):sp}


However, I'm, still new to the Obi devices so I'm not sure if I'm doing things the easy way or the hard way.

[RonR]

The only change to the PHONE Port DigitMap is the addition of a secondary dialtone when **1/**2/**8/**9 is dialed.  No changes are required to the PHONE Port OutboundCallRoute.


Physical Interfaces -> PHONE Port -> DigitMap:

([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|**1{t=di2}(Msp1)|**2{t=di2}(Msp2)|
**8{t=di2}(Mli)|**9{t=di2}(Mpp)|(Mpli))


Physical Interfaces -> PHONE Port -> PrimaryLine : SP1 Service


Physical Interfaces -> PHONE Port -> StarCodeProfile : None


Service Providers -> ITSP Profile A -> General -> DigitMap:

(*97|*75xx|10x|4443|4747|068xxxx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|
0<11:44>44[12]xxxxxxxxx?|04444[12]xxxxxxxxx?|011xx.|
<**8>*xx|<**8>[2-9]11|<**8>xxxxxxx|<**8>1?8(00|88|77|66|55)xxxxxxx|<**8>xx.)


Physical Interfaces -> LINE Port -> DigitMap:

(*xx|[2-9]11|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|xxxxxxx|xx.)


*97, *75xx, 10x, 4443, 4747, 068xxxx, 10/11-digits, 011+  ->  SP1 Service
                  *xx, [2-9]11, 7-digits, 10/11-digit toll-free, xx.  ->  LINE Port


The example above does not retain the option to force SP1 on any call.  If you insist on having that capability, I believe the following example will do so, but does require changing the (Mpli) rule to (Mdef) in the PHONE Port DigitMap.  No changes are required to the PHONE Port OutboundCallRoute.


Physical Interfaces -> PHONE Port -> DigitMap:

([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|**1{t=di2}(Msp1)|**2{t=di2}(Msp2)|
**8{t=di2}(Mli)|**9{t=di2}(Mpp)|(Mdef))


Physical Interfaces -> PHONE Port -> StarCodeProfile : None


Service Providers -> ITSP Profile A -> General -> DigitMap:

(*97|*75xx|10x|4443|4747|068xxxx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1613>xxxxxxx|
0<11:44>44[12]xxxxxxxxx?|04444[12]xxxxxxxxx?|011xx.)


Physical Interfaces -> LINE Port -> DigitMap:

(*xx|[2-9]11|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|xxxxxxx|xx.)


User Defined Digit Maps -> User Defined Digit MapX

Label: def

DigitMap:

(<**1>*97|<**1>*75xx|<**1>10x|<**1>4443|<**1>4747|<**1>068xxxx|
<**1>1xxxxxxxxxx|<**11>[2-9]xxxxxxxxx|
<**1>0<11:44>44[12]xxxxxxxxx?|<**1>04444[12]xxxxxxxxx?|<**1>011xx.|
<**8>*xx|<**8>[2-9]11|<**8>xxxxxxx|<**8>1?8(00|88|77|66|55)xxxxxxx|<**8>xx.)


*97, *75xx, 10x, 4443, 4747, 068xxxx, 10/11-digits, 011+  ->  SP1 Service
                  *xx, [2-9]11, 7-digits, 10/11-digit toll-free, xx.  ->  LINE Port

[MB..]

Thanks, RonR, for your detailed reply!

I'd never have thought of using <**8> inside the ITSP Profile A digit map to bounce selected calls back to the LINE interface. I'm quite surprised that works.

I'll give it a try.

[Wish there was better debugging aid for this. (Anyone from Obi lurking? An online simulator where you could set up a series of test cases and see what will get routed where would be a really useful debugging aid.]

[RonR]

Wish there was better debugging aid for this.

You can tell a lot about what's happening by viewing the Call Status and the Call History Log.

[MB..]

You can tell a lot about what's happening by viewing the Call Status and the Call History Log.

Only if the call is actually established: with DigitMap errors either an automated attendant message or dead air are common outcomes with no call history. (And I see from other posts that if you have an infinite loop you can lose the web interface too.)

[RonR]

Only if the call is actually established: with DigitMap errors either an automated attendant message or dead air are common outcomes with no call history.

But that's a lot of info too.   

(And I see from other posts that if you have an infinite loop you can lose the web interface too.)

There's virtually no error checking in the OBi, so syntax errors do unpredictable things.  Infinite loops are especially disastrous (although there might to be a watchdog that reboots the OBi, albeit repeatedly in the case of an infinite loop).