Issues with an Alarm that cannot dial (analog/FXS)

[apitsos]

Hi there!

We have installed a Grandstream HT-812 FXS adapter on a customer, which is used for FAX and for the Alarm. The first port that is connected to the FAX works perfectly fine, but the Alarm cannot complete the connection by dialing, as the line seems to be dropped. I switched the lines ports (the cables) and the FAX could also send and receive from the port that was intended to be used by the alarm, and the alarm could also not complete a connection when connected to the line that was intended to be used by the FAX. So is not a problem of the extension or the FXS adapter port.

I have the feeling that the alarm dials too fast, much faster than any other analog device. I figured out that, because I connected also a simple phone in parallel, in order to hear what the alarm does. After dialing, the line seems to be dropped by the PBX itself. At least this is what I am understanding from the tones I hear.

The technicians from the alarm system told me that the device cannot change the way that is dialing the numbers, except if they put pauses between each number. But these pauses are 4 seconds, which I think is too much.

Does anyone have a similar experience with alarms and let me know what is needed to be done on the FXS adapter?

Thanks a lot in advance for your prompt attention.

 

[JohnS_3CX]

Hi @apitsos

Devices like the HT812 have an interdigit timeout (default is 4 seconds) before sending the call to the pbx.

What does the Call Log show that the alarm dialled?

 

[apitsos]

Hi @JohnS_3CX!

Thanks a lot for the immediate response, I really appreciate it. This is actually a very urgent issue and it looks like you understood that, because it has to do with alarm systems.

Here is the call logs from the extension I created for Alarm:


Should I try to change something on the setting "No Key Entry Timeout" on the Grandstream FXS adapter?

With Kind regards,
Angelos Pitsos

 

[JohnS_3CX]

1. Is the dialled number correct (ie. what the alarm company expects your device to dial)?

2. If it is indeed correct, can you try dialing it from the ATA via an analog handset?

3. Can you also dial it from the webclient?

Let me know the answer to the above 3 and we can take it from there

 

[apitsos]

Hi mate,

The numbers are correct. I communicated with the technician of the alarm a while ago and we confirmed that the dial numbers are the correct ones. I also confirm that I can dial the numbers from an analog handset, when I connect it on the FXS analog port. As for the Web Client, I have disabled this option from the extension's settings, as I don't want anyone to be able to use this extension for any other reason. I did that for increasing the security. But I am pretty sure that as soon as I can dial these numbers from a device and I get an answer (hearing tones like a FAX or modem), then it will not be an issue to be dialed from the Web Client.

I have understand that the alarm is making the call properly and when starts sending the tones (which are extremely fast), the line is hanged up. I tried also some times to interfere to the connection with an analog device I have connected in parallel, in order to hear and understand what is going on.

 

[JohnS_3CX]

Ok so assuming the number can be dialled from the ATA using an analog phone, we should be OK with the trunk and the outbound rules.

Now, as for the alarm system which gives us different results to what we expect, you should look at the logs after it makes its next attempt. Enable verbose logs and make it try again.

We need to know who is terminating the call (based on the logs):

- The alarm because it does not hear what it expects?
- The ATA because the digits are dialled too fast for it?
- The PBX because it gets a request that doesn't match any rule?
- The provider for getting a request they don't like?

 

[apitsos]

Hi @JohnS_3CX,

How should I sent you the logs? I don't want to publish them here...

 

[JohnS_3CX]

Click on filter, select the call ID to view only that call (Search By Call field), and copy the result.

Click Load More.. on the bottom right to show the entire log first.

Send me a PM and I will take a look.

 

[apitsos]

Hi @JohnS_3CX,

I sent you a pm with the logs.

 

[JohnS_3CX]

It looks like the call was made successfully at first, and then the ATA ended the call.

Normally it will end the call if the alarm system hangs up the line.

You might need to speak with the alarm guys so they can look at the logs of the alarm box and see what it says. Maybe the alarm system made the call, but did not like what it heard and hang up?

 

[apitsos]

Hi @JohnS_3CX,

The decision was made and they will put a GSM module on the alarm system, in order to be able to communicate with via the mobile network.

Thanks a lot for your input. I always appreciate your support!


With kind regards,
Angelos Pitsos

 

[leejor]

Did you find out what at speed the alarm system communicates? It may be that it is too high to go over VoIP and has no fall back to a slower speed as many fax machines do.
As far as the speculation, that the device was dialling too fast, I'm sure that the ATA can take just about any DTMF dialling speed you can throw at it.

 

[cobaltit]

Hi @JohnS_3CX,

The decision was made and they will put a GSM module on the alarm system, in order to be able to communicate with via the mobile network.

Thanks a lot for your input. I always appreciate your support!


With kind regards,
Angelos Pitsos

Best decision that could be made. You don't want fire alarm/security alarm/elevator lines on VoIP. Lots of potential issues when dealing with Life Safety. And besides, the alarm/elevator companies will always blame the line and then bill you to come out and look at it, even with POTS lines. Getting GSM service from them makes them responsible for any issues.

 

[JohnS_3CX]

Indeed, GSM is robust enough as a standalone solution and in case intruders cut the power, your GSM module will still work since it's being powered by the alarm battery.

 

[apitsos]

Did you find out what at speed the alarm system communicates? It may be that it is too high to go over VoIP and has no fall back to a slower speed as many fax machines do.
As far as the speculation, that the device was dialling too fast, I'm sure that the ATA can take just about any DTMF dialling speed you can throw at it.

Hi @leejor,

Unfortunately I couldn't invest more time on that in order to troubleshoot it further. As soon as the decision maker said we will do it via GSM, I am out of it. Less trouble is better sometimes, right?

All the best,
Angelos Pitsos