News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Digitmap not working as expected for international and 900 blocking

Started by RajR, December 07, 2012, 04:40:11 PM

Previous topic - Next topic

RajR

Hi Experts,

I just started with an OBi110.
SP1=Google Voice
SP2=Localphone
Primary line = SP1

My goal: All USA calls go via SP1 (GV), all international calls go via SP2 (Localphone) without 011/00 prefix (provider requirement). Also, block all 1900 premium numbers and route 411/911 to appropriate destinations. Here is my digitmap that ALMOST works (no other settings changed):

User defined (ste): (<911:14082993233>S0|<411:18003733411>S0|!1900xxxxxxx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1650>[2-9]xxxxxx)

SP1: (<**2><00:>xx.|<**2><011:>xx.|(Mste)|(Mipd)|[^*#]@@.)

SP2: ((Mste)|xx.|(Mipd)|[^*#]@@.)

Issues:

1. Dialing a 1-900 number via SP1 (GV) gives a fast busy tone (good/expected), however dialing the same via SP2 (prefixing **2) the number attempts to get routed and fails with a 404 error. I was expecting the Obi would not even deliver the number to the SP2 and give a fast busy as well, which is not happening. Is this an issue with the digitmap?

2. Is there any way to modify the digitmap to allow selective international number dialing using SP1 either by prefixing with **1 or some other means... without having to change digitmaps?

3. Is the digitmap shown above ok or any way to write them better or as per recommendations? For example, I had initially tried <**2><011:>011xx. for dialing 011, but that did not work, instead removing the 011 prefix worked, but I am not sure why.

4. Newbie GV question: My GV Inbound calls ring fine but it does not ring the other forwarded phones setup in GV. Is there some way to control the delay after which Obi handles the GV call so other phones also ring? This is now working. May have been a GV glitch.

Thanks!
Raj

RajR

Update: I am not sure the barring is even working. To test it, I replaced the "!1900xxxxxxx" with my cellphone e.g. "!16505555555" and it still rang the phone! So Is there something wrong in the digitmap? Should the barring numbers be directly inserted in the SP digitmap versus a user defined one?

Please help!
Thanks.

ianobi

User defined (ste) can be a good idea if you need a lot of the same rules in different DigitMaps. Are you sure that applies here? It seems that the two DigitMaps should be doing very different things.

This does not answer all your points, but try it and come back with your thoughts and we can probably work the rest of your points out:

sp1: ((Mste)|<**2>00xx.|<**2>011xx.)

sp2: ((Mste)|<00:>xx.|<011:xx.>|xx.|(Mipd)|[^*#]@@.)

Be careful with rules such as xx. and [^*#]@@. As far as digits are concerned they both match any digit followed by any number of digits. [^*#]@@. Can be improved by changing to [^*#]@@.'@'@@. Or just remove [^*#]@@. If you are not using sip uri dialling in that DigitMap. I have removed (Mipd)|[^*#]@@.) from sp1 as GV does not allow sip uri dialling.

Edit: <011:xx.> should read <011:>xx.


carl

Just to remind you that Localphone allows for outgoing number blocking , that should take care of the 900 problem.

RajR

Thanks Carl - the localphone outgoing number blocking is what is getting kicked in and not allowing the 900 calls. However, I wanted to stop it at the source in case other providers don't support it. Hence wanted to try the the "!" barring feature.

Ianobi - thanks for the suggestion - I will try it out tonight and let you know if that works. I like the separation of concerns with your suggested digitmap. btw, the xx., Mipd and all that ^*@ stuff is something from the default Obi settings which I just left as-is. I will remove it as you said.
Re. (ste), since both sp1 and sp2 needed the same seven-ten-eleven routing, and also the 911/411 routing, I put that in the user-defined setup and assigned to both SPs. Apart from the international routing, is there any reason you see that the custom (ste) should NOT be reused in both SPs?

Thanks
Raj

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