Re: [VoiceOps] Outbound Calls being marked as SPAM

[Matthew Yaklin via VoiceOps]

I was talking with a comcast guy a while back when we had a SBC incorrectly 
set. Here is what he said. By any chance are you sending a 10 digit in the to 
or from? Comcast wants 11 digits for both with no exceptions. We simply logged 
into the Neustar portal and made a small adjustment on that side as it was 
easier then tweaking the acme sbc.

"Hello. My name is XXX XXX; I am an Engineer in Comcast's Voice Communications 
Engineering organization. I obtained your contact information from the Robocall 
Mitigation Database. Below is an example call and Identity header that fails 
Comcast's STIR-SHAKEN verification service. You are signing the call using only 
a 10 digit TO and FROM number. All TO and FROM numbers need to be 11 digits. 
Almost all 8M Comcast residential voice customers have Xfinity Voice Spam 
Blocker enabled with the default settings. Failed STIR-SHAKEN calls are sent 
directly to voicemail and do not ring my customer's phone."

matt


From: VoiceOps  On Behalf Of Matthew Crocker via 
VoiceOps
Sent: Wednesday, April 5, 2023 3:59 PM
To: voiceops@voiceops.org
Subject: [VoiceOps] Outbound Calls being marked as SPAM


We have a customer whos outbound calls are being marked as SPAM by the 
terminating carrier.   We are sending the calls out fully signed (STIR/SHAKEN) 
with attest 'A' and all of the propery identity headers.  The terminating 
carrier is Comcast from what we can tell,  does anyone have any tricks we can 
use or something we may have missed to help get the calls marked correctly?

Thanks

-Matt



___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via VoiceOps]

>https://supportcommunity.adtran.com/t5/General/How-to-Perform-a-DSP-capture/ta-p/27456

>Unfortunately, it sounds like it might not capture DSP input unless it is a 
>call actually already in progress, and (if the doc is to be believed) is going 
>from IP/RTP to TDM and/or analog, or vice-versa.  Ugh.

>There's got to be a way...



-- Nathan,

-- I was thinking more to attack it from the Metaswitch side over GR303 to 
capture a ?wav? file that another user suggested could be analyzed via 
software. I will have to read some docs as I have never done that with GR303 
while I have with a pure SIP call. Of course, I can also ask Meta as well. It 
should be able to do something for me directly on the UMG which is the 
Metaswitch part capturing the digits.





-- Nathan

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Nathan 
Anderson via VoiceOps
Sent: Monday, February 13, 2023 5:21 PM
To: Matthew Yaklin
Cc: Voice Ops
Subject: Re: [VoiceOps] Alarm panels and how they dial DTMF digits - pots 
migration from DMS to Metaswitch issue

Matthew Yaklin wrote:

> I have not considered that. I work remotely with all of this gear and I would 
> have to guide a tech to do such a thing. 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.

I have to wonder if there is a way to get the Adtran to dump a copy of the 
audio in digital form to a local file, that you could then pull off the system 
remotely.  It has to A-to-D it at some point in order to process it, right?

-- Nathan

___
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] [External] Re: Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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.


- 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 
mailto:voiceops@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 
mailto:voiceops@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 
mailto:voiceops@voiceops.org>> wrote:
On 2/13/23 13:20, Matthew Yaklin wrote:

> - ADTRAN went straight to ex

Re: [VoiceOps] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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?

 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
beck...@angryox.comhttps://www.angryox.com/
---
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] [External] Re: Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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 
mailto:voiceops@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 
mailto:voiceops@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 - j...@west.net<mailto:j...@west.net>
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
VoiceOps mailing list
VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org<mailto: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] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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 
mailto:voiceops@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 - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
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] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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.

 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 - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
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] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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 
>  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 - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
> 
> ___
> 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
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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-voip/64282-impedance-choice.html

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 - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
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] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via VoiceOps]

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  On Behalf Of Jay Hennigan via 
VoiceOps
Sent: Monday, February 13, 2023 2:30 PM
To: voiceops@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 - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
VoiceOps mailing list
VoiceOps@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@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via 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 - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

___
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

[VoiceOps] Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue

[Matthew Yaklin via VoiceOps]

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@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops