Digitmap not working as expected for international and 900 blocking
ianobi:
ste makes sense as you want so many of the same rules for both service providers.
I see I made a mistake in my first post. It should read:
sp1: ((Mste)|<**2>00xx.|<**2>011xx.)
sp2: ((Mste)|<00:>xx.|<011:>xx.|xx.|(Mipd)|[^*#]@@.)
RajR:
Ianobi,
Your digitmaps is cleaner and works, however the 1900 numbers are still not getting barred from the Obi i.e. it still passes them to localphone which then rejects with 404. Here is the call history:
Terminal ID PHONE1 SP2
Peer Number **219002345678 19002345678
Direction Outbound Outbound
19:32:40 New Call
19:32:43 End Call (404 Not Found)
Would appreciate help on the barring feature.
Update on Issue#2: On the ability ability to selectively dial the 00/011 numbers from SP1, do you think this would work?
sp1: ((Mste)|<**2>00xx.|<**2>011xx.|<00:>00xx.|<011:>011xx.)
With the above digitmap, I expect that if I double-dial 00 or 011, then it should not prefix **2 and directly dial on SP1. Would that work or would it conflict with the earlier map?
Issue#3 Clarifying Question:- On the SP2 digitmap, does <00:>xx. only strictly match numbers dialled that start with 00 OR does it also optionally match any number that does not necessarily start with 00? Reason I ask is that for SP2 (localphone), I wanted to keep the option open of dialing the country code directly (without the 00/011) and that is the only reason I had kept the xx., however if the "<00:>xx." INCLUDES "xx." then I don't need to duplicate it. Would that work?
Thanks!
Raj
ianobi:
Issue #1:
I’m assuming that if you dial 19002345678, then you get fast busy. However, if you dial **219002345678, then the call goes out on sp2 as shown by your Call History. I’m having to make some educated guesses here! I guess that looking at the sp2 DigitMap:
sp2: ((Mste)|<00:>xx.|<011:>xx.|xx.|(Mipd)|[^*#]@@.)
The OBi Digit Map Processor may be processing the xx. and/or the [^*#]@@. rules before processing (Mste). This would allow 19002345678 through the DigitMap. It would be interesting to see the results for the following tests:
1. Remove xx.|(Mipd)|[^*#]@@. from the sp2 DigitMap. Dial **219002345678 and see what happens.
2. Change sp2 DigitMap to:
((Mste)|!1900xxxxxxx|<00:>xx.|<011:>xx.|xx.|(Mipd)|[^*#]@@.)
Dial **219002345678 and see what happens.
You may well be adding to our forum knowledge base here :)
Issue #2:
sp1: ((Mste)|<**2>00xx.|<**2>011xx.|<00:>00xx.|<011:>011xx.)
This will not work due to conflicts with the **2 rules and the fact that OBi processes the DigitMap twice – first in the Phone Port DigitMap, then in the Phone Port OutboundCallRoute. So <00:>00xx. would result in only xx. going to sp1.
You could try something very unusual:
sp1: ((Mste)|<**2>00xx.|<**2>011xx.|<RAJ>09xx.|<RAJ09:>xx.)
Prefix your codes with 09, so you dial 0900xx, 09011xx. Any number starting with 09 willl have RAJ prepended to it when it is processed through the Phone Port DigitMap. Then when that number is processed through the Phone Port OutboundCallRoute the RAJ09 will be removed and the rest of the number sent to sp1.
Issue #3:
On the SP2 digitmap, <00:>xx. does strictly match numbers dialled that start with 00
Interesting questions! We can all learn something here 8)
RajR:
Ianobi,
Thanks for your help. It was an interesting exercise and here are the results.
Force International Dialing on SP1 even though routed to SP2
I liked your idea of prefixing "RAJ" in the first stage and removing it from the second stage. It actually worked. To keep consistency with ** dialing, I improvised to force SP1 international dialing if dialled with **1 explicitly. The following digitmap worked for this purpose:
sp1: ((Mste)|<**2>00xx.|<**2>011xx.|<**2:>xx.)
With the above digitmap, the first stage ADDS **2 when dialing 011, however since the number was dialled explicitly with **1, the dialled digit show in the call history as being **1**2011xx. Therefore, it gets routed back to SP1 where the second stage processing REMOVES **2. Net effect:
011 dialing goes via SP2
**1011 goes via SP1 (force override for those times when it is needed)
**2011 dialing goes via SP2
Let me know if you can think of any unwanted side-effects!
900 Call Barring Issue
This one was quite tricky, but thanks again for pointing in the right direction. There are a couple of issues I found.
First, when barring using "!1900xx.", even though GV dialing gives fast busy, it is actually handing the call to GV which is resulting in the fast busy. This can be seen as the call history shows the 19002345678 being actually routed via Google Voice. In effect, barring with the digitmap above does NOT work even with GV.
Second, I changed the digitmap to bar "!1900xxxxxxxS0". I still put this in (Mste) instead of hard coding in the providers. This time when dialing 19002345678 using GV, it still gave fast busy, but there was NO CALL HISTORY. i.e. it was actually barring the call from reaching GV! This meant that the barring worked with specific pattern, but not with wildcards.
Third, I tried dialing **219002345678. This time, the call actually got routed to GV (SP1). This was surprising and not sure why the call got routed. I then removed the Mipd, xx. and the ^*# stuff, and then redialled and now the call failed with "No route found" and again, NO CALL HISTORY. So the xx. was interfering with the barring.
So finally, here are my digitmaps that work with barring.
User Defined ste: (!1900xxxxxxxS0|<911:14082993233>S0|<411:18003733411>S0|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1650>[2-9]xxxxxx)
SP1 Google Voice: ((Mste)|<**2>00xx.|<**2>011xx.|<**2:>xx.)
SP2 Localphone: ((Mste)|<00:>xx.|<011:>xx.|1234567)
Note that the last 1234567 is the localphone voip address of an ATA kept in my parent's home so that I can do a voip call without Obi invoking the "ste" rules and prefixing US area codes. This was the reason for keeping "xx." previously, but now since I removed it, I explicitly replaced it with specific VOIP addresses.
Thanks for your pointers!
Raj
ianobi:
I was hoping to start a trend for personalised DigitMaps! Oh well, maybe I can work IAN into one of mine :)
This is interesting:
sp1: ((Mste)|<**2>00xx.|<**2>011xx.|<**2:>xx.)
It works fine just as you describe. It will work for you and maybe others in some situations.
You actually found the main side effect yourself when testing call barring. When you dialled **219002345678 the number went out on sp1. There are two possible scenarios for this:
1. In the Phone Port DigitMap **219002345678 was matched by rule <**2:>xx. in the Msp1 DigitMap and the **2 was removed. 19002345678 was then processed by the Phone Port OutboundCallRoute and matched in Mpli (which is Msp1 in your case) and sent to sp1.
2. In the Phone Port DigitMap **219002345678 was accepted by the rule **2(Msp2),which would not transform it. **219002345678 was then processed by the Phone Port OutboundCallRoute and matched in Msp1 by rule <**2:>xx. which removed the **2 and sent the number out to sp1.
I believe scenario 2 is more likely. The Phone Port OutboundCallRoute checks numbers against its rules from left to right, so swapping rules like so …,{(<**2:>(Msp2)):sp2},{(<**1:>(Msp1)):sp1},… might make your setup work with no problem.
The call barring using “!” only seems to work if the number has nowhere else to go. I’ve never been very confident of how the “!” rules work. I will do some experiments when I get time to find out for sure.
Edit: See here for more info on call barring:
http://www.obitalk.com/forum/index.php?topic=4799.msg31198#msg31198
Navigation
[0] Message Index
[*] Previous page