ADT Alarms Special Dialing?
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?
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? 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?
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? ?
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
I guess we are lucky, then: we do a fair amount of T.38 traffic, and we have never had issues with either the ATA or the remote switch detecting that as a fax call and extending a re-INVITE. -- Nathan -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Paul Timmins Sent: Thursday, August 06, 2015 5:35 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? 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
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Quality of customer endpoints varies widely, my friend. I've had a few different T38 devices (can't remember offhand) kick in on not only FSK alarm panels, but credit card machines too. It's not *supposed* to happen but neither is talkoff (Looking in your direction, Cisco/Linksys/Sipura SPA-100x/200x with RFC2833/AVT). :) Most devices indeed work properly but I've learned long ago to just add that to my mental checklist of things to look for when people start complaining. Part of me wonders what the industry will look like in 5-10 years when everything has to work together natively with everything instead of the current model where there's TDM buffers between a wide variety of VoIP islands and I never have to worry that your customer's choice of PBX handset will affect my customer's ability to operate his IVR because there's a big bad PSTN between us reducing it down to audible touch tones. -Paul On 08/06/2015 08:42 PM, Nathan Anderson wrote:
I guess we are lucky, then: we do a fair amount of T.38 traffic, and we have never had issues with either the ATA or the remote switch detecting that as a fax call and extending a re-INVITE.
-- Nathan
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Paul Timmins Sent: Thursday, August 06, 2015 5:35 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
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
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I was going to touch on t.38 as well - I know that postage meters will trigger t.38 which will then cause the reload to fail. The alarm panels may be experiencing something similar. Rob -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Paul Timmins Sent: Thursday, August 06, 2015 8:35 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? 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
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Out of curiosity, are people experiencing these false-positive fax detections mostly on crap CPEs, or are you also seeing it on switches (either owned and operated by you or by a term provider you are handing a call off to via IP)? -- Nathan -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Rob Dawson Sent: Friday, August 07, 2015 8:37 AM To: Paul Timmins; voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? I was going to touch on t.38 as well - I know that postage meters will trigger t.38 which will then cause the reload to fail. The alarm panels may be experiencing something similar. Rob -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Paul Timmins Sent: Thursday, August 06, 2015 8:35 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? 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
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Wow thanks to all this has been a huge help! So we are using a Broadsoft for the voice switch connected by SIP to an Adtran Total Access 5000 that has VDSL2 Combo cards. So I assume we would need to change the DTMF settings on the Adtran. Have any recommendations on what to look for to make this work with ADT alarm lines if its truly a DMT issue. I don't like the idea of changing setting on the actual alarm. I prefer to get the POTS working right so it works regardless of the alarms settings. On Thu, Aug 6, 2015 at 7:03 PM, Nathan Anderson <nathana at fsr.com> 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?
TA5k only speaks DTMF inband VDSL2 and ADSL2+ combo cards. It's not a changeable setting. -Paul
On Aug 6, 2015, at 21:55, Colton Conor <colton.conor at gmail.com> wrote:
Wow thanks to all this has been a huge help! So we are using a Broadsoft for the voice switch connected by SIP to an Adtran Total Access 5000 that has VDSL2 Combo cards. So I assume we would need to change the DTMF settings on the Adtran. Have any recommendations on what to look for to make this work with ADT alarm lines if its truly a DMT issue.
I don't like the idea of changing setting on the actual alarm. I prefer to get the POTS working right so it works regardless of the alarms settings.
On Thu, Aug 6, 2015 at 7:03 PM, Nathan Anderson <nathana at fsr.com <mailto:nathana at fsr.com>> 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 <mailto:nathana at fsr.com>
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 4:30 PM To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
I did find this page http://www.adt.com/customer-service/voip-faqs <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 <mailto: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
Paul, And is inband DTMF not what the ADT alarm panel needs? On Thu, Aug 6, 2015 at 10:02 PM, Paul Timmins <paul at timmins.net> wrote:
TA5k only speaks DTMF inband VDSL2 and ADSL2+ combo cards. It's not a changeable setting.
-Paul
On Aug 6, 2015, at 21:55, Colton Conor <colton.conor at gmail.com> wrote:
Wow thanks to all this has been a huge help! So we are using a Broadsoft for the voice switch connected by SIP to an Adtran Total Access 5000 that has VDSL2 Combo cards. So I assume we would need to change the DTMF settings on the Adtran. Have any recommendations on what to look for to make this work with ADT alarm lines if its truly a DMT issue.
I don't like the idea of changing setting on the actual alarm. I prefer to get the POTS working right so it works regardless of the alarms settings.
On Thu, Aug 6, 2015 at 7:03 PM, Nathan Anderson <nathana at fsr.com> 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
An HTML attachment was scrubbed... URL: <https://puck.nether.net/pipermail/voiceops/attachments/20150807/d8f68a83/att...>
Treat it as a fax/modem line. It is in fact two machines communicating with each other? Disable echo cancellation Disable alc Disable plc Fix the jitter buffer at a max of 200ms Turn down the gain (reduces echo) Disable modem detection and t38 Disable call-waiting From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 8:55 PM To: Nathan Anderson; Jay Hennigan Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Wow thanks to all this has been a huge help! So we are using a Broadsoft for the voice switch connected by SIP to an Adtran Total Access 5000 that has VDSL2 Combo cards. So I assume we would need to change the DTMF settings on the Adtran. Have any recommendations on what to look for to make this work with ADT alarm lines if its truly a DMT issue. I don't like the idea of changing setting on the actual alarm. I prefer to get the POTS working right so it works regardless of the alarms settings. On Thu, Aug 6, 2015 at 7:03 PM, Nathan Anderson <nathana at fsr.com<mailto:nathana at fsr.com>> 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<mailto:nathana at fsr.com> -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 4:30 PM To: voiceops at voiceops.org<mailto: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<mailto: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?
Alarm systems being serviced over VoIP are generally speaking a very bad idea. What are you supposed to do when and if the power fails? A UPS is only going to last for so long hours maybe. An analog CO line gets power from the wire and won?t go offline in the event of a natural or manmade disaster. The CO usually has a generator and guaranteed fuel delivery. By bringing VoIP into the mix your opening yourself up a huge liability if the alarm system fails due to your failure and someone gets burglarized, robbed, and worse injured or killed you?ll most likely be on the hook. Do yourself a favor and stay away from supporting it. David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W) www.esi-estech.com *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Colton Conor *Sent:* Thursday, August 06, 2015 6:21 PM *To:* voiceops at voiceops.org *Subject:* [VoiceOps] ADT Alarms Special Dialing? 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?
This statement is not quite correct in case of FIOS or U-Verse - whenever those services fail - there is NO connection to CO. Unfortunately - those services are known to fail. Even worse - in case of a natural or manmade disaster - FIOS and U-Verse may and will be down for days if not weeks. 3 years back, after Sandy hit Eat Coast - many FIOS places in NYS, PA, NJ, etc were down within many weeks, some - several months. At the same time wireless and cable connections were repaired relatively quickly therefore 2 days after the storm - my wireless and cable Internet was functioning - and so was my home VoIP service and the 911. B/w - Verizon doesn?t maintain residential FIOS batteries anymore therefore during electricity outages - the battery is also found dead at the same time. Oh, yea - my ADT alarm system functions over VoIP during last 6 years (it?s also protected by wireless) - so far so good. -- Regards, GB.
On Aug 7, 2015, at 2:41 PM, David Thompson <dthompson at esi-estech.com> wrote:
Alarm systems being serviced over VoIP are generally speaking a very bad idea. What are you supposed to do when and if the power fails? A UPS is only going to last for so long hours maybe. An analog CO line gets power from the wire and won?t go offline in the event of a natural or manmade disaster. The CO usually has a generator and guaranteed fuel delivery. By bringing VoIP into the mix your opening yourself up a huge liability if the alarm system fails due to your failure and someone gets burglarized, robbed, and worse injured or killed you?ll most likely be on the hook. Do yourself a favor and stay away from supporting it.
David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com <mailto:dthompson at esi-estech.com> (W) www.esi-estech.com <http://www.esi-estech.com/>
From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: [VoiceOps] ADT Alarms Special Dialing?
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
If you want something that?s more reliable stick to a POTS line for an alarm system. Trusting your alarm system to a technology that is relying on the power being up in order to function is a good way to get cleaned out. David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W) www.esi-estech.com *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of * GregoryB *Sent:* Friday, August 07, 2015 2:01 PM *To:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] ADT Alarms Special Dialing? This statement is not quite correct in case of FIOS or U-Verse - whenever those services fail - there is NO connection to CO. Unfortunately - those services are known to fail. Even worse - in case of a natural or manmade disaster - FIOS and U-Verse may and will be down for days if not weeks. 3 years back, after Sandy hit Eat Coast - many FIOS places in NYS, PA, NJ, etc were down within many weeks, some - several months. At the same time wireless and cable connections were repaired relatively quickly therefore 2 days after the storm - my wireless and cable Internet was functioning - and so was my home VoIP service and the 911. B/w - Verizon doesn?t maintain residential FIOS batteries anymore therefore during electricity outages - the battery is also found dead at the same time. Oh, yea - my ADT alarm system functions over VoIP during last 6 years (it?s also protected by wireless) - so far so good. -- Regards, GB. On Aug 7, 2015, at 2:41 PM, David Thompson <dthompson at esi-estech.com> wrote: Alarm systems being serviced over VoIP are generally speaking a very bad idea. What are you supposed to do when and if the power fails? A UPS is only going to last for so long hours maybe. An analog CO line gets power from the wire and won?t go offline in the event of a natural or manmade disaster. The CO usually has a generator and guaranteed fuel delivery. By bringing VoIP into the mix your opening yourself up a huge liability if the alarm system fails due to your failure and someone gets burglarized, robbed, and worse injured or killed you?ll most likely be on the hook. Do yourself a favor and stay away from supporting it. David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W) www.esi-estech.com *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Colton Conor *Sent:* Thursday, August 06, 2015 6:21 PM *To:* voiceops at voiceops.org *Subject:* [VoiceOps] ADT Alarms Special Dialing? 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
In areas where FIOS is deployed - Verizon abandons/drops copper lines. The moment one orders FIOS - no more way to keep existing POST line. At least in my area. -- Regards, GB.
On Aug 7, 2015, at 5:08 PM, David Thompson <dthompson at esi-estech.com> wrote:
If you want something that?s more reliable stick to a POTS line for an alarm system. Trusting your alarm system to a technology that is relying on the power being up in order to function is a good way to get cleaned out.
David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com <mailto:dthompson at esi-estech.com> (W) www.esi-estech.com <http://www.esi-estech.com/>
From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>] On Behalf Of GregoryB Sent: Friday, August 07, 2015 2:01 PM To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
This statement is not quite correct in case of FIOS or U-Verse - whenever those services fail - there is NO connection to CO. Unfortunately - those services are known to fail. Even worse - in case of a natural or manmade disaster - FIOS and U-Verse may and will be down for days if not weeks. 3 years back, after Sandy hit Eat Coast - many FIOS places in NYS, PA, NJ, etc were down within many weeks, some - several months. At the same time wireless and cable connections were repaired relatively quickly therefore 2 days after the storm - my wireless and cable Internet was functioning - and so was my home VoIP service and the 911. B/w - Verizon doesn?t maintain residential FIOS batteries anymore therefore during electricity outages - the battery is also found dead at the same time. Oh, yea - my ADT alarm system functions over VoIP during last 6 years (it?s also protected by wireless) - so far so good. -- Regards, GB.
On Aug 7, 2015, at 2:41 PM, David Thompson <dthompson at esi-estech.com <mailto:dthompson at esi-estech.com>> wrote:
Alarm systems being serviced over VoIP are generally speaking a very bad idea. What are you supposed to do when and if the power fails? A UPS is only going to last for so long hours maybe. An analog CO line gets power from the wire and won?t go offline in the event of a natural or manmade disaster. The CO usually has a generator and guaranteed fuel delivery. By bringing VoIP into the mix your opening yourself up a huge liability if the alarm system fails due to your failure and someone gets burglarized, robbed, and worse injured or killed you?ll most likely be on the hook. Do yourself a favor and stay away from supporting it.
David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com <mailto:dthompson at esi-estech.com> (W) www.esi-estech.com <http://www.esi-estech.com/>
From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: [VoiceOps] ADT Alarms Special Dialing?
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 <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
The liability of a common carrier is typically limited to the amount paid for their services. I can't sue FedEx for a million dollars because they delivered a million dollar contract a day late and caused me to lose the deal. We'd all be bankrupt if someone dialed 911 during a phone outage and we were liable for it. IANAL but if telephone companies and ISPs were liable for damages for their services not working, they'd all be bankrupt after every natural disaster that takes out the phone lines, for making phone lines capable of being sabotaged by invaders prior to breaking in, and numerous other things. Analog CO lines get screwed up all the time. At least twice a year my analog line has an issue that my home's alarm system doesn't like, and takes at least 2-3 days to fix (even though I work at the CLEC and can directly open the ticket with the underlying carrier). AT&T isn't liable to me if my home gets broken into during that time, and my employer is liable for nothing more than perhaps a service credit for the 2 days I was without service. -Paul On 08/07/2015 02:41 PM, David Thompson wrote:
Alarm systems being serviced over VoIP are generally speaking a very bad idea. What are you supposed to do when and if the power fails? A UPS is only going to last for so long hours maybe. An analog CO line gets power from the wire and won?t go offline in the event of a natural or manmade disaster. The CO usually has a generator and guaranteed fuel delivery. By bringing VoIP into the mix your opening yourself up a huge liability if the alarm system fails due to your failure and someone gets burglarized, robbed, and worse injured or killed you?ll most likely be on the hook. Do yourself a favor and stay away from supporting it.
David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com <mailto:dthompson at esi-estech.com> (W) www.esi-estech.com <http://www.esi-estech.com>
*From:*VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>] *On Behalf Of *Colton Conor *Sent:* Thursday, August 06, 2015 6:21 PM *To:* voiceops at voiceops.org <mailto:voiceops at voiceops.org> *Subject:* [VoiceOps] ADT Alarms Special Dialing?
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
In addition to the other responses, I should point out that it would seem you are making an assumption here, and one that I would wager is an incorrect one. Nowhere did Mr. Conor say he was delivering voice to the end-user via IP. Nowhere. In fact, I would take his language ("...we provided an analog POTS line...") to mean that as a CLEC, at least in these specific cases that he is talking about, he is ordering copper UNE-L from the ILEC and pumping dial-tone down it with his own switch. (I don't want to speak for him, though, and would welcome his correction.) The only reason VoIP came up prior to this in the conversation was in order to give examples of things that others (including myself) have learned by experience can screw with a phone-based alarm panel's ability to communicate with the head-end. If ADT is not purposefully filtering out calls by doing real-time LRN lookups as calls come in (which I am sure they are NOT doing), then there must be something else in the path interfering with that communication. I offered my experience with DTMF problems over VoIP because I figured that it was possible that even if the last mile was not VoIP, somewhere between the switch that services his customer(s) and ADT's head-end MIGHT be IP-based transport, and perhaps the DTMF is getting massaged or mangled there. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Thompson Sent: Friday, August 07, 2015 11:42 AM To: Colton Conor; voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Alarm systems being serviced over VoIP are generally speaking a very bad idea. What are you supposed to do when and if the power fails? A UPS is only going to last for so long hours maybe. An analog CO line gets power from the wire and won?t go offline in the event of a natural or manmade disaster. The CO usually has a generator and guaranteed fuel delivery. By bringing VoIP into the mix your opening yourself up a huge liability if the alarm system fails due to your failure and someone gets burglarized, robbed, and worse injured or killed you?ll most likely be on the hook. Do yourself a favor and stay away from supporting it. ? David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W)?www.esi-estech.com -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops at voiceops.org Subject: [VoiceOps] ADT Alarms Special Dialing? ? 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? ?
Sorry for no response, I have been out lately. To answer everyone's concerns, we are doing exactly as Nathan has described. We are ordering UNE copper loops from Verizon the ILEC, and are putting POTS service onto these copper lines using an Adtran 5000 with VDSL2 Combo cards. The Adtran is powered by Verizon's battery and generators, and sends power directly over the line. This is exactly the same as regular diatone, we are not using VoIP ATA adapters in the field like FiOS or Uverse! The Adtran speaks SIP and converts SIP to FXS ports basically in the CO. The Adtran communicates to a Broadsoft that provides the SIP signalling and minutes. So, trying to correct the problem now. Based on what Paul said, there are no DTMF setting that can be changed on the Adtran 5000. Note, that while the SIP stack is similar, the Adtran 5000 does not have all the voice knobs and settings available that are on their much small 90X/90Xe series. I wonder if it is detecting it as a fax, and trying to send it as T38 instead. Any ideas on what can and can't be disabled on the 5000? I doubt ADT is doing real time LRN lookups, but they did acknowledge that they could see my number was recently portered away from Verizon to our underlying carrier. I have seen some other alarm brands that put a special Verizon specific code before a number, and that way it bills the alarm company. Do you know what that is called? On Fri, Aug 7, 2015 at 4:51 PM, Nathan Anderson <nathana at fsr.com> wrote:
In addition to the other responses, I should point out that it would seem you are making an assumption here, and one that I would wager is an incorrect one. Nowhere did Mr. Conor say he was delivering voice to the end-user via IP. Nowhere. In fact, I would take his language ("...we provided an analog POTS line...") to mean that as a CLEC, at least in these specific cases that he is talking about, he is ordering copper UNE-L from the ILEC and pumping dial-tone down it with his own switch. (I don't want to speak for him, though, and would welcome his correction.)
The only reason VoIP came up prior to this in the conversation was in order to give examples of things that others (including myself) have learned by experience can screw with a phone-based alarm panel's ability to communicate with the head-end. If ADT is not purposefully filtering out calls by doing real-time LRN lookups as calls come in (which I am sure they are NOT doing), then there must be something else in the path interfering with that communication. I offered my experience with DTMF problems over VoIP because I figured that it was possible that even if the last mile was not VoIP, somewhere between the switch that services his customer(s) and ADT's head-end MIGHT be IP-based transport, and perhaps the DTMF is getting massaged or mangled there.
-- Nathan Anderson First Step Internet, LLC nathana at fsr.com
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Thompson Sent: Friday, August 07, 2015 11:42 AM To: Colton Conor; voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
Alarm systems being serviced over VoIP are generally speaking a very bad idea. What are you supposed to do when and if the power fails? A UPS is only going to last for so long hours maybe. An analog CO line gets power from the wire and won?t go offline in the event of a natural or manmade disaster. The CO usually has a generator and guaranteed fuel delivery. By bringing VoIP into the mix your opening yourself up a huge liability if the alarm system fails due to your failure and someone gets burglarized, robbed, and worse injured or killed you?ll most likely be on the hook. Do yourself a favor and stay away from supporting it.
David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W) www.esi-estech.com
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops at voiceops.org Subject: [VoiceOps] ADT Alarms Special Dialing?
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?
On 08/10/2015 08:49 AM, Colton Conor wrote:
I wonder if it is detecting it as a fax, and trying to send it as T38 instead. Any ideas on what can and can't be disabled on the 5000?
Think of the TA5000 as a glorified GR303 or MGCP device. While it has some routing intelligence for SIP, it does NOT have RFC2833, T.38, or codecs other than g711u. Its audio stream cannot be reinvited to speak directly to a gateway, for example, it has to continue on the same path specified in the initial SDP. There's no knobs exposed because there's no settings to change. g711u, inband dtmf, no T.38, no reinvites. One sip peer (it shows you can have more than one, but creating a second doesn't work). If you have settings other than these on your softswitch, these may be part of your problem. -Paul
Paul, So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way? On Mon, Aug 10, 2015 at 12:32 PM, Paul Timmins <paul at timmins.net> wrote:
On 08/10/2015 08:49 AM, Colton Conor wrote:
I wonder if it is detecting it as a fax, and trying to send it as T38 instead. Any ideas on what can and can't be disabled on the 5000?
Think of the TA5000 as a glorified GR303 or MGCP device. While it has some routing intelligence for SIP, it does NOT have RFC2833, T.38, or codecs other than g711u. Its audio stream cannot be reinvited to speak directly to a gateway, for example, it has to continue on the same path specified in the initial SDP.
There's no knobs exposed because there's no settings to change. g711u, inband dtmf, no T.38, no reinvites. One sip peer (it shows you can have more than one, but creating a second doesn't work).
If you have settings other than these on your softswitch, these may be part of your problem.
-Paul
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 08/10/2015 06:36 PM, Colton Conor wrote:
Paul,
So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way?
Specific to the 5k. We have some older Zhone equipment that does T.38 and RFC-2833 and mid call re-invites just fine. It crashes the web interface hard when we try an MLT, but such is life. -Paul
Know anything about other vendors besides Adtran and Zhone? What about Calix and ALU? Do their POTs/Combo cards support T.38 and RFC-2833? On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins <paul at timmins.net> wrote:
On 08/10/2015 06:36 PM, Colton Conor wrote:
Paul,
So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way?
Specific to the 5k. We have some older Zhone equipment that does T.38 and RFC-2833 and mid call re-invites just fine. It crashes the web interface hard when we try an MLT, but such is life.
-Paul
Wait, weren't we talking about turning *off* both OOB DTMF (RFC2833) as well as T.38, because both protocol could potentially mess with either of the modulation schemes (DTMF and FSK, respecitvely) that ADT might use? If the Adtran 5000 does everything inband and you are doing PCM/uLaw audio end-to-end, it seems to me that looking to your MSAN for potential problems is a red herring. You said the TA5K is getting fed by a Broadsoft switch. How does the Broadsoft tie into the PSTN? If it's SIP trunks all the way down, how do you know that the Broadsoft (or even something upstream of it?whatever sits between it and something TDM) isn't trying to be clever and decode the in-band DTMF it gets from the TA5K and re-encode them as RFC2833 signals before passing them on? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com<mailto:nathana at fsr.com> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor Sent: Wednesday, August 26, 2015 7:27 PM To: Paul Timmins Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Know anything about other vendors besides Adtran and Zhone? What about Calix and ALU? Do their POTs/Combo cards support T.38 and RFC-2833? On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins <paul at timmins.net<mailto:paul at timmins.net>> wrote: On 08/10/2015 06:36 PM, Colton Conor wrote: Paul, So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way? Specific to the 5k. We have some older Zhone equipment that does T.38 and RFC-2833 and mid call re-invites just fine. It crashes the web interface hard when we try an MLT, but such is life. -Paul
Especially curious if that Broadsoft by chance is hooking to a Taqua T7000 running RFC2833 DTMF. I know of some bugs if so. -Paul
On Aug 27, 2015, at 00:22, Nathan Anderson <nathana at fsr.com> wrote:
Wait, weren't we talking about turning *off* both OOB DTMF (RFC2833) as well as T.38, because both protocol could potentially mess with either of the modulation schemes (DTMF and FSK, respecitvely) that ADT might use?
If the Adtran 5000 does everything inband and you are doing PCM/uLaw audio end-to-end, it seems to me that looking to your MSAN for potential problems is a red herring. You said the TA5K is getting fed by a Broadsoft switch. How does the Broadsoft tie into the PSTN? If it's SIP trunks all the way down, how do you know that the Broadsoft (or even something upstream of it?whatever sits between it and something TDM) isn't trying to be clever and decode the in-band DTMF it gets from the TA5K and re-encode them as RFC2833 signals before passing them on?
-- Nathan Anderson First Step Internet, LLC nathana at fsr.com <mailto:nathana at fsr.com>
From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor Sent: Wednesday, August 26, 2015 7:27 PM To: Paul Timmins Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
Know anything about other vendors besides Adtran and Zhone? What about Calix and ALU? Do their POTs/Combo cards support T.38 and RFC-2833?
On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins <paul at timmins.net <mailto:paul at timmins.net>> wrote: On 08/10/2015 06:36 PM, Colton Conor wrote: Paul,
So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way?
Specific to the 5k. We have some older Zhone equipment that does T.38 and RFC-2833 and mid call re-invites just fine. It crashes the web interface hard when we try an MLT, but such is life.
-Paul
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
Has anyone had an in depth conversation with any of these alarm vendors with what there move is going to be with everyone moving towards packet based voice switching which you can pretty much guarantee will break modems in general somewhere down the line. I just recently ran into an issue with an alarm line, where yes we do have some lines running on calix h.248 back to a meta switch and routed out to our tdm tandem trunks. Our first thought was to look into the QOS make sure things are set correctly ect, after days of testing we found that the call being terminated on the other side of the tandem had qos issues. I can only see these type of issue increasing as time passes. Thoughts? Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com<mailto:carlos at race.com> / http://www.race.com<http://www.race.com/> ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Paul Timmins <paul at timmins.net> Sent: Wednesday, August 26, 2015 9:42 PM To: Nathan Anderson Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Especially curious if that Broadsoft by chance is hooking to a Taqua T7000 running RFC2833 DTMF. I know of some bugs if so. -Paul On Aug 27, 2015, at 00:22, Nathan Anderson <nathana at fsr.com<mailto:nathana at fsr.com>> wrote: Wait, weren't we talking about turning *off* both OOB DTMF (RFC2833) as well as T.38, because both protocol could potentially mess with either of the modulation schemes (DTMF and FSK, respecitvely) that ADT might use? If the Adtran 5000 does everything inband and you are doing PCM/uLaw audio end-to-end, it seems to me that looking to your MSAN for potential problems is a red herring. You said the TA5K is getting fed by a Broadsoft switch. How does the Broadsoft tie into the PSTN? If it's SIP trunks all the way down, how do you know that the Broadsoft (or even something upstream of it...whatever sits between it and something TDM) isn't trying to be clever and decode the in-band DTMF it gets from the TA5K and re-encode them as RFC2833 signals before passing them on? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com<mailto:nathana at fsr.com> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor Sent: Wednesday, August 26, 2015 7:27 PM To: Paul Timmins Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Know anything about other vendors besides Adtran and Zhone? What about Calix and ALU? Do their POTs/Combo cards support T.38 and RFC-2833? On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins <paul at timmins.net<mailto:paul at timmins.net>> wrote: On 08/10/2015 06:36 PM, Colton Conor wrote: Paul, So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way? Specific to the 5k. We have some older Zhone equipment that does T.38 and RFC-2833 and mid call re-invites just fine. It crashes the web interface hard when we try an MLT, but such is life. -Paul _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
My personal thoughts are that any traditional alarm vendors that don't come out with a completely IP-based product are just going to end up getting smoked in the market. ADT is not "too big to fail" if they don't keep up with what the rest of the industry is doing. If they insist that potential and current customers of theirs maintain a POTS line just to receive service, with POTS (especially in residential) going the way of the Dodo, I think it inevitable that they will have their client base chipped away at by somebody else (or multiple somebody elses) that can deliver monitoring service over the internet, with customer premise equipment that has native Ethernet connectivity and an IP stack, etc. Such companies already exist. I don't think that ADT (yet) has such a product, although I am pretty sure that they do at least have a wireless/cellular module you can buy that replaces the POTS interface at the customer prem. So people who don't want to pay to maintain a POTS line for monitoring could go that route, but then you are paying for a dedicated wireless subscription that is monopolized by the monitoring system...at least with POTS you can share the line with the monitoring system and get more value out of it that way. -- Nathan From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alcantar Sent: Wednesday, August 26, 2015 10:33 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Has anyone had an in depth conversation with any of these alarm vendors with what there move is going to be with everyone moving towards packet based voice switching which you can pretty much guarantee will break modems in general somewhere down the line. I just recently ran into an issue with an alarm line, where yes we do have some lines running on calix h.248 back to a meta switch and routed out to our tdm tandem trunks. Our first thought was to look into the QOS make sure things are set correctly ect, after days of testing we found that the call being terminated on the other side of the tandem had qos issues. I can only see these type of issue increasing as time passes. Thoughts? Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com<mailto:carlos at race.com> / http://www.race.com<http://www.race.com/> ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> on behalf of Paul Timmins <paul at timmins.net<mailto:paul at timmins.net>> Sent: Wednesday, August 26, 2015 9:42 PM To: Nathan Anderson Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Especially curious if that Broadsoft by chance is hooking to a Taqua T7000 running RFC2833 DTMF. I know of some bugs if so. -Paul On Aug 27, 2015, at 00:22, Nathan Anderson <nathana at fsr.com<mailto:nathana at fsr.com>> wrote: Wait, weren't we talking about turning *off* both OOB DTMF (RFC2833) as well as T.38, because both protocol could potentially mess with either of the modulation schemes (DTMF and FSK, respecitvely) that ADT might use? If the Adtran 5000 does everything inband and you are doing PCM/uLaw audio end-to-end, it seems to me that looking to your MSAN for potential problems is a red herring. You said the TA5K is getting fed by a Broadsoft switch. How does the Broadsoft tie into the PSTN? If it's SIP trunks all the way down, how do you know that the Broadsoft (or even something upstream of it...whatever sits between it and something TDM) isn't trying to be clever and decode the in-band DTMF it gets from the TA5K and re-encode them as RFC2833 signals before passing them on? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com<mailto:nathana at fsr.com> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor Sent: Wednesday, August 26, 2015 7:27 PM To: Paul Timmins Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Know anything about other vendors besides Adtran and Zhone? What about Calix and ALU? Do their POTs/Combo cards support T.38 and RFC-2833? On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins <paul at timmins.net<mailto:paul at timmins.net>> wrote: On 08/10/2015 06:36 PM, Colton Conor wrote: Paul, So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way? Specific to the 5k. We have some older Zhone equipment that does T.38 and RFC-2833 and mid call re-invites just fine. It crashes the web interface hard when we try an MLT, but such is life. -Paul _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
Following my last e-mail, I started Googling around for internet-based alarm monitoring systems and found a handful of interesting options... https://www.irisbylowes.com/ http://www.lifeshield.com/services/monitoring/internet-option/ http://www.eyezon.com/?page_id=246) ...but I thought that THIS -- http://info.nextalarm.com/ -- was a paricularly clever option: an internet monitoring service that hooks up to your existing non-internet-aware system using a box that locally performs the modulation that your current system expects. It's like an ATA for your alarm system! And because it intercepts all of the dialing, etc. (which never actually happens, since this thing isn't actually digitizing an audio stream), it sounds like you don't even need to reprogram your panel to dial a different number...just plug it in and go, regardless of whether you are locked out of the panel programming by the original installer/monitoring company or not. Pretty genius. -- Nathan From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan Anderson Sent: Wednesday, August 26, 2015 11:11 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? My personal thoughts are that any traditional alarm vendors that don't come out with a completely IP-based product are just going to end up getting smoked in the market. ADT is not "too big to fail" if they don't keep up with what the rest of the industry is doing. If they insist that potential and current customers of theirs maintain a POTS line just to receive service, with POTS (especially in residential) going the way of the Dodo, I think it inevitable that they will have their client base chipped away at by somebody else (or multiple somebody elses) that can deliver monitoring service over the internet, with customer premise equipment that has native Ethernet connectivity and an IP stack, etc. Such companies already exist. I don't think that ADT (yet) has such a product, although I am pretty sure that they do at least have a wireless/cellular module you can buy that replaces the POTS interface at the customer prem. So people who don't want to pay to maintain a POTS line for monitoring could go that route, but then you are paying for a dedicated wireless subscription that is monopolized by the monitoring system...at least with POTS you can share the line with the monitoring system and get more value out of it that way. -- Nathan From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alcantar Sent: Wednesday, August 26, 2015 10:33 PM To: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Has anyone had an in depth conversation with any of these alarm vendors with what there move is going to be with everyone moving towards packet based voice switching which you can pretty much guarantee will break modems in general somewhere down the line. I just recently ran into an issue with an alarm line, where yes we do have some lines running on calix h.248 back to a meta switch and routed out to our tdm tandem trunks. Our first thought was to look into the QOS make sure things are set correctly ect, after days of testing we found that the call being terminated on the other side of the tandem had qos issues. I can only see these type of issue increasing as time passes. Thoughts? Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com<mailto:carlos at race.com> / http://www.race.com<http://www.race.com/> ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> on behalf of Paul Timmins <paul at timmins.net<mailto:paul at timmins.net>> Sent: Wednesday, August 26, 2015 9:42 PM To: Nathan Anderson Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Especially curious if that Broadsoft by chance is hooking to a Taqua T7000 running RFC2833 DTMF. I know of some bugs if so. -Paul On Aug 27, 2015, at 00:22, Nathan Anderson <nathana at fsr.com<mailto:nathana at fsr.com>> wrote: Wait, weren't we talking about turning *off* both OOB DTMF (RFC2833) as well as T.38, because both protocol could potentially mess with either of the modulation schemes (DTMF and FSK, respecitvely) that ADT might use? If the Adtran 5000 does everything inband and you are doing PCM/uLaw audio end-to-end, it seems to me that looking to your MSAN for potential problems is a red herring. You said the TA5K is getting fed by a Broadsoft switch. How does the Broadsoft tie into the PSTN? If it's SIP trunks all the way down, how do you know that the Broadsoft (or even something upstream of it...whatever sits between it and something TDM) isn't trying to be clever and decode the in-band DTMF it gets from the TA5K and re-encode them as RFC2833 signals before passing them on? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com<mailto:nathana at fsr.com> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Colton Conor Sent: Wednesday, August 26, 2015 7:27 PM To: Paul Timmins Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Know anything about other vendors besides Adtran and Zhone? What about Calix and ALU? Do their POTs/Combo cards support T.38 and RFC-2833? On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins <paul at timmins.net<mailto:paul at timmins.net>> wrote: On 08/10/2015 06:36 PM, Colton Conor wrote: Paul, So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way? Specific to the 5k. We have some older Zhone equipment that does T.38 and RFC-2833 and mid call re-invites just fine. It crashes the web interface hard when we try an MLT, but such is life. -Paul _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
I can't speak for nextalarms current product but a few years back it was a Linksys ATA with specific RFC2833 config pointing at their server, and you used the DTMF based ademco contact id protocol. They used to give you the URL to plug into your own box if you asked. Ironically I use them over POTS with them because my ip network won't last 24 hours without power like my alarm panel will. Hell, even if I replaced the UPS units I wouldn't get 20 minutes. Problem with IP based reporting is you just need to come by 20 minutes before you break into a house and snap the tag and pull the electric meter. Yeah, you can cut the phone line too but my alarm will get upset if you do that while its armed and alert the inside panels right away. A power outage for me would be unsurprising if I was away from home. On Aug 27, 2015 02:59, Nathan Anderson <nathana at fsr.com> wrote:
Following my last e-mail, I started Googling around for internet-based alarm monitoring systems and found a handful of interesting options...
?
http://www.lifeshield.com/services/monitoring/internet-option/
http://www.eyezon.com/?page_id=246)
?
...but I thought that THIS -- http://info.nextalarm.com/ -- was a paricularly clever option: an internet monitoring service that hooks up to your existing non-internet-aware system using a box that locally performs the modulation that your current system expects.? It's like an ATA for your alarm system!? And because it intercepts all of the dialing, etc. (which never actually happens, since this thing isn't actually digitizing an audio stream), it sounds like you don't even need to reprogram your panel to dial a different number...just plug it in and go, regardless of whether you are locked out of the panel programming by the original installer/monitoring company or not.? Pretty genius.
?
-- Nathan
?
From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan Anderson Sent: Wednesday, August 26, 2015 11:11 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
?
My personal thoughts are that any traditional alarm vendors that don't come out with a completely IP-based product are just going to end up getting smoked in the market.? ADT is not "too big to fail" if they don't keep up with what the rest of the industry is doing.? If they insist that potential and current customers of theirs maintain a POTS line just to receive service, with POTS (especially in residential) going the way of the Dodo, I think it inevitable that they will have their client base chipped away at by somebody else (or multiple somebody elses) that can deliver monitoring service over the internet, with customer premise equipment that has native Ethernet connectivity and an IP stack, etc.? Such companies already exist.
?
I don't think that ADT (yet) has such a product, although I am pretty sure that they do at least have a wireless/cellular module you can buy that replaces the POTS interface at the customer prem.? So people who don't want to pay to maintain a POTS line for monitoring could go that route, but then you are paying for a dedicated wireless subscription that is monopolized by the monitoring system?at least with POTS you can share the line with the monitoring system and get more value out of it that way.
?
-- Nathan
?
From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alcantar Sent: Wednesday, August 26, 2015 10:33 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
?
?
Has anyone had an in?depth conversation with any of these alarm vendors with what there move is going to be with everyone moving towards packet based voice switching which you can pretty much guarantee will break modems in general somewhere down the line. ?I just recently ran into an issue with an alarm line, where yes we do have some lines running on calix h.248 back to a meta switch and routed out to our tdm tandem trunks. ?Our first thought was to look into the QOS make sure things are set correctly ect, after days of testing we found that the call being terminated on the other side of the tandem had qos issues. ?I can only see these type of issue increasing as time passes. ?Thoughts?
?
?
Carlos Alcantar
Race Communications / Race Team Member?
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 /?carlos at race.com?/?http://www.race.com
?
?
________________________________
From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Paul Timmins <paul at timmins.net> Sent: Wednesday, August 26, 2015 9:42 PM To: Nathan Anderson Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
?
Especially curious if that Broadsoft by chance is hooking to a Taqua T7000 running RFC2833 DTMF.
?
I know of some bugs if so.
?
-Paul
?
?
On Aug 27, 2015, at 00:22, Nathan Anderson <nathana at fsr.com> wrote:
?
Wait, weren't we talking about turning *off* both OOB DTMF (RFC2833) as well as T.38, because both protocol could potentially mess with either of the modulation schemes (DTMF and FSK, respecitvely) that ADT might use?
?
If the Adtran 5000 does everything inband and you are doing PCM/uLaw audio end-to-end, it seems to me that looking to your MSAN for potential problems is a red herring.? You said the TA5K is getting fed by a Broadsoft switch.? How does the Broadsoft tie into the PSTN?? If it's SIP trunks all the way down, how do you know that the Broadsoft (or even something upstream of it?whatever sits between it and something TDM) isn't trying to be clever and decode the in-band DTMF it gets from the TA5K and re-encode them as RFC2833 signals before passing them on?
?
--
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com
?
From:?VoiceOps [mailto:voiceops-bounces at voiceops.org]?On Behalf Of?Colton Conor Sent:?Wednesday, August 26, 2015 7:27 PM To:?Paul Timmins Cc:?voiceops at voiceops.org Subject:?Re: [VoiceOps] ADT Alarms Special Dialing?
?
Know anything about other vendors besides Adtran and Zhone? What about Calix and ALU? Do their POTs/Combo cards support T.38 and RFC-2833??
?
On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins <paul at timmins.net> wrote:
On 08/10/2015 06:36 PM, Colton Conor wrote:
Paul,
So is this just a limitation of Adtran's implementation of SIP on the 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way?
Specific to the 5k. We have some older Zhone equipment that does T.38 and RFC-2833 and mid call re-invites just fine. It crashes the web interface hard when we try an MLT, but such is life.
-Paul
?
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
?
Nathan, That is a great question, and one I am trying to figure out now. We use a wholesale Broadsoft partition where our wholesale provider handles all the configuration and setup of the Broadsoft switch, so I am shooting in the dark here. I have no clue how they have the Adtran 5000 device profile setup on the switch, nor do I know how it should be setup. I checked on Broadsoft's website, and there is not a Adtran 5000 combo card config guide to use. I know the provider uses wholesale SIP trunks as well as TDM trunks into a Metaswitch. >From the sounds of it, there are not any setting I can possibly change on the Adtran since everything in Inband. So basically the way I see it I have two options: 1. Figure out what the correct settings should be on the Broadsoft side, and have my hosted provider change those settings. 2. Switch the Adtran 5000 out with another DSLAM vendor who's POTS and or DSL combo cards support the correct knobs and setting to make this work. However, it sounds like inband is the best anyways for DMTF for alarms, so I am not sure this will help since Adtran only supports inband already. However I do plan on switching access vendors soon anyways. I appreciate all the posts and replies both on and off list, but these are all NOT valid in this situation: 1. Using an ATA or device at the customer prem that works with alarm systems. Yes I know there are a million devices out there that can integrate with existing alarms and do this, but we are not an alarm provider. We are a telephone company. 2. Telling the customer that our POTS provided line doesn't work with their alarm (even though their line and number they just ported over from Verizon did). I am having a hard time telling the customer that Verizon's 1970's voice switch can support this, but we can't. 3. Telling the customer to cancel our POTS line and just use wireless and pay the cellular alarm company (though I agree for an alarm cellular is the way to go). One of the reasons they keep out DSL AND POTS is they want the POTS for their Alarm line, and to make occasional calls in emergency situations. 4. Selling the customer a ILEC POTS line. We don't want to give Verizon anymore money than we already are. On Wed, Aug 26, 2015 at 11:22 PM, Nathan Anderson <nathana at fsr.com> wrote: > Wait, weren't we talking about turning *off* both OOB DTMF (RFC2833) as > well as T.38, because both protocol could potentially mess with either of > the modulation schemes (DTMF and FSK, respecitvely) that ADT might use? > > > > If the Adtran 5000 does everything inband and you are doing PCM/uLaw audio > end-to-end, it seems to me that looking to your MSAN for potential problems > is a red herring. You said the TA5K is getting fed by a Broadsoft switch. > How does the Broadsoft tie into the PSTN? If it's SIP trunks all the way > down, how do you know that the Broadsoft (or even something upstream of > it?whatever sits between it and something TDM) isn't trying to be clever > and decode the in-band DTMF it gets from the TA5K and re-encode them as > RFC2833 signals before passing them on? > > > > -- > > Nathan Anderson > > First Step Internet, LLC > > nathana at fsr.com > > > > *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Colton > Conor > *Sent:* Wednesday, August 26, 2015 7:27 PM > *To:* Paul Timmins > *Cc:* voiceops at voiceops.org > *Subject:* Re: [VoiceOps] ADT Alarms Special Dialing? > > > > Know anything about other vendors besides Adtran and Zhone? What about > Calix and ALU? Do their POTs/Combo cards support T.38 and RFC-2833? > > > > On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins <paul at timmins.net> wrote: > > On 08/10/2015 06:36 PM, Colton Conor wrote: > > Paul, > > So is this just a limitation of Adtran's implementation of SIP on the > 5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the same > way? > > > Specific to the 5k. We have some older Zhone equipment that does T.38 and > RFC-2833 and mid call re-invites just fine. It crashes the web interface > hard when we try an MLT, but such is life. > > -Paul > > >
Colton Conor write:
However, it sounds like inband is the best anyways for DMTF for alarms, so I am not sure this will help since Adtran only supports inband already.
Yes, that was precisely my point: you don't need T.38 and RFC2833 support in your customer-facing switch, just so that you can go into the config and flip those settings off, because they are already "off" by virtue of *not existing*. :) I think we are getting far afield by concentrating on the TA5K at all. It is also (most likely) pointless to worry about how the peering between the TA5K and Broadsoft is configured on the Broadsoft side (short of a Broadsoft software bug or a very glaring configuration error) because since the TA5K cannot support either protocol, no session between the Broadsoft and the TA5K will ever successfully negotiate the use of those protocols. The TA5K will never generate or accept a T.38 INVITE, nor will it advertise RFC2833 support in the SDPs it sends to the Broadsoft. It's possible that if one side tries to initiate the use of one or the other that problems could arise of both sides do not deal with such a request gracefully, but I think that would be more likely to result in a complete call drop mid-call. (Do a packet capture, though, of an alarm monitoring session between the Adtran and the Broadsoft. It could be revealing.) So leave the Adtran out of it for now. The problem is most likely to be upstream. If you are getting your service provided to your Broadsoft via a telecom wholesaler, and that service is delivered to your Broadsoft via SIP, and then they themselves have both SIP and TDM peering with other providers, then the problem could be between your Broadsoft and them, or between them and the other providers they peer with via SIP. If I were a betting man, I'd put my money on the former. Again, you'd do best to capture multiple call legs of a live session. Have an alarm system make a call, and insert yourself both between the Adtran and the Broadsoft, and between the Broadsoft and your provider. Then check for the various things that have been talked about here (T.38 re-INVITE, advertisement of OOB DTMF by either party, transmission of OOB DTMF on either leg of the call regardless of whether it was successfully negotiated during call set-up, etc.) If any of these guesses were right on the money, you should be able to spot the culprit pretty fast. After you figure out *where* it is happening, only then can you devise a plan of attack. -- Nathan
David, Most of us have inside or outside counsel that make sure our service agreements protect us from such things ? Frank From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Thompson Sent: Friday, August 07, 2015 1:42 PM To: Colton Conor <colton.conor at gmail.com>; voiceops at voiceops.org Subject: Re: [VoiceOps] ADT Alarms Special Dialing? Alarm systems being serviced over VoIP are generally speaking a very bad idea. What are you supposed to do when and if the power fails? A UPS is only going to last for so long hours maybe. An analog CO line gets power from the wire and won?t go offline in the event of a natural or manmade disaster. The CO usually has a generator and guaranteed fuel delivery. By bringing VoIP into the mix your opening yourself up a huge liability if the alarm system fails due to your failure and someone gets burglarized, robbed, and worse injured or killed you?ll most likely be on the hook. Do yourself a favor and stay away from supporting it. David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com <mailto:dthompson at esi-estech.com> (W) www.esi-estech.com <http://www.esi-estech.com> From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org> ] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: [VoiceOps] ADT Alarms Special Dialing? 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?
participants (9)
-
carlos＠race.com -
colton.conor＠gmail.com -
dthompson＠esi-estech.com -
frnkblk＠iname.com -
gb20090101＠gmail.com -
LRiemer＠bestline.net -
nathana＠fsr.com -
paul＠timmins.net -
rdawson＠force3.com