Re: [VoiceOps] ADT Alarms Special Dialing?
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 ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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 nath...@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 nath...@fsr.com *From:* VoiceOps [mailto:voiceops-boun...@voiceops.org] *On Behalf Of *Colton Conor *Sent:* Wednesday, August 26, 2015 7:27 PM *To:* Paul Timmins *Cc:* voiceops@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 p...@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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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-boun...@voiceops.org] On Behalf Of Carlos Alcantar Sent: Wednesday, August 26, 2015 10:33 PM To: voiceops@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 / car...@race.commailto:car...@race.com / http://www.race.comhttp://www.race.com/ From: VoiceOps voiceops-boun...@voiceops.orgmailto:voiceops-boun...@voiceops.org on behalf of Paul Timmins p...@timmins.netmailto:p...@timmins.net Sent: Wednesday, August 26, 2015 9:42 PM To: Nathan Anderson Cc: voiceops@voiceops.orgmailto:voiceops@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 nath...@fsr.commailto:nath...@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 nath...@fsr.commailto:nath...@fsr.com From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Wednesday, August 26, 2015 7:27 PM To: Paul Timmins Cc: voiceops@voiceops.orgmailto:voiceops@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 p...@timmins.netmailto:p...@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@voiceops.orgmailto:VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https
Re: [VoiceOps] ADT Alarms Special Dialing?
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-boun...@voiceops.org] On Behalf Of Nathan Anderson Sent: Wednesday, August 26, 2015 11:11 PM To: voiceops@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-boun...@voiceops.org] On Behalf Of Carlos Alcantar Sent: Wednesday, August 26, 2015 10:33 PM To: voiceops@voiceops.orgmailto:voiceops@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 / car...@race.commailto:car...@race.com / http://www.race.comhttp://www.race.com/ From: VoiceOps voiceops-boun...@voiceops.orgmailto:voiceops-boun...@voiceops.org on behalf of Paul Timmins p...@timmins.netmailto:p...@timmins.net Sent: Wednesday, August 26, 2015 9:42 PM To: Nathan Anderson Cc: voiceops@voiceops.orgmailto:voiceops@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 nath...@fsr.commailto:nath...@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
Re: [VoiceOps] ADT Alarms Special Dialing?
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 nath...@fsr.commailto:nath...@fsr.com From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Wednesday, August 26, 2015 7:27 PM To: Paul Timmins Cc: voiceops@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 p...@timmins.netmailto:p...@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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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 nath...@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 nath...@fsr.com mailto:nath...@fsr.com From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Wednesday, August 26, 2015 7:27 PM To: Paul Timmins Cc: voiceops@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 p...@timmins.net mailto:p...@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@voiceops.org mailto:VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
I've seen a lot of things go sideways over my 30+ years in this business. Put the alarms on a re-sold POTS line from the LEC and call it a day. Anything other than this is placing your customer and your company at risk. If, by chance, the line goes dead... you have done all that could have been done with today's technology. If you choose another route, and the service fails, you are risking it all on someone's interpretation of a contract /or law. Kidd On Mon, Aug 10, 2015 at 8:10 AM, Pawlowski, Adam aj...@buffalo.edu wrote: All, I appreciate the insight into this with regard to alarms, especially that they'd trip up T.38, which will probably save me some time in the future. So far so good on alarms and credit card machines, but I'd run into some older CPE type Cisco VG that would mangle and eat modem calls no matter what we did with it. Is there a compendium of information anywhere regarding devices, signaling, and compatibility with CPE? One of our alarm monitoring companies just said that many of their older (FBI type) panels don't work via VoIP in their experience, but other than previously mentioned sensitivity to DTMF it should be possible. Liability and service performance aside, just speaking technically. Also, regarding Sandy and FiOS customers - it was quite a hot topic for a while that the flooding had absolutely trashed the copper plant in a number of areas. Leaded cables with cracked jacket, or enclosures with long-failed positive pressure had allowed water in and ruined the copper. While that's not your run of the mill power or service outage, I'm not entirely certain you can count on a wireline provider to provide longevity of CO battery over time, or even that you're not connected through some span/regen that is independently powered. It certainly helps piece of mind to move the failure somewhere else than where you happen to be, but I can't believe it would be as granite-tough reliable as commonly thought. Regards, Adam Pawlowski University at Buffalo ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops -- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
Many of you don't seem to understand that the technology is equivalent security and power wise to what the ILEC is providing. We are not going to resell ILEC POTS lines. We want to make our own POTS lines work with alarm panels. This is for residential customers not business. On Mon, Aug 10, 2015 at 10:14 AM, Kidd Filby kiddfi...@gmail.com wrote: I've seen a lot of things go sideways over my 30+ years in this business. Put the alarms on a re-sold POTS line from the LEC and call it a day. Anything other than this is placing your customer and your company at risk. If, by chance, the line goes dead... you have done all that could have been done with today's technology. If you choose another route, and the service fails, you are risking it all on someone's interpretation of a contract /or law. Kidd On Mon, Aug 10, 2015 at 8:10 AM, Pawlowski, Adam aj...@buffalo.edu wrote: All, I appreciate the insight into this with regard to alarms, especially that they'd trip up T.38, which will probably save me some time in the future. So far so good on alarms and credit card machines, but I'd run into some older CPE type Cisco VG that would mangle and eat modem calls no matter what we did with it. Is there a compendium of information anywhere regarding devices, signaling, and compatibility with CPE? One of our alarm monitoring companies just said that many of their older (FBI type) panels don't work via VoIP in their experience, but other than previously mentioned sensitivity to DTMF it should be possible. Liability and service performance aside, just speaking technically. Also, regarding Sandy and FiOS customers - it was quite a hot topic for a while that the flooding had absolutely trashed the copper plant in a number of areas. Leaded cables with cracked jacket, or enclosures with long-failed positive pressure had allowed water in and ruined the copper. While that's not your run of the mill power or service outage, I'm not entirely certain you can count on a wireline provider to provide longevity of CO battery over time, or even that you're not connected through some span/regen that is independently powered. It certainly helps piece of mind to move the failure somewhere else than where you happen to be, but I can't believe it would be as granite-tough reliable as commonly thought. Regards, Adam Pawlowski University at Buffalo ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops -- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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 p...@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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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 nath...@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 nath...@fsr.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of David Thompson Sent: Friday, August 07, 2015 11:42 AM To: Colton Conor; voiceops@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) dthomp...@esi-estech.com (W) www.esi-estech.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops@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
Re: [VoiceOps] ADT Alarms Special Dialing?
All, I appreciate the insight into this with regard to alarms, especially that they'd trip up T.38, which will probably save me some time in the future. So far so good on alarms and credit card machines, but I'd run into some older CPE type Cisco VG that would mangle and eat modem calls no matter what we did with it. Is there a compendium of information anywhere regarding devices, signaling, and compatibility with CPE? One of our alarm monitoring companies just said that many of their older (FBI type) panels don't work via VoIP in their experience, but other than previously mentioned sensitivity to DTMF it should be possible. Liability and service performance aside, just speaking technically. Also, regarding Sandy and FiOS customers - it was quite a hot topic for a while that the flooding had absolutely trashed the copper plant in a number of areas. Leaded cables with cracked jacket, or enclosures with long-failed positive pressure had allowed water in and ruined the copper. While that's not your run of the mill power or service outage, I'm not entirely certain you can count on a wireline provider to provide longevity of CO battery over time, or even that you're not connected through some span/regen that is independently powered. It certainly helps piece of mind to move the failure somewhere else than where you happen to be, but I can't believe it would be as granite-tough reliable as commonly thought. Regards, Adam Pawlowski University at Buffalo ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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-boun...@voiceops.org] On Behalf Of David Thompson Sent: Friday, August 07, 2015 1:42 PM To: Colton Conor colton.co...@gmail.com; voiceops@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) dthomp...@esi-estech.com mailto:dthomp...@esi-estech.com (W) www.esi-estech.com http://www.esi-estech.com From: VoiceOps [mailto:voiceops-boun...@voiceops.org mailto:voiceops-boun...@voiceops.org ] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops@voiceops.org mailto:voiceops@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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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 nath...@fsr.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of David Thompson Sent: Friday, August 07, 2015 11:42 AM To: Colton Conor; voiceops@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) dthomp...@esi-estech.com (W) www.esi-estech.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops@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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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-boun...@voiceops.org] On Behalf Of Paul Timmins Sent: Thursday, August 06, 2015 8:35 PM To: voiceops@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 nath...@fsr.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 4:30 PM To: voiceops@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
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) dthomp...@esi-estech.com (W) www.esi-estech.com *From:* VoiceOps [mailto:voiceops-boun...@voiceops.org] *On Behalf Of *Colton Conor *Sent:* Thursday, August 06, 2015 6:21 PM *To:* voiceops@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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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). ATT 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) dthomp...@esi-estech.com mailto:dthomp...@esi-estech.com (W) www.esi-estech.com http://www.esi-estech.com *From:*VoiceOps [mailto:voiceops-boun...@voiceops.org mailto:voiceops-boun...@voiceops.org] *On Behalf Of *Colton Conor *Sent:* Thursday, August 06, 2015 6:21 PM *To:* voiceops@voiceops.org mailto:voiceops@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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 8:55 PM To: Nathan Anderson; Jay Hennigan Cc: voiceops@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 nath...@fsr.commailto:nath...@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 nath...@fsr.commailto:nath...@fsr.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.orgmailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 4:30 PM To: voiceops@voiceops.orgmailto:voiceops@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
Re: [VoiceOps] ADT Alarms Special Dialing?
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-boun...@voiceops.org] On Behalf Of Rob Dawson Sent: Friday, August 07, 2015 8:37 AM To: Paul Timmins; voiceops@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-boun...@voiceops.org] On Behalf Of Paul Timmins Sent: Thursday, August 06, 2015 8:35 PM To: voiceops@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 nath...@fsr.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 4:30 PM To: voiceops@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
Re: [VoiceOps] ADT Alarms Special Dialing?
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 dthomp...@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) dthomp...@esi-estech.com mailto:dthomp...@esi-estech.com (W) www.esi-estech.com http://www.esi-estech.com/ From: VoiceOps [mailto:voiceops-boun...@voiceops.org mailto:voiceops-boun...@voiceops.org] On Behalf Of GregoryB Sent: Friday, August 07, 2015 2:01 PM To: voiceops@voiceops.org mailto:voiceops@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 dthomp...@esi-estech.com mailto:dthomp...@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) dthomp...@esi-estech.com mailto:dthomp...@esi-estech.com (W) www.esi-estech.com http://www.esi-estech.com/ From: VoiceOps [mailto:voiceops-boun...@voiceops.org mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 6:21 PM To: voiceops@voiceops.org mailto:voiceops@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@voiceops.org mailto:VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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.co...@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 nath...@fsr.com mailto:nath...@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 nath...@fsr.com mailto:nath...@fsr.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 4:30 PM To: voiceops@voiceops.org mailto:voiceops@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
[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@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] ADT Alarms Special Dialing?
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-boun...@voiceops.org] On Behalf Of Paul Timmins Sent: Thursday, August 06, 2015 5:35 PM To: voiceops@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 nath...@fsr.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 4:30 PM To: voiceops@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
Re: [VoiceOps] ADT Alarms Special Dialing?
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 nath...@fsr.com -Original Message- From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor Sent: Thursday, August 06, 2015 4:30 PM To: voiceops@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.co...@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
