Digimap and outgoing porting for Obi202

[hueofheather]

I am sorry to have to post this as there are lots of posts on this subject, but I am missing something.

I have Google Voice on SP1, and have it set as the primary line.  I have a freephoneline.ca on the second line.  all I am really trying to accomplish is that area codes 613 and 815, and the emergency 911 go to SP2, the freephoneline account.

I have tried various plan configurations and have only gone backwards, so any help would be great.  I have no traditional land line so I disabled the line.

Any help would be greatly appreciated,
Chris

[Shale]

Here is my try at doing what you ask:

Add this string just after the first '(' in your default ISTP Profile * General DigitMap
<**2>911|<1?:**21>613xxxxxxx|<1?:**21>815xxxxxxx|

Since you use SP1 as your default you will use ISTP Profile A if you just dial 3 or more digits.
Suppose your original ISTP Profile A General DigitMap is this:

(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)

Convert that to
(<**2>911|<1?:**21>613xxxxxxx|<1?:**21>815xxxxxxx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)


Explanations:
<1?:**21>613xxxxxxx
says to send either 6137654321 or 16137654321 to SP2 as 16137654321
The 1? means match nothing or a 1, and then replace that with **21
The **2 means to send to SP2, and the always 1 gets added in front of the 10 digits.

There are various threads where a similar method was discribed., but here a two:
https://www.obitalk.com/forum/index.php?topic=6325.0
http://www.obitalk.com/forum/index.php?topic=1279.msg8068

I could have made one or more mistakes, and there may be more optimum ways of doing that. You might want to wait until Ianobi takes a look.

[ianobi]

My personal preference is to route 911 direct from the Phone Port OutboundCallRoute. This avoids any possible conflicts or delays in the digitmaps:

Physical Interfaces > PHONE Port 1/2 > OutboundCallRoute:
{911:sp2},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**9:>(Mpp)):pp},{(Mpli):pli}

<1?:**21>613xxxxxxx|<1?:**21>815xxxxxxx

This is logical and follows the rules in the AdminGuide precisely. However, I have tried this myself and found a problem. Here is what I posted:

I tried to have smaller/neater digit maps by using a rule such as 1?800xxxxxxx (1 or no 1 followed by 800 etc). This works fine in a digit map on its own. However, when sharing a digit map with rule 1xxxxxxxxxx even if you dial 18002345678 the Digit Map Processor will use rule 1xxxxxxxxxx as the best match. It seems that "1" always takes precedence over "1?"

Of course, the OP will not have any problem if they don't dial the "1".

In my config, 911 is routed as described above. I don't know if FPL needs the "1" or not. If it does then the ITSP A digitmap would be:

Service Providers > ITSP Profile A > General > DigitMap:
(<**21>613xxxxxxx|<**21>815xxxxxxx|<**2>1613xxxxxxx|<**2>1815xxxxxxx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)

Sorry to raise such obscure points in this post, but these things can have you going around in circles for days - as I well know  

[Shale]

Obscure? Yours seems very clear and, unlike my first try, works... Now this might be more obscure:

<1?:**21>(613|815)xxxxxxxS0

The S0 would seem to overcome the precedence problem. I can see that getting modified with some bad consequence, but for this purpose the S0 seems safe enough. But brevity over clarity can be a very bad thing in such strings.

[ianobi]

Shale,

That's interesting. It would seem to depend on speed of processing. The 1xxxxxxxxxx rule has a two second delay built in as a result of the "xx." rule in the same digitmap.

Getting late here - I'll think about this one tomorrow 

[Shale]

While we are discussing obscure, I wonder how <x?>xx. would do to replace xx. as the catch-all with lower precedence.  Much less obscure might be xx.S2 or xx.S4  as alternatives.

These are not suggestions to hueofheather or others, but just throwing them out as for food for thought.

Longer but clearer strings are better for real use.

[hueofheather]

Well, thank you guys!

I used Service Providers > ITSP Profile A > General > DigitMap:

(<**21>613xxxxxxx|<**21>815xxxxxxx|<**2>1613xxxxxxx|<**2>1815xxxxxxx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)

Now however when I dial **2 to select the line, I get a busy signal. IE, to check voicemail.    If there is an easy fix, what would that be?

Again, thanks for your help!


I had the right idea but used the wrong Digimap.  I was in the Phone Port .



Thanks for your help!

[Shale]

Now however when I dial **2 to select the line, I get a busy signal. IE, to check voicemail.    If there is an easy fix, what would that be?

You are dialing **2 and then waiting? You need to keep dialing the digits before stopping. So you might dial **21202551234 to dial 1202551234 on SP2.

[ianobi]

Shale,

Much less obscure might be xx.S2 or xx.S4  as alternatives.

There's definitely merit in using xx.S4 instead of xx.

The problem here is that having xx. or [^*#]@@. in any digitmap means that whatever you dial those two rules are always in the "Indefinitely Matched" state. This means that even if you have a rule in the "Exactly Matched" state, there will still be a two second delay.

My personal preference is to delete xx.|(Mipd)|[^*#]@@. from my digitmaps and find other less general ways of matching numbers/characters.