911 Calls Not Going out PSTN Line

[robhouston]

I'm using the following DigitMap for ITSP Profile A General on my Obi110:

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

Google Voice is set up on the Obi, and the line port is plugged into a POTS line.  This DigitMap successfully allows all 11 and 10-digit calls to go out by GV, and all 7-digit calls to be completed on the POTS line. 

However, when I attempted to do a 911 test today (after arranging it with our PSAP), the calls were not completed.  Every time I dialed "911", nothing happened.

What is missing or wrong?

Thanks!

[RonR]

911 calls should go out the LINE Port by default:


PHONE Port DigitMap:

([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|**1(Msp1)|**2(Msp2)|**8(Mli)|
**9(Mpp)|(Mpli))

PHONE Port OutboundCallRoute:

{([1-9]x?*(Mpli)):pp},{(<#:>|911):li},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},
{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}

[robhouston]

RonR-----yes, that is the exact digitmap and OutBoundCallRoute in the Phone Port on the Obi, but the 911 calls are not being completed.  I successfully made a 911 test using a telephone directly connected to the POTS line, so I know that it works.

This is a wild thought, but could the fact that I have "S1" in the DigitMap for ITSP Profile A be a problem?  I was attempting to minimize the dialing delay, but now I'm wondering if I created a problem with that.

Thanks
 

[RonR]

That S1 shouldn't kick in until you've entered 7 digits.

Can you dial only a '#' and get a PSTN dialtone?

You might try taking the <**8> off of the xx. rule to see what happens.  I don't think that should be causing a problem, but let's make sure.

[robhouston]

Yes, the # gives me a PSTN dial tone.

Okay, I can remove the <**8> from the xx. rule, but I'll need to wait a day or so to test again.  I don't want to keep bothering the PSAP while I "experiment".   Interestingly, when I disconnect the Obi from the PSTN and dial 911, I get the message "there is no service available to complete the call", so it seems like it's trying to dial out on the PSTN.  Unfortunately, test calls to 911 are not showing up in the Obi call history when the PSTN line is disconnected.

RonR, any other idea?  Thanks very much for the help.

[RonR]

With no battery on the LINE Port, the OBi knows it's not available and gives you the error message.

You could change '911' in the PHONE Port DigitMap and OutboundCallRoute to something like '211' (something that's not used nor valid) so you can do testing.

I really don't think the <**8>xx. rule in ITSPA is the problem, but it needs to be eliminated as a possibility.

[robhouston]

Great idea, RonR!  I'll change the "911" to experiment.  I'll let you know what happens.

[robhouston]

RonR----Okay, I changed the "911" in the Phone DigitMap and OutboundCallRoute to "211".  (211 is actually used here in NJ as a community resource number and is routed to a call processor).

I'm amazed, but the 211 calls worked fine, and removing the <**8> from the xx. rule made no difference.  It's got me wondering whether my 911 failures were a fluke, but strangely, the 911 attempts never made it to the Obi110's call history.  This is a serious concern, since if it was a real emergency, I could have never reached the 911 dispatcher, at least during the time when I was testing.    The good news is that I'm still in "test mode" with the Obi, meaning that I haven't wired it to the house phones yet, other than connecting it to the PSTN through the Line port. 

I'll need to do more testing over the next couple of days, so thanks very much for the ideas.

[RonR]

Search other areas for a DigitMap containing '911' in case it's left over from something previous.  It really didn't make sense that 911 wasn't working.

If you've got another ATA laying around that will give you battery and possibly dialtone, you could plug it into the OBi's LINE Port to simulate a PSTN line so you could go back to testing with '911' without it going out anywhere.

[robhouston]

RonR----Your idea to use another ATA for testing was brilliant.  I hooked up a Grandsteam HT502 into the line port of the Obi110.

So here's the interesting thing------when I dial 911, it's trying to go out on GoogleVoice.  I can't find anything in any DigitMaps that might be causing this.  If I dial 211, the call is routed to Line1 (correctly).  If I remove the "911" and replace it with "211" in the Phone DigitMap and OutBoundCallRoute, it still behaves the same way.

Somehow, the 911 calls are always being routed through Google Voice, instead of through Line 1. 

It's very frustrating, and I'm tired, so I'm going to have to knock off for now, but any other suggestions are very much appreciated, and I'll probably work on this late tomorrow.

Thanks!

[robhouston]

Okay, so I made a change that seems to be working, at least with my test setup using another ATA to simulate a PSTN. 

For the PHONE OutboundCallRoute:
{([1-9]x?*(Mpli)):pp},{(<#:>|911):li},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},
{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}

I changed the rule (<#:>|911)  TO   (<**8:>|911)

I haven't fully tested everything to see what else might have been affected, but this is routing 911 calls to LINE1, so that appears to be finally working.

Is there anything wrong with making this change?

Thanks!

[RonR]

I changed the rule (<#:>|911)  TO   (<**8:>|911)

I assume you meant:

{(<#:>|911):li}  to  {(<**8:>|911):li}

That changes dialing a single '#' for a direct connection to the LINE Port to '**8' instead.

That shouldn't be necessary nor does it make any sense if that makes 911 work.

Are any DigitMap's NOT at the default value besides ITSPA?

If you put the ITSPA DigitMap temporariliy back to default (as well as the OutboundCall Route), does 911 work correctly?

[robhouston]

RonR:

Yes, your assumption is correct.  The only DigitMap changed is ITSPA, and to my knowledge all of the rest of the DigitMaps are set to default.  Further, when I change the DigitMaP of ITSPA back to default, I still can't dial out 911 to LINE1.

Yes, I've noticed that I can no longer use the # to get a direct connection to the LINE port, but clearly, when I change that rule back to # instead of **8, the 911 calls are routed to GoogleVoice.

Maybe I just need to reset the entire Obi110 to default and start over......

Thanks again for your help!

[RonR]

Maybe I just need to reset the entire Obi110 to default and start over......

I agree.  That may be the quickest and easiest way.

As you reconfigure, take it slow so you can spot the problem if it recurs.

Please let us know the outcome.

[robhouston]

Okay, I took the Obi110 back to factory default, and I started configuration all over again.  I reconfigured Google Voice and I'm successfully using the DigitMap in the original post.  All calls, including 911 calls over the PSTN, are working fine.

So, sweet success.......

However, I'm still looking for a way to reduce the delay for outgoing calls over PSTN.  Despite the fact that I have "S1" in my ITSP DigitMap, it still seems like the Obi is waiting 3 or 4 seconds before dialing the call on PSTN.  Is there maybe another timer somewhere?

Thanks for any advice.

[RonR]

Despite the fact that I have "S1" in my ITSP DigitMap, it still seems like the Obi is waiting 3 or 4 seconds before dialing the call on PSTN.  Is there maybe another timer somewhere?

I think what you're seeing is perfectly normal.

Dial a 7-digit number and watch the LINE Port LED (the right-most one) on the OBi.  It should start blinking 1 second after you've dialed the 7th digit.  That's the LINE Port going off-hook.  That's followed by a .5 second off-hook delay, followed by .4 seconds for each of the 7 digits to dial (.2 seconds DTMF ON followed by .2 seconds DTMF OFF).  That's about 4.3 seconds minimum before you could possibly hear any PSTN ringback.

Don't forget, you can always terminate your dialing with a #, which is guaranteed to start the OBi processing your call immediately with no further delays.  I personally think your S1 is a bad idea because it forces you dial the 8th digit very quicky when you're trying to dial a 10- or 11-digit number, otherwise the OBi takes off dialing the first 7 digits.  I would at least delete the S1 entirely, leaving a 2 second delay in place.  I prefer a 4 second delay (S4) just in case I get distracted.  I always terminate all dialing with a #, so it doesn't matter how long the default delay is.

[robhouston]

RonR----thanks again for your prompt response.  

Yeah, I think I may have to get used to the delay.  You make a good point about a minimum 4-second delay for outbound PSTN dialing.

Rob

[robhouston]

RonR-----I just found this DigitMap for the Line port (PSTN in my setup):

(xxxxxxxS4|1xxxxxxxxxx|xx.)

Wouldn't this add a 4-second delay to outbound calls on the line port? 

Thanks!

[shap]

Press # at the end of the dialed number and your call will be placed immediately. Or you can change the DigitMap and add S0 at the end of 911.

[RonR]

RonR-----I just found this DigitMap for the Line port (PSTN in my setup):

(xxxxxxxS4|1xxxxxxxxxx|xx.)

Wouldn't this add a 4-second delay to outbound calls on the line port?  

Thanks!

Only if your PHONE Port -> PrimaryLine = PSTN LINE and you dial a 7-digit number OR you explicitly dial **8 + 7-digit number.

In your case, where PHONE -> PrimaryLine = SP1 and you're dialing 7-digit numbers without a **8 prefix, the LINE Port DigitMap only comes into play when the OutboundCallRoute is evaluated (because **8 was added to the 7-digit number by the ITSPA DigitMap).  'Sn' operators are ignored when a DigitMap is being evaluated in the context of an OutboundCallRoute.  'Sn' operators only effect a delay when they're evaluated in the context of the PHONE Port DigitMap, in which case the LINE Port DigitMap will only be a candidate for evaluation if the first sentence in this post is true.

You have to remember that placing a call is a two-stage process:

1.  The PHONE Port DigitMap is evaluated using the dialed number and returns the best matched value ('Sn' is honored).

2. The OutboundCallRoute is evaluated using the number returned in stage one ('Sn' is not honored).