All the ATA does is attempt to complete the call, what transgresses within is between the panel and the monitoring service, it will only work on g711 and the alarm panel will need to recognize a valid FXS interface (your ATA) to initiate the call.
If you can ‘call-in’ but not ‘call-out’ suspect the BAT as a deal breaker.
Okay, I was digging through the manual of the HT801, and found a setting called:
Enable HIgh Ring Power - Configures a High Ringing Voltage Output for the HT801/HT802
I thought that sounded promising! I didn’t want to get my hopes up, but its worth a try.I’m hoping that makes it 48VDC…I’m praying.
That only affects ringing voltage sent to the panel on an incoming call. Try to debug this by finding out what is going wrong.
First, the usual problem with alarm panels is that the outbound call is made and connects fine, but the communication with the central station (usually Contact ID or SIA) does not get passed accurately by the VoIP system, so the events are not acknowledged. The panel attempts several calls and then gives up.
If this is your issue, the CDRs will show a sequence of several calls made by the panel. In this case, assuming Contact ID, try switching from RFC2833 to inband (or vice versa). Find out whether the central station accepts both protocols; if so, try the other one.
If nothing appears in the CDRs, see whether anything appears in the Asterisk log. If so, perhaps the panel is dialing in a different format than what you tested.
If nothing in the Asterisk log, confirm that when the panel is not trying to call, the DC voltage supplied by the HT is 45 to 52 volts. If ok, set up syslog on the HT801 and see whether anything shows up there.
And if no syslog from the HT801, either, try reversing the tip and ring wires to the panel – possibly it has no polarity guard and it’s opposite to what the panel expects.
Okay, will start with this tommorrow.
Is in-audio another name for inband?
Yep. It means that DTMF is sent the same as voice, rather than being digitally encoded.
Okay, something for me to try tommorrow. Thank-you for the clarification. I will also call the central station and see what protocols they accept.
Okay, so here’s what i know so far, and I want to emphasize that Dicko was correct on several things too, thank you for your help too Stewart1:
I find it interesting that the panel is communicating with the call centre, and that the call center is answering, so I feel like we’re close.
PS - The raw codec on the box as the first choice is G711 PCMU.
Next thing is to check with the monitoring service that the daily ‘checkpoints’ are being received correctly, normally the ademco protocol will return to the panel an ‘ack’ signal in the same call that relieves the panel from the need to recall.
Ref :-
http://www.voip-sip-sdk.com/attachments/583/contact_id.pdf
This is the config I use for the Grandstream HT802 for faxing which is basically functionally the same as the Ademco communication protocol.
The two most important settings are likely the T.38 passthrough and disabling the echo cancellation.
Create filename cfgabcdefabcdef.xml in the /tftpboot folder of your FreePBX instance. Where abcdefabcdef is the MAC using lower case letters in the filename and uppercase letters in the config file below.
<?xml version="1.0" encoding="UTF-8"?>
<!-- HT8XX XML Provisioning Configuration -->
<gs_provision version="1">
<mac>ABCDEFABCDEF</mac>
<config version="2">
<!-- # Admin password for web interface -->
<P2>domain$upport123</P2>
<!-- # Firmware Upgrade and Privisioning. 0 - TFTP Upgrade, 1 - HTTP Upgrade, 2 - HTTPS Upgrade. -->
<P212>2</P212>
<!-- # HTTP/HTTPS User Name -->
<P1360>123456</P1360>
<!-- # HTTP/HTTPS Password -->
<P1361>0987654321cba</P1361>
<!-- # Firmware Server Path -->
<P192>pbx.domain.com:1443</P192>
<!-- # Firmware File Postfix -->
<P233>_1.0.17.5</P233>
<!-- Config Server Path-->
<P237>pbx.domain.com:1443</P237>
<!-- # Config File Postfix -->
<P235></P235>
<!-- # Automatic Upgrade. 0 - No, 1 - Check daily, 2 - Check weekly, 3 - Check every () minutes. Default is No. -->
<P194>1</P194>
<!-- # Automatic Upgrade. Daily at hour(0-23) -->
<P285>18</P285>
<!-- # NTP Server -->
<P30>us.pool.ntp.org</P30>
<P64>CST6CDT</P64>
<!-- DHCP Hostname -->
<P146>ext123</P146>
<!-- FXS PORT 1 Settings -->
<!-- # Account Active. 0 - No, 1 - Yes. -->
<P271>1</P271>
<!-- # SIP Registration. 0 - No, 1 - Yes -->
<P31>1</P31>
<!-- # Primary SIP Server -->
<P47>pbx.domain.com</P47>
<!-- # SIP Transport 0 - UDP, 1 - TCP, 2 - TLS -->
<P130>2</P130>
<!-- # SRTP Mode 0=Disabled 1=Enabled but not forced 2=Enabled and forced -->
<P183>2</P183>
<!-- SIP User ID -->
<P35>123</P35>
<!-- Authenticatoin ID -->
<P36>123</P36>
<!-- Authentication Password -->
<P34>hexpasswordfromextensionpage</P34>
<!-- Name -->
<P3>Fax 1</P3>
<!-- # SIP Registration Failure Retry Wait Time upon 403 Forbidden default 1200-->
<P26002>3600</P26002>
<!-- # 0 - PCMU, 8 - PCMA, 4 - G.723, 18 - G.729, 2 - G.726-32, 97 - iLBC, 123 - OPUS， 9 - G722. -->
<!-- Codec Choice 1 -->
<P57>9</P57>
<!-- Codec Choice 2 -->
<P58>123</P58>
<!-- Codec Choice 3 -->
<P59>0</P59>
<!-- Codec Choice 4 through 8 -->
<P60>0</P60>
<P61>0</P61>
<P62>0</P62>
<P46>0</P46>
<P98>0</P98>
<!-- Fax Mode 0=T.38 1=Passthrough -->
<P228>1</P228>
<!-- Disable Line Echo Canceller (LEC). 0 - No, 1 - Yes -->
<P824>1</P824>
<!-- FXS PORT 2 Settings -->
<!-- # Account Active. 0 - No, 1 - Yes. -->
<P401>1</P401>
<!-- # SIP Registration. 0 - No, 1 - Yes -->
<P731>1</P731>
<!-- # Primary SIP Server -->
<P747>pbx.domain.com</P747>
<!-- # SIP Transport 0 - UDP, 1 - TCP, 2 - TLS -->
<P830>2</P830>
<!-- # SRTP Mode 0=Disabled 1=Enabled but not forced 2=Enabled and forced -->
<P443>2</P443>
<!-- SIP User ID -->
<P735>321</P735>
<!-- Authenticatoin ID -->
<P736>321</P736>
<!-- Authentication Password -->
<P734>hexpasswordfromextensionpage</P734>
<!-- Name -->
<P703>Fax 2</P703>
<!-- # SIP Registration Failure Retry Wait Time upon 403 Forbidden default 1200-->
<P26102>3600</P26102>
<!-- # 0 - PCMU, 8 - PCMA, 4 - G.723, 18 - G.729, 2 - G.726-32, 97 - iLBC, 123 - OPUS， 9 - G722. -->
<!-- Codec Choice 1 -->
<P757>9</P757>
<!-- Codec Choice 2 -->
<P758>123</P758>
<!-- Codec Choice 3 -->
<P759>0</P759>
<!-- Codec Choice 4 through 8 -->
<P760>0</P760>
<P761>0</P761>
<P762>0</P762>
<P814>0</P814>
<P815>0</P815>
<!-- Fax Mode 0=T.38 1=Passthrough -->
<P710>1</P710>
<!-- Disable Line Echo Canceller (LEC). 0 - No, 1 - Yes -->
<P825>1</P825>
</config>
</gs_provision>
None of this voltage crap matters. If you hook it up and the alarm panel does not go into fault for lack of phone line, then it is detecting what it needs to detect. If and only if it goes into immediate alarm/check about lack of dial tone do you even think about anything else.
Having spent 7 years of my life installing Alarm systems, I can go into all kinds of detail on how it all works. But make life easy on yourself and just take whatever wires were on the original POTS demarc and plug them into the Grandstream on an RJ11.
Wow! Okay I’ll try this…like…wow. Looking forward to this.
Thank-you Jared.
I disagree with one of @sorvani 's settings. IMO P57 (codec choice 1) should be 0 (PCMU a.k.a. ulaw) – any transcoding is just asking for trouble.
Also, he’s not setting DTMF parameters at all. You should definitely try in-audio if digits are dropped when using RFC2833.
You may have to do this on the trunk side as well. If a test shows that’s necessary, create a secondary trunk (with the same credentials and other parameters as the regular trunk), so you don’t degrade DTMF performance for human callers.
If you can’t get Contact ID to work and you switch to SIA, @sorvani 's settings should do the trick.
All a little confusing her from a previous link I gave
ACKNOWLEDGMENTS
This document was developed by Richard Hinkson of the ADEMCO Group, a division of Pittway
Corporation.
The Ademco “Contact ID” protocol has become a prevalent and respected format for digital
communications between security alarm systems and central monitoring stations. Many manufacturers
have adopted it, seeking industry wide compatibility.
SIA gratefully acknowledges Ademco’s generous contribution to communications in the security
industry, both in allowing SIA to publish this protocol as a de facto security industry standard and in
accepting industry requests for modifications.
i.e. they are all actually the same, the Voltage thing is not actually BS, ATA’s only supplying 24 have been problematic for me for a lot longer than 7 years, my experience includes alarm panels, tivo boxes, postage machines, ATM machines and even 300-56K baud modems, they all work fine on a PSTN , add ‘cleverness’ with not g711 or even AT&T’s IP-FLEX (they happily reuse g711 for perceived faxes, anything else will still be abroken through g729 until you bitch and whine) and you can be in a world of hurt.
If the OP still has a copper PSTN, I suggest he’ compares and contrasts.’
Technically, of course it is not B.S.
But that is not relevant to the OP.
You hook it up and see if it causes an issues or not. If not, nothing else to even think about. I stated above, if and only if it has problems, then you need to worry about it.
The entire side track of talking about the line voltage here never actually mattered because his panel alarm panel is obviously not in a check state since it is dialling and having issues with the actual communication. Not beeping at him that the line is missing.
His problems are likely the LEC and/or T.38 both being enabled by default.
My trunk provider offers 722, so that is always my primary codec all the way through. Of course change that as appropriate for our scenario.
Okay, so I tried the config. No love, same result as before. I just don’t think the HT801 ATA is passing the ContactID/Ademco protocol properly. I really appreciate all of your help in here. You have all been great. At this point, with the Alarm Call center unwilling to work with me, and check communication logs, I’m dead in the water, not to mention they won’t Indemnify the alarm for insurance if I don’t have a back-up mode of communication.
As a result, I researched a $200 IP/GSM card for this panel that is ULC compliant as it has a main and backup mode of communication. This allows me to ditch the analog line, for the Network line, and also has the GSM sim backup, We get a government discount rate on the sim card so this is also a more affordable solution (a couple bucks a month, plus flat rate data). It is way cheaper then the analog line and solves my problem. Thanks you all once again, I gave it my best go, and so did you all.
I think you made the wise choice. If you ever get inquisitive, bridge the FXS to the asterisk app_alarmreceiver
https://wiki.asterisk.org/wiki/display/AST/Application_AlarmReceiver