Solved: PAP2 -> Obi110 dial plan

[mrjoe]

I'm currently using tg1 as my default line.
it includes: li1,vg3
dial plan: (Mli)

I have AA setup to dial exactly as if I would be dialling from the Phone port, like this:

DigitMap:
([1-9]x?*@@.|[1-9]|[1-9][0-9]|<00:$1>|0|**1{t=di}(Msp1)|**2{t=di}(Msp2)|**3{t=di}(Mvg3)|**4{t=di}(Mvg4)|**6{t=di}(Mvg6)|**7{t=di}(Mvg7)|**0{t=di}(Mvg8)|**8{t=di}(Mli)|**9{t=di}(Mpp)|(Mpli))

OutboundCallRoute:
{([1-9]x?*@@.):pp},{0:ph},{(<#:>):li},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Mvg3)):vg3},{(<**4:>(Mvg4)):vg4},{(<**6:>(Mvg6)):vg6},{(<**7:>(Mvg7)):vg7},{(<**0:>(Mvg)):vg8},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):tg1}

Everything works perfectly.

I would like to be able to dial like that when calling through the Obi110 using a PAP2, at the moment however, I can't call without dialing a **x prefix.

SP1> X_InboundCallRoute:
{9725xxxxxxxx:aa},{(9725xxxxxxxx):aa(**688351000xxxxxx)},{pap2>(Mli):tg1},{pap2>([1-9]x?*@@.):pp},{pap2>(<#:>|1xx):li},{pap2>**0:aa},{pap2>***:aa2},{pap2>(<**1:>(Msp1)):sp1},{pap2>(<**2:>(Msp2)):sp2},{pap2>(<**3:>(Mvg3)):vg3},{pap2>(<**4:>(Mvg4)):vg4},{pap2>(<**6:>(Mvg6)):vg6},{pap2>(<**7:>(Mvg7)):vg7},{pap2>(<**8:>(Mli)):li},{pap2>(<**9:>(Mpp)):pp},{pap2>0:ph},{pap2:},{ph,vg5(pap2)}

What can I change in the above Call Route to achieve that?

Thanks

[mrjoe]

This setup seems to be working now!? 
Only for calls which use the default line.
It will failover to vg3 when the Cellphone is not connected.

I think this setup of calls being initiated from the inbound Call Route of SP1 may be coming at too late a stage to recognise **x for choosing a line.

Anyone have any more information on this?

[ianobi]

mrjoe,

Your setup is working as it should.

Calls going to tg1 will not need any ** codes because it is your Primary Line.

The only way to achieve what you want is to arrange other codes to be diverted in your Primary Line Digit Map, in this case tg1.

For example, if you included this rule in tg1 Digit Map <**1>(Msp1) numbers matching Msp1 would have **1 prepended to them and be sent out of sp1 by the OutBoundCallRoute.

To make this work you need to include this at the beginning of the sp1 InBoundCallRoute:
{pap2>(Mtg1):tg1} This could replace {pap2>(Mli):tg1} as Mli exists within Mtg1.

You might try the above as an example for Msp1. To do this for all codes coming from your pap2 would make the tg1 digit map very complicated!

[mrjoe]

Thanks for that,
I'll give it a try.
Would copying and pasting Mli's content work?

What I don't understand is:
Why is putting (Mli) in tg1's Digitmap not the same as copying all the information from Mli and putting it there.

I thought using shortcuts like that allowed you to 'Host' a dial plan somewhere else while having the same effects.

[mrjoe]

Hi ianobi thanks for all your help,
I tried doing what you said.

I put Line's Digit Map (and changed it to (xx.)) into tg1 changed SP1 inbound to Mtg1 etc.
Nothing has changed though.

Do you think I have something when I say that maybe Obitalk/SP1's Inboundcallroute is too low in the Hierarchy to deal with **x of the digitmap it is sent to?

AA is using {(Mpli):tg1} and it is working fine.

I'll remind you of what the Digit Plan consists of:

(2<#>S0|3S0|<972:0>[23489]xxxxxxx|<972:0>[7]xxxxxxxx|02[3-9]xxxxxx<#>|<02>[5-9]xxxxxx<#>|0[49]xxxxxxx<#>|03[125689]xxxxxx<#>|0[5][0-57-9]xxxxxxx<#>|07[23]xxxxxxx<#>|07[4-8]xxxxxxx<#>S2|08[135689]xxxxxx<#>|087[4-9]xxxxx<#>|084[126-90]xxxxx<#>|1[2578]xxxxxxxx<#>S2|*xxxx<#>S2|*xxxxx<#>|1xx<#>S2|1xxx<#>|12[12]2xxxx<#>|1255xxx<#>|00(46|34|351|48|31|39|36|30|49|33|32|43|852|86|65|90|27|41|64|353|352|613|39|54|868)xx.<#>|<**3>00xx.|<**2>1xxxxxxxxxx|<00:**2>1xxxxxxxxxx|0044[123]xxxxxxxxx<#>|0<044>1xxxxxxxxx<#>|<0044191>4xxxxxx<#>|0<044>20xxxxxxxx<#>|0<044>2[34]xxxxxxxxx<#>|0<044>28[2346-9]xxxxxxx<#>|0<044>292xxxxxxx<#>|0<044>3[0347]xxxxxxxx<#>|<0:**344>7xxxxxxxxx|<**7>0(500|800|808)xxxxxxS2|<**7>0(500|800|808|870)xxxxxxx|<**6>084[345]xxxxxxx|<**6>087[123]xxxxxxx)

[mrjoe]

I'm thinking now maybe if I integrate the Dial Plan into the inboundcallroute of SP1 it might work but that would mean hours of painstaking work! 

[ianobi]

Take a step back!

When I said "This could replace {pap2>(Mli):tg1} as Mli exists within Mtg1." I was meaning to say Mli is already part of the tg1 digit map, you do not need to put it in there again.

For my example to work you only need to do two things:

1. Change your tg1 digit map to ((Mli)|<**1>(Msp1))

2. To make this work you need to include this at the beginning of the sp1 InBoundCallRoute:
{pap2>(Mtg1):tg1} This could replace {pap2>(Mli):tg1} as Mli exists within Mtg1.

No need to type any long digit maps into anywhere.

I have no way to test these changes, so you are chief test pilot on this one 

[mrjoe]

Hi ianobi,

Please could you explain to me the theory behind those adjustments?

The Obi got even more upset than it has been lately  and went in to a Reboot Loop, in between, I tried it and it did not seem to help.

What I think you were trying to do is get tg1 to replace numbers without **x in front with **1?

[mrjoe]

Hi ianobi,

I read your previous post again and understand the theory.

What does this mean though?

For example, if you included this rule in tg1 Digit Map <**1>(Msp1) numbers matching Msp1 would have **1 prepended to them and be sent out of sp1 by the OutBoundCallRoute.

which numbers would be matching Msp1

thanks again

[ianobi]

Before any changes you dial from your pap2 **1 and a number that fits the format for Msp1. The incoming SP1> X_InboundCallRoute removes the **1 and sends the number to sp1 using this rule {pap2>(<**1:>(Msp1)):sp1}

After the changes the aim is to dial a number that fits the format for Msp1 and let the tg1 digit map process that number using <**1>(Msp1) so it adds **1. Then the Phone Port OutBoundCallRoute will send it out via its rule {<**1:>(Msp1)):sp1}

We are at the limits of my ability here! Processing numbers through trunk routes is not an easy subject. I can only suggest experiment making one small change at a time.

[mrjoe]

Hi ianobi,
Thanks for that explanation.
I'll do some more exhaustive trials when I next get in the mood.

I'd really like an engineer from Obihai to join this post.

With the information I've learned in this Forum, I'm going to help some NPOs get the cheapest most sofisticated phone system running.

[ianobi]

mrjoe,

You have the hardest working OBi110 on this planet! It deals with incoming routes, mobile phones, pap2 .....

Obihai should be using you as an advertisment for what is possible 

I may have another think about this soon. Perhaps I can simulate your pap2 with a softphone.

Keep up the good work!

[mrjoe]

Thanks ianobi,
You do have a point there.

I just can't help thinking that whatever we're breaking our heads over can be accomplished with the greatest of ease with the Obi202.

I press 1# to switch lines, incoming calls ring both lines (without CLI for incoming Line calls on the PAP2), I can transfer calls from the Obi to the PAP2 (but not vice versa), outgoing calls can be made from both lines using the same routes etc.

I still think the Obi110 has the advantage though as POTS aren't going away for some reason.
Another advantage is often you get VoIP providers who will not reveal SIP settings and provide their own equipment that cannot be manipulated in any way.
It could be here the reason is because they are allowed to work as virtual Landline providers not VoIP.

[mrjoe]

Just wondering why is this not workinging in the SP1 inbound Callroute?

,{pap2>(0(500|800|808)xxxxxx):vg7}

[ianobi]

I think this is a format problem. pap2 is the callee, thats ok. After the > is the caller list. OBi expects to see each caller separated by a |. I think this would work:

,{pap2>(0500xxxxxx|0800xxxxxx|0808xxxxxx):vg7}

I note in your first post you had this rule:

,{pap2>(<**7:>(Mvg7)):vg7}

In this case the caller list is anything that agrees with Mvg7 and you remove **7 before sending the number to vg7.


Edit: Where are you experts?!! Someone should have spotted that I got callee and caller the wrong way round in this post 

[mrjoe]

Hi ianobi,
Tried that, no luck.

I think this is saying if a call comes through from the PAP2 that is prefixed with **7 (remove **7) use vg7's digit map and put the call through vg7.

{pap2>(<**7:>(Mvg7)):vg7}

I'm lost for digit maps!  

[ianobi]

Your last post is correct. We are saying the same thing in different ways. What is in Mvg7? Maybe there is a problem there.

[ianobi]

My attempt to prepend codes to incoming calls was wrong. Here is why:

Call originating from Phone Port or Auto Attendant: This is a two stage process. Stage one: The DMP (Digit Map Processor) compares the number with the rules in the Phone Port or Auto Attendant Digit Map, then executes the best matched rule. This may transform the number by say adding a code such as **1. Transforming is most often done using Mpli. Stage two: The DMP takes the number from stage one and compares it to the rules in the Phone Port or Auto Attendant OutBoundCallRoute. It looks at rules from left to right and executes the first rule that matches the number from stage one. The number may be further transformed here by say removing a code such as **1 before sending the number out on the appropriate trunk.

Call coming into Obi through X_InboundCallRoute: This is a one stage process. The DMP compares the incoming number with the rules in X_InboundCallRoute. It looks at rules from left to right and executes the first rule that matches the number. The number may be further transformed here by say removing a code such as **1 before sending the number out on the appropriate trunk. The DMP then stops, no further processing takes place.

In effect the X_InboundCallRoute acts the same as the Phone Port or Auto Attendant OutBoundCallRoute. If we wish to prepend codes to incoming numbers, then we must do it before they reach the Obi. In your case you do it in the pap2.

[mrjoe]

Thanks ianobi,
Where did you see that?

In all sincerity, that makes a mighty lot of sense.

It really should work that way.

The only problem is....

The PAP2's dial plan will not affect any calls going out in that way.  All it will do is block calls that do not match it for example if it says (xx.) it will stop **x from going through.
It seems to use Mli all the way.

[ianobi]

The Obi Admin Guide tries to explain it, but as usual it took RonR to give us a clear idea of how it all works.

I do not know how the pap2 dial plan works. The best way forward is to look at the OBi Call History to see in what format numbers are coming into the OBi from the pap2. Then the OBi will apply the rules in X_InboundCallRoute and Call History will show the result.

It looks like the pap2 and the OBi are doing exactly what they are supposed to do, but maybe not what you want them to do