Simple 911 Redirection

(1/2) > >>

Lavarock7:
To simplify the redirection of 911 or other emergency calls through service providers or out the LINE port, I propose:

A simple lookup table along the lines of the table in the 202 that would take precidence at all times. I realize this can be done with dial strings and so on, but perhaps a simple lookup table would eliminate the possibility of a misdirected call, especially for 911. I envision this idea NOT using substitution but rather a strict lookup and forced dial.

Phone1 911 routes to SP1 and is dialed as 911
Phone2 911 routes to SP2 and is dialed as 123-555-1911

The bold items are user entered and would accommodate overseas emergency numbers too.

primerisk:
The solution below isn't accessing a table lookup, but at the end of the day that is just a GUI design decision.  That table lookup could be implemented on the web administration interface or on the Obi itself.  Is there some reason other than the interface that you want to have a lookup table?  There needs to be a 1 to 1 mapping between the phone port and what action happens when someone picks up a handset and dials 911.

Are you looking for a page where it asks "911 Action"  with options for each Port that selects the SP and what number to route it to?  IE:

Port: PHONE1
Service Provider: SPx
Route To #: 911 | 123-456-9111

For my solution you'll just have to go into Obi Expert Configuration and under Physical Interfaces select the phone port ("PHONE 1, or "PHONE 2" as appropriate), uncheck “ObiTalk Settings” and “Device Default” for OutboundCallRoute and replace the current entry with:

Since you are referencing Phone1/Phone2 ports i'm making an assumption that you have an Obi202 or maybe 302.

Original Phone 1/2 OutboundCallRoute:
{([1-9]x?*(Mpli)):pp},{(<#:>):ph1},{(<**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 1 OutboundCallRoute:
{([1-9]x?*(Mpli)):pp},{(<#:>):ph2},{(<911:911>):sp1},{(<**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 2 OutboundCallRoute:
{([1-9]x?*(Mpli)):pp},{(<#:>):ph1},{(<911:1235551911>):sp2},{(<**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}

And YES, at the end of the first rule where is says "ph2" for the Phone 1 Call Route and "ph1" for the Phone 2 Call Route is correct.  If you reverse those it will just show the wrong port in the call log (AFAIK).  You can check it on your original config.

Lavarock7:
Thanks for the reply.

When I said "table" I should have just suggested a simple table, similar to

[911] -->> [18775550911]
[411] -->> [8007000411  ]

I personally am somewhat familiar with how to modify the call routes, etc. My suggestion is to make it simple for the many non-technical users we have trying to make these changes to 911 (and similar substitutions). Making this very simple and foolproof is important.

My suggestion is this: When a user configures a SP, one question could be:

Is this SP the one handling 911?
When you dial 911, what number should be sent to the provider? [18775550911]

This would make it extremely simple and eliminate people having to guess if they are making the correct substitution in the right place and would even eliminate them having to test 911.

My suggestion also allowed for a couple/few substitutions such as 411, 911 etc

JerryT:
This solution works on my Obi100 for 911 and 411 with two caveats:  1) the 411 number seems to be out-dated, 2) the 911 number goes to the Salt Lake County police non-emergency line.

Go to expert configuration, physical interfaces, phone, and look for "OutboundCallRoute".  Uncheck the boxes so you can make a change.  Here is my before and after config lines:

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

Modified:
{([1-9]x?*(Mpli)):pp},{(<911:18018404000>):sp1},{(<411:18002464411>):sp1},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**9:>(Mpp)):pp},{(Mpli):pli}

When I call 911, I get a recorded message saying this is the non-emergency line and to please wait for the next available dispatcher.

Lavarock7:
Thanks Terry, but this was a request for an enhancement, not a question about how an owner could use existing configurations.

My idea for the request was to have a simple, fill in the blank location on the setup page where the user entered in a number to be used when 911 is dialed. This eliminates the user from having to modify any dial string manually.

There would be no testing needed.

Imagine a section on the setup that looks like this:

---

When a person dials 911 on the phone, what number should be sent out?
[X] 911
[ ] [            ] This number will be sent out the service provider exactly as entered.

For example, if your emergency number is 810-840-4000 and your service provider requires a 1 first, you would check the second box and enter "18018404000".

---

The request was created because I saw many people who were not familiar with dial strings trying to cram in numbers and test, trying to adjust dial strings for a number that they needed to work first time, every time. They didn't understand Expert config; they understood little of how to make the Obi work in the first place.

The Obi202 asks some very simple questions like "Primary Line for Outgoing Calls Route to:" and a simple choice is the Service Provider.

I think there can be a simple question and answer field that would allow a new user to configure where the 911 call is routed without having to touch a dial string or expert configuration, etc.

Even a speed dial called 911 that had an entry for a phone number and ability to associate it to a service provider, would make this more seamless.

Navigation

[0] Message Index

[#] Next page