S0, DigitMaps, and OutboundCallRoutes
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:
Quote from: MB.. on August 27, 2011, 10:45:32 am
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..:
Quote from: RonR on August 27, 2011, 11:13:13 am
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.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page