News:

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

Main Menu

OBi212 **70 does not seem to work

Started by Rick313, May 05, 2018, 04:24:13 PM

Previous topic - Next topic

Rick313

I just switched from an OBi200+OBiLINE to an OBi212 thinking that fewer devices might mean fewer problems.  I have not had any issues with the OBi200, but I've read a lot of reports regarding issues with the OBiLINE, so I thought I would give the OBi212 a try.

Unfortunately, the **70 code does not seem to work properly on the OBi212 to dial out on the POTS line port.  One would expect this value to be stripped off before passing the remaining digits to the POTS line, but as far as I can tell, the OBi212 seems to be passing the whole string to the POTS line including the **70 which causes the outgoing call to fail.

The ## code works as expected, but I prefer to use **70 because the outbound number is written to the call history log whereas it is not when ## is used.  With the OBi200+OBiLINE, I could use either ## or **70 to dial out on the POTS line.  Is there a way to get **70 to work on the OBi212?

By the way, I also tried **8 in case the OBi212 worked similar to the OBi110, but that did not work either.  In that case, I get a recording saying that the service is not configured, but I assume that it is referring to BlueTooth since I can receive incoming calls from the POTS line.

azrobert

Why do you think the **70 isn't being stripped?
What error do you hear?

Look at the call history. Maybe that will give you a hint.

To access Call History:
Log directly into the OBi using the local interface.
Key the IP address of the OBi into a Web Browser and hit Enter
The UserID and default Password are both "admin".
Click Status on the left column then click Call History.

azrobert

Where I live we have 3 local area codes. We dial 10 digits for local calls and only 7 digits if the number is in my own area code. All other area codes are 11 digits.

Assuming you have the same dialing rules and you have a provider defined on SP1 for long distance calls, you can setup the OBi212 to do the following without a prefix:

11 digits routed to SP1
10 digits non-local numbers routed to SP1 as 11 digits
10 digits local numbers routed to Line
7 digits routed to Line

You would be able to override these rules by dialing an ** prefix
I could help you configure the OBi212. You would need to use OBi Expert.

Rick313

Quote from: azrobert on May 05, 2018, 04:44:29 PM
Why do you think the **70 isn't being stripped?  What error do you hear?

When I dial **70 with nothing after it, I would expect to hear a dial tone like I do when I dial ##.  Instead, I hear what sounds like a very fast busy signal which I assume is a dialing error.

Quote from: azrobert on May 05, 2018, 05:00:10 PM
Where I live we have 3 local area codes. We dial 10 digits for local calls and only 7 digits if the number is in my own area code. All other area codes are 11 digits.

I'm not looking to do anything fancy.  I just want the OBi212 to work like the OBi200+OBiLINE.  Seems like it should be pretty easy, but I'm still pretty new to these devices, so I haven't figured out all of their quirks yet.

azrobert

Quote from: Rick313 on May 05, 2018, 05:34:10 PM
When I dial **70 with nothing after it, I would expect to hear a dial tone like I do when I dial ##.  Instead, I hear what sounds like a very fast busy signal which I assume is a dialing error.

Dialing **70 with nothing after it is a dialing error and should produce a fast busy.

Dialing **70 followed by a phone number will route that number to Line. You will hear a few seconds of silence then ringing. The default OBi200 should do the same.

Rick313

#5
The bottom line is that if I dial ## + phone number, the call goes through, and if I dial exactly the same number replacing ## with **70, I get a fast busy signal.  The call should go through either way.  Why does **70 fail?

azrobert

#6
Please use OBi Expert to copy and post the following. Uncheck both boxes to the right of the value before copying.

Physical Interfaces -> Phone1 -> DigitMap
Physical Interfaces -> Phone1 -> OutboundCallRoute
Physical Interfaces -> Line -> DigitMap

When you dial **70+Number do you pause after the **70 ?

Rick313

#7
OutboundCallRoute
{911:li},{933:li},{([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}

Phone DigitMap
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|##|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))

Line DigitMap
(xxxxxxxS4|1xxxxxxxxxx|xx.)

I have tried dialing with a pause and without pause with the same results.

By the way, on the OBi200, I hear a few seconds of silence before I hear the fast busy signal after dialing **70 followed by nothing.  On the OBi212, I hear the fast busy signal immediately.  I don't know if that makes a difference, but I thought I would mention it.

azrobert

I edited my post. Please post the following. Sorry.

Physical Interfaces -> Line -> DigitMap

How many digits do you dial after the **70?

I don't see any problem with the DigitMap or OutboundCallRoute.

**70(Mli) will validate the dialed number.
The number after **70 must match a rule in the Line DigitMap.
The default Line DigitMap contains rule "xx.".
This will match 1 or more digits.
That is why you need at least 1 digit after the **70

Rule {(<**70:>(Mli)):li} will strip the **70 and route the number to Line.

Rick313

I have tried 3 digits, 7 digits, 10 digits, and 11 digits after the **70.  The ## code generally seems to prefer 11 digits, so that's what I have been using most of the time.  The number of digits does not seem to make any difference since no calls have been successful using **70 on the OBi212.  On the OBi200, I think I had to use 11 digits after the **70, but at least it worked.

azrobert

Again, I don't see any problem.
Try the following:

Phone OutboundCallRoute
{911:li},{933:li},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<**70:>xx.):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}

Phone DigitMap
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|##|**70xx.S3|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))

Rick313

It works!  Thank you SO much for your help Robert.  I never would have figured that out on my own.  I understand the xx. from your earlier explanation, but I'm curious, what does the S3 do?

azrobert

First, I'll explain why and what I did. Everything pointed to a bad Line DigitMap, but there isn't anything wrong with that DigitMap. It is set at default. I removed any (Mli) rule that references the Line DigitMap and replaced it with an inline rule. I suspect an internal corruption of the DigitMap. This happened to me and I fixed it by deleting my OBi from the portal, doing a factory reset and then did the setup like it was a new box.

xx.S3
The 1st x matches a single digit
The x. matches zero or more digits
So xx. matches 1 or more digits

The OBi examines each dialed digit as they are received.
It waits 0, 2 or 10 seconds for additional digits depending on which rule matches the dialed number.

If the dialed number matches a rule and can't match another rule with additional digits, it waits zero seconds for additional digits.

If the dialed number matches a rule and can match another rule with additional digits, it waits 2 seconds.

If the dialed number only matches a rule ending with x., it waits 10 seconds.

The xx.S3 overrides the 10 second wait with 3 seconds.

The 2 and 10 second wait are controlled by the Short and Long timers.
You can globally change these timers with a Phone Port setting, so you won't need the S3.


Rick313

Interesting.  Now that you mention it, I did have trouble registering the device initially.  It failed several times before it was finally successful.  I probably should have tried a factory reset.  I will remember that for future reference.

Thanks again for all of your help.  It is very much appreciated.