Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue
Hello All, I guess I have an old school question for the list. The question is we are having trouble with alarm panels dialing and our gear collecting the DTMF digits properly. Only from a company ran by a single alarm panel guy who is not terribly helpful. At least 7 different sites are having the same problem on different copper pairs/T1s. Different gear. Etc... It seems we are always migrating off old DMS switches. In this case a DMS 100 with your typical line drawers with cards in them for pots lines or GR303 groups. We are migrating to a Metaswitch using different types of connections. In this case GR303 for some and SIP for others. ADTRAN gear in this case. TA4303 and a TA5000. We have been a Metaswitch shop for quite a long time now. Pretty vanilla stuff we rely on in many regions that has always "just worked" for legacy clients. Metaswitch -> GR303 to a TA4303 -> drop T1 to a TA3000 -> build a T1 on our copper plant -> Smart jack -> TA750 at customer location -> customer fire alarm panel Or... Metaswitch -> SIP -> TA5k with RPOTS cards in SIP mode -> copper plant -> demarc -> customer fire alarm panel What I am seeing is that the DMS was collecting the digits properly before the cutover. Yet our migrated to setup is having trouble. We see missing digits in most cases or other oddities. It does appear the alarm panels are dialing within DTMF specs. Duration of the DTMF is approx 95 ms. A DTMF signal separated by a 150-200 ms pause. Any other type of customer is working flawlessly. 100s and 100s of pots line migrated with no complaints except a single guy who manages fire alarm panels of a few different types. "Contact id Edwards". " Contact id ES4 Kidde". Naturally, a tech sent on site can dial out fine with his butt set. The copper pairs test fine. T1 is error free. Hardware has been swapped out. Moved to different fxs ports. You name it we probably tried it. Does anyone have a suggestion what could be the cause for this? Something I am not aware of DMS wise when it came to fire alarm panels? Some change that can be adjusted in the fire panel configuration that might solve this? When we port/move the customer back to the DMS it just starts working again in the case of the TA5000. There is no going back for the GR303 subs which were moved all at once. Any tips are welcome! Thank you, Matt
On 2/13/23 11:15, Matthew Yaklin via VoiceOps wrote:
Hello All,
I guess I have an old school question for the list. The question is we are having trouble with alarm panels dialing and our gear collecting the DTMF digits properly. Only from a company ran by a single alarm panel guy who is not terribly helpful. At least 7 different sites are having the same problem on different copper pairs/T1s. Different gear. Etc...
Is the issue that the alarm panels can't complete a call to the central monitor, or do they ring in OK and then cant pass DTMF inband once connected to communicate the nature of the alarm? Alarm panels are essentially a form of modem. You might turn on modem passthrough and ensure that your codecs are forced to G.711. Other codecs don't play well with modem-like applications. If the DTMF digits used to set up the call are failing, then there's likely something out of spec with the DTMF encoders in the alarm panels, frequency or twist. Or something different in the call setup like a leading 9 for a PBX that no longer exists. What does the sending Adtran show for the dialed digits on the call? Got a Sage 930A gathering dust on a shelf? Using VoIP or anything that requires local power for fire alarms in general is another topic. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
Jay beat me too it. Force G.711 and set packetization to 10ms if you can. Also, try in-band audio. Some older alarm panels don't work well with NTE 101. Adtran's don't always pickup every DTMF tone which can result in missing or doubled DTMF tones. At the end of the day, I would urge the customer to put the fire alarms on cellular communicators. We constantly fight with signals over phone lines. Even if you get it working on your side today, that doesn't mean it will work a month from now if one of your carriers makes a change and backhauls over SIP using a different codec. Thanks, Mike -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Jay Hennigan via VoiceOps Sent: Monday, February 13, 2023 2:30 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 2/13/23 11:15, Matthew Yaklin via VoiceOps wrote:
Hello All,
I guess I have an old school question for the list. The question is we are having trouble with alarm panels dialing and our gear collecting the DTMF digits properly. Only from a company ran by a single alarm panel guy who is not terribly helpful. At least 7 different sites are having the same problem on different copper pairs/T1s. Different gear. Etc...
Is the issue that the alarm panels can't complete a call to the central monitor, or do they ring in OK and then cant pass DTMF inband once connected to communicate the nature of the alarm? Alarm panels are essentially a form of modem. You might turn on modem passthrough and ensure that your codecs are forced to G.711. Other codecs don't play well with modem-like applications. If the DTMF digits used to set up the call are failing, then there's likely something out of spec with the DTMF encoders in the alarm panels, frequency or twist. Or something different in the call setup like a leading 9 for a PBX that no longer exists. What does the sending Adtran show for the dialed digits on the call? Got a Sage 930A gathering dust on a shelf? Using VoIP or anything that requires local power for fire alarms in general is another topic. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops IMPORTANT NOTICE: This e-mail message is intended to be received only by persons entitled to receive the confidential information it may contain. E-mail messages to clients of Holmes Security Systems may contain information that is confidential and legally privileged. Please do not read, copy, forward, or store this message unless you are an intended recipient of it. If you have received this message in error, please forward it to the sender and delete it completely from your computer system.
Jay beat me too it. Force G.711 and set packetization to 10ms if you can. Also, try in-band audio. Some older alarm panels don't work well with NTE 101. Adtran's don't always pickup every DTMF tone which can result in missing or doubled DTMF tones. --- The problem is happening before SIP is involved or in the case of GR303 there is no SIP unless sent out IQNT for example. But if that takes place that means we collected the digits properly. At the end of the day, I would urge the customer to put the fire alarms on cellular communicators. We constantly fight with signals over phone lines. Even if you get it working on your side today, that doesn't mean it will work a month from now if one of your carriers makes a change and backhauls over SIP using a different codec. --- I am afraid we have almost reached the point where we will fire the customer. Have them choose a different vendor as their only response to us is that it worked on the DMS 100 and now it does not. While I agree with that I cannot seem to get any information from them on possible changes they can make in the alarm panel or share documentation on it so I can read up. --- It is almost like this small localized region had fire alarm panels setup in a unique way compared to the 100s and 100s of other alarm panels we serve throughout New England. Matt Thanks, Mike -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Jay Hennigan via VoiceOps Sent: Monday, February 13, 2023 2:30 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 2/13/23 11:15, Matthew Yaklin via VoiceOps wrote:
Hello All,
I guess I have an old school question for the list. The question is we are having trouble with alarm panels dialing and our gear collecting the DTMF digits properly. Only from a company ran by a single alarm panel guy who is not terribly helpful. At least 7 different sites are having the same problem on different copper pairs/T1s. Different gear. Etc...
Is the issue that the alarm panels can't complete a call to the central monitor, or do they ring in OK and then cant pass DTMF inband once connected to communicate the nature of the alarm? Alarm panels are essentially a form of modem. You might turn on modem passthrough and ensure that your codecs are forced to G.711. Other codecs don't play well with modem-like applications. If the DTMF digits used to set up the call are failing, then there's likely something out of spec with the DTMF encoders in the alarm panels, frequency or twist. Or something different in the call setup like a leading 9 for a PBX that no longer exists. What does the sending Adtran show for the dialed digits on the call? Got a Sage 930A gathering dust on a shelf? Using VoIP or anything that requires local power for fire alarms in general is another topic. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops IMPORTANT NOTICE: This e-mail message is intended to be received only by persons entitled to receive the confidential information it may contain. E-mail messages to clients of Holmes Security Systems may contain information that is confidential and legally privileged. Please do not read, copy, forward, or store this message unless you are an intended recipient of it. If you have received this message in error, please forward it to the sender and delete it completely from your computer system. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 2/13/23 11:15, Matthew Yaklin via VoiceOps wrote:
Hello All,
I guess I have an old school question for the list. The question is we are having trouble with alarm panels dialing and our gear collecting the DTMF digits properly. Only from a company ran by a single alarm panel guy who is not terribly helpful. At least 7 different sites are having the same problem on different copper pairs/T1s. Different gear. Etc...
Is the issue that the alarm panels can't complete a call to the central monitor, or do they ring in OK and then cant pass DTMF inband once connected to communicate the nature of the alarm? --- The issue is that when the alarm panel dials the INVITE from the TA5k does not contain the correct digits dialed. A couple of digits are missing for example. Sometimes a call does manage to squeak through properly. If the digits do get to the Metaswitch properly the call completes fine. Same exact symptom with GR303. In SAS (meta's service assurance server that contains debug output) I can clearly review what digits reach the metaswitch via GR303. In this case I will see missing digits as I know the number the alarm panel is supposed to dial and a gap of time which should have contained digits. --- So this is not an INBAND issue when the call is active or a SIP issue. It is truly a problem of collecting the DTMF digits to dial a number. Nothing SIP related is taking place yet. The TA5k does not send the INVITE until the dialing-plan in the config says it collected enough digits or it times out. Alarm panels are essentially a form of modem. You might turn on modem passthrough and ensure that your codecs are forced to G.711. Other codecs don't play well with modem-like applications. --- TA5k is G711 only but per the above collecting DTMF on it happens before the first INVITE. GR303 is no SIP at all to the metaswitch yet same symptoms. If the DTMF digits used to set up the call are failing, then there's likely something out of spec with the DTMF encoders in the alarm panels, frequency or twist. Or something different in the call setup like a leading 9 for a PBX that no longer exists. What does the sending Adtran show for the dialed digits on the call? --- A leading 9 is not the issue but the other things you mentioned seem relevant. I just cannot figure out why the DMS 100 is able to gather the digits so reliably over GR303 yet the Metaswitch is struggling. Let alone the TA5k situation. This gear is pretty industry standard now days. --- On the TA5k we tried changing the impedance. The rx/tx-gain. There is truly not much to adjust on the TA5k because these are RPOTS cards. We also had ADTRAN review our config which according to them is quite fine and vanilla. --- It really does seem like the fire alarm panel sends a DTMF 95 ms duration digit and it just never gets "detected" by the TA5k or Metaswitch over GR303. Got a Sage 930A gathering dust on a shelf? --- Sadly no. Using VoIP or anything that requires local power for fire alarms in general is another topic. --- The TA5k is only a SIP backhaul. Normal pots to the customers. No local power. As for the TA750 example that has battery backup but yea... another topic. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
If the DTMF digits used to set up the call are failing, then there's likely something out of spec with the DTMF encoders in the alarm panels, frequency or twist. Or something different in the call setup like a leading 9 for a PBX that no longer exists. What does the sending Adtran show for the dialed digits on the call? --- An example would be the fire alarm panel should dial 877-386-4923. Yet we collect the digits on the Metaswitch as 877-38923. That is it. The 6 and 4 are missing. The Metaswitch dial-plan times out and it tries to process those digits and the call fails. There is a gap of time of approx 600 ms where the Metaswitch does not collect anything and according to the time pattern should have been the 6 and 4. On top of that this is over GR303 with no SIP involved. Good old fashioned analog pots lines with TDM T1 circuits to the Metaswitch. Very old fashioned. Also in this example the TA750 channel bank is located at the customer premise with the alarm panel only 300 feet away. --- It is truly a mystery to me. Short of using specialized gear and spending countless hours to find the blame I am out of ideas. This very same setup works for many other fire alarm panels. The gear used to provide the clients pots lines is the same exact gear that used to be hooked up to the DMS 100. We just configured a gr303 sub on the meta, built new gr303 T1s to the TA4303 from the meta, and ported the TN. Nothing else changed. I have done this type of migration for tens of thousands of pots lines from a DMS to the meta. First time I ran into this over all these years. Matt
On 2/13/23 11:48, Matthew Yaklin wrote:
--- The issue is that when the alarm panel dials the INVITE from the TA5k does not contain the correct digits dialed. A couple of digits are missing for example. Sometimes a call does manage to squeak through properly. If the digits do get to the Metaswitch properly the call completes fine. Same exact symptom with GR303. In SAS (meta's service assurance server that contains debug output) I can clearly review what digits reach the metaswitch via GR303. In this case I will see missing digits as I know the number the alarm panel is supposed to dial and a gap of time which should have contained digits.
OK, so the FXS port of the local Adtran device isn't reliably decoding the DTMF from the panel. Could be frequency, level, or twist. See if there are knobs for receive level and/or impedance for the specific line port used by the panel. I'd start with level, bump it up and down 3dB at a time and see if it starts decoding reliably. If possible bracket it to see where it fails again and set it in the middle. Changing impedance might help if it's twist. Sometimes the options include series capacitance. Likely going to be trial-and-error. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
I wouldn't be surprised if you were seeing it try to dial DTMF, then pulse, then DTMF again if the call didn't cut through very quickly. I saw this with some fire panels that I was connected to once upon a time - they'd dial 7 digits, the adtran was configured to cut through on 10 digits or to give a post dial delay waiting for additional digit collection, and that took more than 3 seconds to fully connect so the panel would give up, hang up, and try pulse dial. Then it would hang up, try DTMF again, then hang up and try pulse again. Then it would fault and evacuate the school. Needless to say, that was an awkward call to show up on at an inner city charter school, pulling up to greet a bunch of evacuated students and an annoyed fireman who stuck around in a fly car just to give the all clear. Setting the adtran to 7 digit dialing cleared the issue, fwiw. That was on the TA900 series, but maybe something similar is happening here? -Paul
On Feb 13, 2023, at 3:47 PM, Jay Hennigan via VoiceOps <voiceops at voiceops.org> wrote:
On 2/13/23 11:48, Matthew Yaklin wrote:
--- The issue is that when the alarm panel dials the INVITE from the TA5k does not contain the correct digits dialed. A couple of digits are missing for example. Sometimes a call does manage to squeak through properly. If the digits do get to the Metaswitch properly the call completes fine. Same exact symptom with GR303. In SAS (meta's service assurance server that contains debug output) I can clearly review what digits reach the metaswitch via GR303. In this case I will see missing digits as I know the number the alarm panel is supposed to dial and a gap of time which should have contained digits.
OK, so the FXS port of the local Adtran device isn't reliably decoding the DTMF from the panel. Could be frequency, level, or twist. See if there are knobs for receive level and/or impedance for the specific line port used by the panel. I'd start with level, bump it up and down 3dB at a time and see if it starts decoding reliably. If possible bracket it to see where it fails again and set it in the middle.
Changing impedance might help if it's twist. Sometimes the options include series capacitance. Likely going to be trial-and-error.
-- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I wouldn't be surprised if you were seeing it try to dial DTMF, then pulse, then DTMF again if the call didn't cut through very quickly.
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper. ----- My last hopeful attempt is that ADTRAN appears to have engineering superuser temporary passwords for the TA5000 that can see things I cannot. So I have to get a test scheduled with them. I had a tech out at a GR303/TA750 site today and no matter what we tried those two digits in my previous example were always missing. ----- I just need to motivate people to keep working this as people above us said why are we spending this much time on a dozen pots lines and the alarm vendor is difficult to work with. They can go to Verizon or get that cell phone setup for alarm panels. Killing off a DMS switch is a big savings and each month costs $$$.
On Feb 13, 2023, at 3:47 PM, Jay Hennigan via VoiceOps <voiceops at voiceops.org> wrote:
On 2/13/23 11:48, Matthew Yaklin wrote:
--- The issue is that when the alarm panel dials the INVITE from the TA5k does not contain the correct digits dialed. A couple of digits are missing for example. Sometimes a call does manage to squeak through properly. If the digits do get to the Metaswitch properly the call completes fine. Same exact symptom with GR303. In SAS (meta's service assurance server that contains debug output) I can clearly review what digits reach the metaswitch via GR303. In this case I will see missing digits as I know the number the alarm panel is supposed to dial and a gap of time which should have contained digits.
OK, so the FXS port of the local Adtran device isn't reliably decoding the DTMF from the panel. Could be frequency, level, or twist. See if there are knobs for receive level and/or impedance for the specific line port used by the panel. I'd start with level, bump it up and down 3dB at a time and see if it starts decoding reliably. If possible bracket it to see where it fails again and set it in the middle.
Changing impedance might help if it's twist. Sometimes the options include series capacitance. Likely going to be trial-and-error.
-- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
_______________________________________________ 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
On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it. Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
Ok this is a bodge... but if it always dials the same number, and its dialing it has an issue with, set it up as a PLAR line? As soon as goes to dial just dial the number for it, and leave it to send or not send which ever digits of the number it wants....? Its not perfect, the customer needs to know you need to know if the alarm panel people ever change the number, but would get it working? On Mon, 13 Feb 2023 at 21:29, Jay Hennigan via VoiceOps < voiceops at voiceops.org> wrote:
On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it.
Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec.
-- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Ok this is a bodge... but if it always dials the same number, and its dialing it has an issue with, set it up as a PLAR line? As soon as goes to dial just dial the number for it, and leave it to send or not send which ever digits of the number it wants....? Its not perfect, the customer needs to know you need to know if the alarm panel people ever change the number, but would get it working?
---- To keep our discussion simple, I gave the most common error case which is missing digits. There are variations to the issue and I doubt that would be feasible on a dozen lines when the error can vary slightly depending on the factors causing the problem. Sometimes it can be two missing digits. Sometimes it can dial properly in some pots examples. Next time it dials something else is missing. ---- As times goes on the company has lost a lot of the copper knowledge we used to have. A lot of old school CO techs are retired. I relied on turnstones and other central office gear to test copper pairs. T1s are easy. This is getting into the nitty gritty realm of pots lines that normally I can figure out with research but this is an odd one. ---- Like I mentioned. I will send an email shortly to all the relevant parties that getting an ADTRAN eng on the line to use those superuser temp passwords is my last real chance to solve this short of using suggestions people made here about getting specialized gear and checking the specs of what things are doing. Even if we did prove the old fire alarm panels are doing something wrong ?it worked on the DMS? will be said back to us. End result is the same. Go find a different provider. ---- I am just annoyed I have a problem and I cannot seem to figure it out. I don?t like the taste of it at all. Matt Matt On Mon, 13 Feb 2023 at 21:29, Jay Hennigan via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> wrote: On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it. Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec. -- Jay Hennigan - jay at west.net<mailto:jay at west.net> Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
But if the issue is always at dial time, and never at reporting time, it seems like a PLAR would indeed solve it...? -- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering On Mon, Feb 13, 2023 at 3:48 PM Matthew Yaklin via VoiceOps < voiceops at voiceops.org> wrote:
Ok this is a bodge... but if it always dials the same number, and its dialing it has an issue with, set it up as a PLAR line? As soon as goes to dial just dial the number for it, and leave it to send or not send which ever digits of the number it wants....? Its not perfect, the customer needs to know you need to know if the alarm panel people ever change the number, but would get it working?
---- To keep our discussion simple, I gave the most common error case which is missing digits. There are variations to the issue and I doubt that would be feasible on a dozen lines when the error can vary slightly depending on the factors causing the problem. Sometimes it can be two missing digits. Sometimes it can dial properly in some pots examples. Next time it dials something else is missing.
---- As times goes on the company has lost a lot of the copper knowledge we used to have. A lot of old school CO techs are retired. I relied on turnstones and other central office gear to test copper pairs. T1s are easy. This is getting into the nitty gritty realm of pots lines that normally I can figure out with research but this is an odd one.
---- Like I mentioned. I will send an email shortly to all the relevant parties that getting an ADTRAN eng on the line to use those superuser temp passwords is my last real chance to solve this short of using suggestions people made here about getting specialized gear and checking the specs of what things are doing. Even if we did prove the old fire alarm panels are doing something wrong ?it worked on the DMS? will be said back to us. End result is the same. Go find a different provider.
---- I am just annoyed I have a problem and I cannot seem to figure it out. I don?t like the taste of it at all.
Matt
Matt
On Mon, 13 Feb 2023 at 21:29, Jay Hennigan via VoiceOps < voiceops at voiceops.org> wrote:
On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it.
Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec.
-- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
_______________________________________________ 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
But if the issue is always at dial time, and never at reporting time, it seems like a PLAR would indeed solve it...?
---- Sorry Hunter. I should have googled what a PLAR was. I am not used to that acronym. Basically, a hotline. Pick up the line it dials a specific number. I was thinking digit manipulation for some reason. ----- Normally a fire alarm panel has two lines plugged into it. It can be programmed with multiple numbers it tries to dial. If one line is down or the number it dialed is busy it will try the other line or another number. ----- I am not sure if that would be allowed. I think in the case of a fire alarm panel it has to work properly with our pots or we simply tell the customer to find a pots line that works with a different provider. I doubt we would be comfortable with that as a solution. Matt -- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering On Mon, Feb 13, 2023 at 3:48 PM Matthew Yaklin via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> wrote:
Ok this is a bodge... but if it always dials the same number, and its dialing it has an issue with, set it up as a PLAR line? As soon as goes to dial just dial the number for it, and leave it to send or not send which ever digits of the number it wants....? Its not perfect, the customer needs to know you need to know if the alarm panel people ever change the number, but would get it working?
---- To keep our discussion simple, I gave the most common error case which is missing digits. There are variations to the issue and I doubt that would be feasible on a dozen lines when the error can vary slightly depending on the factors causing the problem. Sometimes it can be two missing digits. Sometimes it can dial properly in some pots examples. Next time it dials something else is missing. ---- As times goes on the company has lost a lot of the copper knowledge we used to have. A lot of old school CO techs are retired. I relied on turnstones and other central office gear to test copper pairs. T1s are easy. This is getting into the nitty gritty realm of pots lines that normally I can figure out with research but this is an odd one. ---- Like I mentioned. I will send an email shortly to all the relevant parties that getting an ADTRAN eng on the line to use those superuser temp passwords is my last real chance to solve this short of using suggestions people made here about getting specialized gear and checking the specs of what things are doing. Even if we did prove the old fire alarm panels are doing something wrong ?it worked on the DMS? will be said back to us. End result is the same. Go find a different provider. ---- I am just annoyed I have a problem and I cannot seem to figure it out. I don?t like the taste of it at all. Matt Matt On Mon, 13 Feb 2023 at 21:29, Jay Hennigan via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> wrote: On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it. Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec. -- Jay Hennigan - jay at west.net<mailto:jay at west.net> Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
OK, that makes sense. PLAR is more useful for elevator phones I think, but perhaps as a stopgap while they migrate to cellular or whatever, it might be useful to you as well. Given all the trials and tribulations you have outlined, I'd be considering declining to continue providing service to these fire alarms as well. -- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering On Mon, Feb 13, 2023 at 4:12 PM Matthew Yaklin <myaklin at firstlight.net> wrote:
But if the issue is always at dial time, and never at reporting time, it seems like a PLAR would indeed solve it...?
---- Sorry Hunter. I should have googled what a PLAR was. I am not used to that acronym. Basically, a hotline. Pick up the line it dials a specific number. I was thinking digit manipulation for some reason.
----- Normally a fire alarm panel has two lines plugged into it. It can be programmed with multiple numbers it tries to dial. If one line is down or the number it dialed is busy it will try the other line or another number.
----- I am not sure if that would be allowed. I think in the case of a fire alarm panel it has to work properly with our pots or we simply tell the customer to find a pots line that works with a different provider. I doubt we would be comfortable with that as a solution.
Matt
-- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331
Office of Information Technology The University of Alabama in Huntsville Network Engineering
On Mon, Feb 13, 2023 at 3:48 PM Matthew Yaklin via VoiceOps < voiceops at voiceops.org> wrote:
Ok this is a bodge... but if it always dials the same number, and its dialing it has an issue with, set it up as a PLAR line? As soon as goes to dial just dial the number for it, and leave it to send or not send which ever digits of the number it wants....? Its not perfect, the customer needs to know you need to know if the alarm panel people ever change the number, but would get it working?
---- To keep our discussion simple, I gave the most common error case which is missing digits. There are variations to the issue and I doubt that would be feasible on a dozen lines when the error can vary slightly depending on the factors causing the problem. Sometimes it can be two missing digits. Sometimes it can dial properly in some pots examples. Next time it dials something else is missing.
---- As times goes on the company has lost a lot of the copper knowledge we used to have. A lot of old school CO techs are retired. I relied on turnstones and other central office gear to test copper pairs. T1s are easy. This is getting into the nitty gritty realm of pots lines that normally I can figure out with research but this is an odd one.
---- Like I mentioned. I will send an email shortly to all the relevant parties that getting an ADTRAN eng on the line to use those superuser temp passwords is my last real chance to solve this short of using suggestions people made here about getting specialized gear and checking the specs of what things are doing. Even if we did prove the old fire alarm panels are doing something wrong ?it worked on the DMS? will be said back to us. End result is the same. Go find a different provider.
---- I am just annoyed I have a problem and I cannot seem to figure it out. I don?t like the taste of it at all.
Matt
Matt
On Mon, 13 Feb 2023 at 21:29, Jay Hennigan via VoiceOps < voiceops at voiceops.org> wrote:
On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it.
Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec.
-- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
_______________________________________________ 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 think you are on the right track to escalate this with Adtran. They should hopefully appreciate the opportunity to discover the root cause and fix this. It seems pretty clear it is something with the Adtran hardware or firmware that can solve this problem. Are all your Adtran on the same firmware? Maybe while you wait you could try to upgrade or downgrade one to see if you can reveal any difference. Good luck. I know exactly how frustrating issues like this feel. On Mon, Feb 13, 2023 at 2:12 PM Matthew Yaklin via VoiceOps < voiceops at voiceops.org> wrote:
But if the issue is always at dial time, and never at reporting time, it seems like a PLAR would indeed solve it...?
---- Sorry Hunter. I should have googled what a PLAR was. I am not used to that acronym. Basically, a hotline. Pick up the line it dials a specific number. I was thinking digit manipulation for some reason.
----- Normally a fire alarm panel has two lines plugged into it. It can be programmed with multiple numbers it tries to dial. If one line is down or the number it dialed is busy it will try the other line or another number.
----- I am not sure if that would be allowed. I think in the case of a fire alarm panel it has to work properly with our pots or we simply tell the customer to find a pots line that works with a different provider. I doubt we would be comfortable with that as a solution.
Matt
-- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331
Office of Information Technology The University of Alabama in Huntsville Network Engineering
On Mon, Feb 13, 2023 at 3:48 PM Matthew Yaklin via VoiceOps < voiceops at voiceops.org> wrote:
Ok this is a bodge... but if it always dials the same number, and its dialing it has an issue with, set it up as a PLAR line? As soon as goes to dial just dial the number for it, and leave it to send or not send which ever digits of the number it wants....? Its not perfect, the customer needs to know you need to know if the alarm panel people ever change the number, but would get it working?
---- To keep our discussion simple, I gave the most common error case which is missing digits. There are variations to the issue and I doubt that would be feasible on a dozen lines when the error can vary slightly depending on the factors causing the problem. Sometimes it can be two missing digits. Sometimes it can dial properly in some pots examples. Next time it dials something else is missing.
---- As times goes on the company has lost a lot of the copper knowledge we used to have. A lot of old school CO techs are retired. I relied on turnstones and other central office gear to test copper pairs. T1s are easy. This is getting into the nitty gritty realm of pots lines that normally I can figure out with research but this is an odd one.
---- Like I mentioned. I will send an email shortly to all the relevant parties that getting an ADTRAN eng on the line to use those superuser temp passwords is my last real chance to solve this short of using suggestions people made here about getting specialized gear and checking the specs of what things are doing. Even if we did prove the old fire alarm panels are doing something wrong ?it worked on the DMS? will be said back to us. End result is the same. Go find a different provider.
---- I am just annoyed I have a problem and I cannot seem to figure it out. I don?t like the taste of it at all.
Matt
Matt
On Mon, 13 Feb 2023 at 21:29, Jay Hennigan via VoiceOps < voiceops at voiceops.org> wrote:
On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it.
Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec.
-- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
_______________________________________________ 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
-- *Brandon Svec* CA C-7 Lic. #822064 <https://www.cslb.ca.gov/OnlineServices/CheckLicenseII/LicenseDetail.aspx?Lic...> *15106862204 <15106862204> voice|sms**teamonesolutions.com <https://teamonesolutions.com/>* Schedule time with me <https://calendar.app.google/tb1tibeLZu8mTpm68>
I think you are on the right track to escalate this with Adtran. They should hopefully appreciate the opportunity to discover the root cause and fix this. It seems pretty clear it is something with the Adtran hardware or firmware that can solve this problem. Are all your Adtran on the same firmware? Maybe while you wait you could try to upgrade or downgrade one to see if you can reveal any difference. ----- The trouble with blaming ADTRAN is that the TA750 has been out for a very long time. It was the same device serving the customer on the DMS and the same device now migrated to the Metaswitch. On top of that the TA5000 is a completely different device and relatively new compared to the TA5000. We deployed it just a couple of months ago and the first thing we do is upgrade it to the current stable release. We use both of these devices all over New England serving other alarm panels. ----- It really seems that the DMS was more capable of handling the dialing (DTMF) of these alarm panels compared to the Metaswitch in this specific region of NY. Be it the DMS with fxs pots line cards as part of it as well as GR303 trunks it provided the existing gear which is still being used. Quite the mystery for me. ----- I also sent the email to the team with the remaining idea to bring in ADTRAN deeper. They have a lot of experience with this stuff. ---- Thank you everyone for the replies. I wish I had specialized gear laying around to attempt some lower level ideas but I do not think I have that much time left to figure this out. Mgmt?s patience is wearing thin especially after a VP tried to talk to the alarm panel guy and realized who we were dealing with. Matt Good luck. I know exactly how frustrating issues like this feel. On Mon, Feb 13, 2023 at 2:12 PM Matthew Yaklin via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> wrote:
But if the issue is always at dial time, and never at reporting time, it seems like a PLAR would indeed solve it...?
---- Sorry Hunter. I should have googled what a PLAR was. I am not used to that acronym. Basically, a hotline. Pick up the line it dials a specific number. I was thinking digit manipulation for some reason. ----- Normally a fire alarm panel has two lines plugged into it. It can be programmed with multiple numbers it tries to dial. If one line is down or the number it dialed is busy it will try the other line or another number. ----- I am not sure if that would be allowed. I think in the case of a fire alarm panel it has to work properly with our pots or we simply tell the customer to find a pots line that works with a different provider. I doubt we would be comfortable with that as a solution. Matt -- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering On Mon, Feb 13, 2023 at 3:48 PM Matthew Yaklin via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> wrote:
Ok this is a bodge... but if it always dials the same number, and its dialing it has an issue with, set it up as a PLAR line? As soon as goes to dial just dial the number for it, and leave it to send or not send which ever digits of the number it wants....? Its not perfect, the customer needs to know you need to know if the alarm panel people ever change the number, but would get it working?
---- To keep our discussion simple, I gave the most common error case which is missing digits. There are variations to the issue and I doubt that would be feasible on a dozen lines when the error can vary slightly depending on the factors causing the problem. Sometimes it can be two missing digits. Sometimes it can dial properly in some pots examples. Next time it dials something else is missing. ---- As times goes on the company has lost a lot of the copper knowledge we used to have. A lot of old school CO techs are retired. I relied on turnstones and other central office gear to test copper pairs. T1s are easy. This is getting into the nitty gritty realm of pots lines that normally I can figure out with research but this is an odd one. ---- Like I mentioned. I will send an email shortly to all the relevant parties that getting an ADTRAN eng on the line to use those superuser temp passwords is my last real chance to solve this short of using suggestions people made here about getting specialized gear and checking the specs of what things are doing. Even if we did prove the old fire alarm panels are doing something wrong ?it worked on the DMS? will be said back to us. End result is the same. Go find a different provider. ---- I am just annoyed I have a problem and I cannot seem to figure it out. I don?t like the taste of it at all. Matt Matt On Mon, 13 Feb 2023 at 21:29, Jay Hennigan via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> wrote: On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it. Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec. -- Jay Hennigan - jay at west.net<mailto:jay at west.net> Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops -- [https://team-one-solutions-v1612389488.websitepro-cdn.com/wp-content/uploads...] Brandon Svec CA C-7 Lic. #822064<https://www.cslb.ca.gov/OnlineServices/CheckLicenseII/LicenseDetail.aspx?Lic...> 15106862204<tel:15106862204> voice|sms teamonesolutions.com<https://teamonesolutions.com/> Schedule time with me<https://calendar.app.google/tb1tibeLZu8mTpm68>
On 2/13/23 13:20, Matthew Yaklin wrote:
----- ADTRAN went straight to examining the dialing-plan in the TA5000 when I shared my config with them for those exact reasons. We both agreed since digits were missing in the middle in many cases this was probably not a dialing-plan issue or DTMF/pulse dial issue. They signed off on our config as proper.
Does the Adtran detect pulse dialing? That might be an option if the alarm panel can be configured for it. -------- The fire alarm panel guy is not helpful at all. If we asked him to change it to pulse dialing, he just shouts back at us it worked on the DMS. It is very difficult to get coherent information from him but then maybe there is really nothing for him to modify in his panel configuration? Early on he replaced a "dialer" in one of them but since then we do not get much cooperation. Is it just one make and model of alarm panel that fails? Do the tones sound off or different with a butt-set bridged in monitor mode? See if someone local has a SAGE 930A that you can borrow, that will definitely tell you if the DTMF is in spec. -------- So far I know of at least two different models by different manufacturers. Unless one company just happens to own all these brands now days and keeps them going it does appear to be different models. The tones sound decent via a crappy butt set speaker but happen very very quickly. I am talking less than 2 seconds to dial. Someone else mentioned specialized gear to analyze this better. The thing is the Metaswitch gives me basic analysis when I view SAS in engineering mode. I see the duration of the tone, time between tones, etc.. so I do have some basic information to go on. But yes, I am unable to figure out what is going on when I have a period of time where I expect two DTMF digits but the meta sees nothing. -------- I will be honest. I doubt I can get specialized gear before the company sends out letters saying you have 2 months to find a new provider. Matt -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Jheeze, what an event ya poor bugger Paul! Granted I operate in an entirely different country, but when my school looses either or both of their dual fire monitoring channels (IP & cellular), the monitoring company calls my cellphone to let me know. The alarm does not trip! Heh :) Also a comment on the side to Matt - I commend you for your persistence and tenacity. It's been a fascinating thread on which to lurk and if I were in the US I'd want to be your customer. It sounds like your alarm guy might have come from New Zealand maybe - they're almost all like that here! Best of luck & please report back if you ever do fix it :) Pete
On 14/02/2023, at 10:00 AM, Paul Timmins via VoiceOps <voiceops at voiceops.org> wrote:
<snip> Needless to say, that was an awkward call to show up on at an inner city charter school, pulling up to greet a bunch of evacuated students and an annoyed fireman who stuck around in a fly car just to give the all clear.
On 2/13/23 19:47, Pete Mundy via VoiceOps wrote:
Also a comment on the side to Matt - I commend you for your persistence and tenacity. It's been a fascinating thread on which to lurk and if I were in the US I'd want to be your customer. It sounds like your alarm guy might have come from New Zealand maybe - they're almost all like that here!
If it's in New Zealand, don't even think about setting it to rotary dial. You'll get wrong numbers unless you have the secret decoder ring. https://commons.wikimedia.org/wiki/File:New_Zealand_Rotary_Telephone.jpg -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
"In 1987, Telecom was created ..." :-) They should "but it was not yet useful for anything", haha Quoting Jay Hennigan via VoiceOps <voiceops at voiceops.org>:
On 2/13/23 19:47, Pete Mundy via VoiceOps wrote:
Also a comment on the side to Matt - I commend you for your persistence and tenacity. It's been a fascinating thread on which to lurk and if I were in the US I'd want to be your customer. It sounds like your alarm guy might have come from New Zealand maybe - they're almost all like that here!
If it's in New Zealand, don't even think about setting it to rotary dial. You'll get wrong numbers unless you have the secret decoder ring.
https://commons.wikimedia.org/wiki/File:New_Zealand_Rotary_Telephone.jpg
-- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--- The issue is that when the alarm panel dials the INVITE from the TA5k does not contain the correct digits dialed. A couple of digits are missing for example. Sometimes a call does manage to squeak through properly. If the digits do get to the Metaswitch properly the call completes fine. Same exact symptom with GR303. In SAS (meta's service assurance server that contains debug output) I can clearly review what digits reach the metaswitch via GR303. In this case I will see missing digits as I know the number the alarm panel is supposed to dial and a gap of time which should have contained digits.
OK, so the FXS port of the local Adtran device isn't reliably decoding the DTMF from the panel. Could be frequency, level, or twist. See if there are knobs for receive level and/or impedance for the specific line port used by the panel. I'd start with level, bump it up and down 3dB at a time and see if it starts decoding reliably. If possible bracket it to see where it fails again and set it in the middle. Changing impedance might help if it's twist. Sometimes the options include series capacitance. Likely going to be trial-and-error. ------ That is exactly what we tried. Modifying the settings available in the TA5000. So here is what you have to play with. PLBGNY01AT0#show running-config interface fxs 1/7/23 verbose ! interface fxs 1/7/23 description "default adtran settings shown" impedance 900c rx-gain -4.0 tx-gain -4.0 signaling loop-start alarm enable line-showering alarm enable trunk-conditioning alarm enable over-temperature no shutdown ======================= PLBGNY01AT0(config-fxs 1/7/23)#impedance 600r - 600 Ohms 900c - 900 + 2.16uF auto - Automatically select the impedance z1 - 220 + (820 || 115nF) z2 - 270 + (750 || 150nF) z3 - 270 + (750 || 150nF), Zin = 600 z4 - 320 + (1050 || 230nF) z5 - 350 + (1000 || 210nF), Zin = 600 z6 - 370 + (620 || 310nF) z7 - 800 || (100 + 50nF), Zin = 900 + 2.16uF z8 - 1650 || (100 + 5nF), Zin = 900 + 2.16uF ============================= PLBGNY01AT0(config-fxs 1/7/23)#tx-gain <-6.0-9.0> - Gain in 0.1dB increments PLBGNY01AT0(config-fxs 1/7/23)#rx-gain <-10.0-6.0> - Gain in 0.1dB increments ================== And I hate to say this I brute forced them all pretty much. Tried each impedance. Forced the alarm panel to dial out by disconnecting the battery backup in it. Then adjusted tx and rx gain. For the alarm panel to dial. Etc... I read docs such at this to improve my understanding and many others: https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-... I never had to try this hard to get a normal pots line working to an alarm panel over copper or T1 delivered pots to a channel bank. Matt -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Mon, 13 Feb 2023, Matthew Yaklin via VoiceOps wrote:
What I am seeing is that the DMS was collecting the digits properly before the cutover. Yet our migrated to setup is having trouble. We see missing digits in most cases or other oddities. It does appear the alarm panels are dialing within DTMF specs. Duration of the DTMF is approx 95 ms. A DTMF signal separated by a 150-200 ms pause.
Can you modify this timing to something longer? Like 250ms tone, 250ms space/delay? --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
On Mon, 13 Feb 2023, Matthew Yaklin via VoiceOps wrote:
What I am seeing is that the DMS was collecting the digits properly before the cutover. Yet our migrated to setup is having trouble. We see missing digits in most cases or other oddities. It does appear the alarm panels are dialing within DTMF specs. Duration of the DTMF is approx 95 ms. A DTMF signal separated by a 150-200 ms pause.
-> Can you modify this timing to something longer? Like 250ms tone, 250ms space/delay? ---- Those are the exact questions I asked the fire alarm panel guy and it appears the answer is no once I got him through his 10 minute tirade it used to work on the DMS and other things he saw go wrong over his career. I also wanted to know if the alarm panel could manually dial a call like a pots line could and I never got a clear answer on that or documentation on the panel that I could study myself. So maybe the answer is no, maybe he never tried to do it, or he has no clue. ---- I get the feeling these alarm panels are quite old and based on the pictures I saw of a couple of them ancient. They have definitely been on the wall for 20 plus years along with that DMS switch sitting in our central office. Matt --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
On 2/13/23 14:35, Peter Beckman via VoiceOps wrote:
On Mon, 13 Feb 2023, Matthew Yaklin via VoiceOps wrote:
What I am seeing is that the DMS was collecting the digits properly before the cutover. Yet our migrated to setup is having trouble. We see missing digits in most cases or other oddities. It does appear the alarm panels are dialing within DTMF specs. Duration of the DTMF is approx 95 ms. A DTMF signal separated by a 150-200 ms pause.
?Can you modify this timing to something longer? Like 250ms tone, 250ms ?space/delay?
Anything greater than 35ms on, 35 ms off typically works, 50 on, 50 off for sure. Won my share of radio station contests back in the day before the PRI guys came along. I agree that auto-ringdown would be something to try unless the alarm panel is too smart for its own good and just sits there waiting for dial tone. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
Hi Matt,
I don't think a butt set and a tape recorder would be sufficient to record the audio which is about all I could possibly scratch up without spending money.
It's been a while since I've had to deal with POTS issues like you're describing, but getting a recording off a buttset into a sound file (e.g. WAV) that Audacity can handle was very useful back then. It would let me analyze the duration and amplitude of the tones, as well as do frequency analysis to make sure the tones were in spec. These days I might use some of the blocks in GNURadio (it's not just for SDRs) to do further frequency analysis. This might give you some additional tools without spending money. Hopefully this helps. - Lawrence On Mon, Feb 13, 2023, 14:16 Matthew Yaklin via VoiceOps < voiceops at voiceops.org> wrote:
Hello All,
I guess I have an old school question for the list. The question is we are having trouble with alarm panels dialing and our gear collecting the DTMF digits properly. Only from a company ran by a single alarm panel guy who is not terribly helpful. At least 7 different sites are having the same problem on different copper pairs/T1s. Different gear. Etc...
It seems we are always migrating off old DMS switches. In this case a DMS 100 with your typical line drawers with cards in them for pots lines or GR303 groups. We are migrating to a Metaswitch using different types of connections. In this case GR303 for some and SIP for others. ADTRAN gear in this case. TA4303 and a TA5000. We have been a Metaswitch shop for quite a long time now.
Pretty vanilla stuff we rely on in many regions that has always "just worked" for legacy clients.
Metaswitch -> GR303 to a TA4303 -> drop T1 to a TA3000 -> build a T1 on our copper plant -> Smart jack -> TA750 at customer location -> customer fire alarm panel
Or...
Metaswitch -> SIP -> TA5k with RPOTS cards in SIP mode -> copper plant -> demarc -> customer fire alarm panel
What I am seeing is that the DMS was collecting the digits properly before the cutover. Yet our migrated to setup is having trouble. We see missing digits in most cases or other oddities. It does appear the alarm panels are dialing within DTMF specs. Duration of the DTMF is approx 95 ms. A DTMF signal separated by a 150-200 ms pause.
Any other type of customer is working flawlessly. 100s and 100s of pots line migrated with no complaints except a single guy who manages fire alarm panels of a few different types. "Contact id Edwards". " Contact id ES4 Kidde".
Naturally, a tech sent on site can dial out fine with his butt set. The copper pairs test fine. T1 is error free. Hardware has been swapped out. Moved to different fxs ports. You name it we probably tried it.
Does anyone have a suggestion what could be the cause for this? Something I am not aware of DMS wise when it came to fire alarm panels? Some change that can be adjusted in the fire panel configuration that might solve this? When we port/move the customer back to the DMS it just starts working again in the case of the TA5000. There is no going back for the GR303 subs which were moved all at once.
Any tips are welcome!
Thank you,
Matt
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (11)
-
beckman＠angryox.com -
bsvec＠teamonesolutions.com -
hf0002+nanog＠uah.edu -
jay＠west.net -
jbrower＠signalogic.com -
larryka＠gmail.com -
mbolton＠holmeselectricsecurity.com -
myaklin＠firstlight.net -
paul＠timmins.net -
pete＠mac.geek.nz -
richard.goodyear＠googlemail.com