Solved: PAP2 -> Obi110 dial plan
ianobi:
mrjoe,
I decided to have one more look at this after looking at a similar problem for my own set up. I think RonR’s original post was intending for the ** codes to be used from the pap2.
This is your SP1> X_InboundCallRoute, modified to allow dialling without ** codes:
{9725xxxxxxxx:aa},{(9725xxxxxxxx):aa(**688351000xxxxxx)},{pap2>(Mtg1):tg1},{pap2>([1-9]x?*@@.):pp},{pap2>(<#:>|1xx):li},{pap2>**0:aa},{pap2>***:aa2},{pap2>(Msp1):sp1},{pap2>(Msp2):sp2},{pap2>(Mvg3):vg3},{pap2>(Mvg4):vg4},{pap2>(Mvg6):vg6},{pap2>(Mvg7):vg7},{pap2>(<**9:>(Mpp)):pp},{pap2>0:ph},{pap2:},{ph,vg5(pap2)}
I have left in **9 as Mpp matches any nine digit number and may cause conflicts. This relies on there being no conflicts between digit maps. I removed Mli as it is already there within Mtg1.
I would copy and save your original plan, maybe put it in a word doc. Copy and paste this plan to try it. Easy then to get back to the original.
Of course, by now you may have gone a completely different route :)
mrjoe:
Hi Ianobi,
I really appreciate your attempts at solving this issue.
The new digit map did not achieve the desired results however.
I’ve officially given up on trying to find a solution.
I think it must be it is a lower level digit map that cannot evoke a SP change on its own.
I now have another problem.
I’ll open a new Post :)
mrjoe:
Finally figured this one out with something I read about trunks.
A trunk will also check each dial plan and when it finds a match it will use that particular VG/SP.
So I broke up my Line dial plan, took the * prefixes out and put the remaining digits in each VG/SP that I wanted it to dial through.
Then I changed Trunk1's digit map to include all of the VGs that I wanted to use.
Everything now works perfectly.
COTs cannot have **Xs prepended automatically but they can have the Trunk do the work for them!
I'll post a few examples when I get home.
mrjoe:
Just saw this RonR Post:
http://www.obitalk.com/forum/index.php?topic=3094.msg20656#msg20656
Quote
The InboundCallRoute rules generated by the OBiTALK Web Portal for Circle of Trust have some limitations and shortcomings:
1. When single-stage dialing is used, the called number is not processed though the OBi's PrimaryLine DigitMap. As a result, no validation is done and expected transformations do not occur. The rules should instead be:
Voice Services -> OBiTALK Service -> InboundCallRoute:
{(290123456|200123456|300123456)>(Mpli):pli},{(290123456|200123456|300123456):aa},{ph}
where pli is the OBi's PrimaryLine name (sp1, sp2, or li).
2. Single-stage dialing is limited to using the OBi's PrimaryLine. Service Route Access Codes (**1, **2, etc.) are not supported.
These limitations and shortcomings do not exist if the configuration described in Single-Stage Dialing Through Any OBi Trunk is used instead of Circle of Trust.
mrjoe:
Here is an example of my Setup now:
Trunk Group 1
li1,sp2,vg1,vg4,vg7,vg6,vg8,sp1
DigitMap
((Mli)|(Msp2)|(Mvg1)|(Mvg4)|(Mvg7)|(Mvg6)|(Mvg8)|(Msp1))
Voice Gateway 4
(01xxxxxxxxx|<0191>4[2-9]xxxxx|02[34]xxxxxxxxx|028[2346-9]xxxxxxx|0292xxxxxxx|03[0347]xxxxxxxx|07xxxxxxxxx)
Voice Gateway 5
(<0:972>[3-9]x.|<0:972>2[1-9]x.|9<0:72>[2-489]xxxxxxx|9<0:72>[57]xxxxxxxx)
None of the Digit Maps can have xx. In them except the last one.
So if you don't have a detailed dial plan and usually dial a **x prefix and end your number with # this won't fork for you.
Navigation
[0] Message Index
[#] Next page
[*] Previous page