Callcentric Backup - Using Anveo with the Obi for E911 and DID
rsriram22:
Quote from: MikeHObi on November 05, 2012, 06:44:30 am
... I do understand that with Anveo I can configure my Google Voice number and have it presented as the CID number for E911. But that isn't really required is it? I will read some of the other posts to see if there is something I'm missing.
you *cannot* set any number of your choice as outbound CID for 911 calls with anveo (and CC).. anveo sends a 'hidden' CID to 911 and so does CC (although CC can give that number to you ahead in time, but it only gets activated when 911 call is made)..
HMishra:
(Reposting after embedding image)
1: I would like to propose using the first option (of using call flow) instead of the one shown. It does need some configuration changes when setting up the call flow, but once done, will provide a failsafe mechanism to route your incoming calls to an alternative number e.g. cell# in the event of power failure or internet outage at your premises. The call flow I have setup is below.
The above call flow will not cost any more if you have the 'Personal Unlimited' plan for $2.00/month. That entitles you to unlimited free incoming calls. E911 costs $0.80 on top of that for a total of $2.80/month.
(Edit) I would like to add that because of this call flow above, I did not elect to signup for the SIP status alert service mentioned below since I would receive the call using the failsafe mechanism if my Obi lost Anveo registration for any reason.
2: The other option is to sign up for SIP status alert at an additional costy of $2.99/month.
MikeHObi:
Quote from: rsriram22 on November 05, 2012, 07:07:07 am
you *cannot* set any number of your choice as outbound CID for 911 calls with anveo (and CC).. anveo sends a 'hidden' CID to 911 and so does CC (although CC can give that number to you ahead in time, but it only gets activated when 911 call is made)..
Understood now after reading some threads over at DSLReports. I believe the main concern is that Anveo (and some others) dynamically create a temporary CID number for E911 to call you back on if you get disconnected. The down side to this is that Anveo (and some others) have to provision your E911 data into the destination E911 provider when you place the call. And only if this provisioning is successful does your E911 call get connected. This on the fly provisioning is different than say a POTS line which provisions this data in the 911 database when the phone number is issued.
From what I found, Voip.ms doesn't do it this way, and instead assigns the 911 to a DID you enable. The big difference thus that Voip.ms when connecting 911 doesn't have to do the inserting of your data into the 911 providers db while someone doing things like Anveo has to. But this also means Anveo can give you E911 without you having a DID, and Voip.ms can not.
CallCentric does it similar to Anveo.
It would be interesting to see a guide for setting up Voip.ms or any other provider. I did this one for Anveo simply because the configuration was less than clear for my simple needs and knowledge level.
HMishra:
Speaking of E911, I just tested it by arranging ahead of time with my local police department. The call itself was answered succesfully and confirmed by 911 operator that she did see my verified address come through at her end.
However, at least with Anveo, there appears to be a delay of @ 5 seconds after dialing 911 for the phone at the other end to start ringing where as normal 10 digit numbers start ringing immediately. I am using the same digit map as configured by default by Obitalk portal when I setup Anveo service. Anyone else experience this delay if they have attempted a similar test?
Additionally, does anyone have a suggestion to remove the delay between dialing 911 to the phone ringing at other end? I know it has something to do with adding S0 at the end but not sure where to add it.
There is Service Provider -> ITSP Profile A -> DigitMap = (*xx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.)
Also, Physical Interfaces -> Phone 1 -> DigitMap = ([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|**8(Mbt)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))
Also, Physical Interfaces -> Phone 1 -> OutboundCallRoute = {911:sp1},{([1-9]x?*(Mpli)):pp},{(<#:>):ph2},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**9:>(Mpp)):pp},{(Mpli):pli}
Finally, Physical Interfaces -> Phone 1 -> CallReturnDigitMaps = {pli:(xx.)},{sp1:(<**1>xx.)},{sp2:(<**2>xx.)},{sp3:(<**3>xx.)},{sp4:(<**4>xx.)},{bt:(<**8>xx.)}{pp:(<**9>xx.)}
Thanks,
CoalMinerRetired:
You put "S0" right after any instance of 911, as in "911S0". The explanation for it is under "Digit Map Rules and Elements" in the device admin manual.
Here's the quote from the manual, I bolded the part that applies in what it does here: Quote
S, S0, S1, S2, …S9 - Digit timer of 0, 1, 2, …,9 seconds respectively; S is equivalent to S1; S0 is the same as “blank”. You can concatenate multiple S elements together if you need more than 9s timeout, such as S9S5 for a 14s timeout. S is CASE SENSITIVE. It should only be used either as the first element of a rule for hot/warm line implementation, or as the last element of a rule as a means of overriding the default interdigit timer
Navigation
[0] Message Index
[#] Next page
[*] Previous page