[VoiceOps] ADT Alarms Special Dialing?
Paul Timmins
paul at timmins.net
Thu Aug 6 20:34:54 EDT 2015
Many alarm systems use Ademco Contact ID which requires very tight
tolerances on the DTMF. I actually just had to demand firmware changes
to our TDM switch's packet interface card's RTP handling to get the
tolerances right (the ISU the other night fixed it! yay!). The FSK (SIA
somethingorother) is hit or miss too, sometimes it can trigger T.38
detection in the network and then you're screwed a different way.
We've standardized on getting our customers to use Contact ID and
getting the DTMF codecs working just right. It's not always easy but
then we can predict. We're one of the few in our area where alarm panels
work consistently, PBX vendors seem to like that. :-) Makes the cutover
much easier.
-Paul
On 08/06/2015 08:03 PM, Nathan Anderson wrote:
> I doubt it. We are an ISP and ITSP doing voice exclusively 100% over IP. We have historically actively discouraged hooking up an alarm system to our service and relying on that (in order to avoid support headaches, liability issues, etc.), but we ourselves have an ADT system that was previously hooked up to local ILEC POTS service and that we moved over to an ATA of ours as an experiment.
>
> It actually works just fine now, but it didn't initially. Turns out that the default "modulation" technique used between the panel and the monitoring center is...DTMF. Really. It appeared that either the monitoring center or the panel (or both) did not like something about how either the ATA or the terminating provider was regenerating the DTMF tones from the OOB info. Not sure if it was a timing issue or what. I am pretty sure I did try forcing DTMF to not be decoded/re-encoded and just remain inband, but that didn't seem to work for whatever reason (can't remember the details; it's been a while since this all transpired).
>
> Eventually, I managed to track down an installer's manual for the particular model of panel we have, and was able to reprogram it to use a form of FSK modulation to talk to the monitoring center instead. It's super low bitrate (300 baud IIRC), and works 100% perfectly over G.711 PCM. (I know this because after I made the change, I accidentally managed to set the alarm off, and ADT called my boss, etc.; that was fun...) We have been using the panel this way for months, plugged into a VoIP ATA.
>
> The panel dials an 800 number periodically to check in, and also when the alarm is tripped. If it cannot complete a check-in successfully, a light on the panel will be illuminated. That LED has not come on since the modulation switch. If they were doing LRN lookups, we would fail that test as well since none of our sources for DIDs are on ADT's "approved" list, either. I am sure I can get you the number that ours dials if you care to have it, but I have no way of knowing if they use the same number in all geographies or across all product lines (ours is an office/business system that I'm pretty sure doesn't get used in residential installs; for all I know, it may call a different monitoring center than the residential product(s) do).
>
> Hope this helps at least give you some more ideas,
>
> --
> Nathan Anderson
> First Step Internet, LLC
> nathana at fsr.com
>
> -----Original Message-----
> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor
> Sent: Thursday, August 06, 2015 4:30 PM
> To: voiceops at voiceops.org
> Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
>
> I did find this page http://www.adt.com/customer-service/voip-faqs Seems that your phone company has to be:
>
> A Qualified “Managed Facility Voice Network (MFVN)”includes the following:
> 1. Has a physical facilities network which is managed and maintained (directly or indirectly) by the service provider. Can ensure service quality from the service subscriber location to the PSTN or other MFVN peer network.
> 2. Utilizes similar signaling and related protocols as the PSTN with respect to dialing, dial plan, call completion, carriage of alarm signals and protocols, and loop voltage treatment.
> 3. Provides real-time transmission of voice signals, carrying alarm formats unchanged.
> 4. Provides professional installation that preserves primary line seizure for alarm signal transmission.
> 5. Has major and minor disaster recovery plans to address both individual customer outages and widespread events such as tornados, ice storms and other natural disasters. This includes specific network power restoration procedures that are comparable to those of traditional landline telephone services in the same geographic region.
> 6. Has informed ADT that its network meets the characteristics of a MFVN.
> Still how are they controlling this? Think ADT is smart enough to do a LRN lookup on a number, and see its not one from their qualified list?
>
> -----Original Message-----
> On Thu, Aug 6, 2015 at 6:21 PM, Colton Conor <colton.conor at gmail.com> wrote:
> We are a CLEC and have a had a couple of customers port away from Verizon's landline service and to our voice service where we provided an analog POTS line with the same number just as the client had before with Verizon. We hook the POTS line up to the exact same wire going to the client's alarm panel, but the alarm can't communicate with ADT.
>
> We called ADT on multiple clients behalfs, and they basically said Verizon is on an approved list to work with their services and our CLEC is not, so it would not work.
>
> How is ADT limiting this? Does their alarm panels dial a special number that only Verizon knows or allows? This has happened with multiple clients.
>
> We have not been able to get on the voice switch and see what numbers they panel is actually trying to dial, but any insight to this would be helpful.
>
> I have read that some alarm companies uses a special code before they make an outbound call so the long distance gets billed to them or something?
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
More information about the VoiceOps
mailing list