アスタリスクを使用してセキュリティシステムからデータを受信する

数年前、私が当時働いていたセキュリティ会社を、従来の「有線」電話からアスタリスクに基づいたIPに移行しました。 それは別の物語であり、試行錯誤、失敗、壮大な失敗、そして新しいものに関する継続的な知識がありました。 それ以来、音声通信に関しては、すべてがすでにデバッグされており、障害なく機能し、すべての関係者に十分に適しています。



最近まで、有線回線で動作するコンソール機器のみが保護されたオブジェクトからイベントを自動的に受信し、処理のためにディスパッチャに送信していました。 そして最後に、彼ら自身の怠inessと管理ゴーレムが敗北し、これらの鉄片の機能も電話サーバーに移されました。

ソースデータとその開始理由

• 15チャンネルの容量制限があるSIPトランクがオフィスに到着し、通信事業者が10個の番号を割り当てました。
• オペレーターのキャビネットには「鉄」のVoIPゲートウェイがあり、そこからFXSポート回線が機器に接続されています。
• 実際、「機器」は、オブジェクトセキュリティシステムから連絡先IDメッセージを受信し、ディスパッチャ作業プログラムに転送できる、さまざまなメーカーの2つの鉄です。

利用可能なソリューションの短所：

• 余分な変換チェーンVoIPゲートウェイ→アナログ回線→受信検出器。着信信号に品質を追加しません。多くの場合、施設での電話回線の不具合に悩まされます。
• 情報を送信するとき、FXSポートは自然にビジーであり、2番目の呼び出しはそれを通過しないため（また、場合によっては単一のオブジェクトからの情報の転送に数分かかることがあるため）
• 着信番号を判別できない-ゲートウェイは理論的にはそれらを発行できますが、機器は判別できません。
• 適切なログと通話記録の欠如、およびその結果、通信が定期的に失われる「問題」オブジェクトの診断と設定に関する特定の困難。
• この組織の規模では具体的であり、コンソール機器のコストは、受信機が故障した場合に備えて予備を確保する必要があるため複雑になっています。

構成方法と構成

2004年以来、Asteriskディストリビューションにはapp_alarmreceiverモジュールが含まれており、これはリモートコントロールレシーバーをエミュレートするように設計されています。 通常のダイヤルプランコマンドのように呼び出され、着信呼び出しに応答し、イベントを処理して、設定で指定されたパス内のテキストファイルに追加します。その後、これらのファイルを処理する任意のシステムコマンドを呼び出します。 設定時に直面しなければならなかったこと：



はじめに -ログにデータを受信すると、フォームのchannel.cからのメッセージがバンドルに分類され始めました。

[Mar 23 22:58:35] DTMF[636][C-00000009] channel.c: DTMF begin '0' received on SIP/inbound-0000000e [Mar 23 22:58:35] DTMF[636][C-00000009] channel.c: DTMF begin ignored '0' on SIP/inbound-0000000e [Mar 23 22:58:35] DTMF[636][C-00000009] channel.c: DTMF end '0' received on SIP/inbound-0000000e, duration 51 ms [Mar 23 22:58:36] DTMF[636][C-00000009] channel.c: DTMF end emulation of '4' queued on SIP/inbound-0000000e [Mar 23 22:58:36] DTMF[636][C-00000009] channel.c: DTMF end '0' received on SIP/inbound-0000000e, duration 51 ms [Mar 23 22:58:36] DTMF[636][C-00000009] channel.c: DTMF begin emulation of '0' with duration 80 queued on SIP/inbound-0000000e [Mar 23 22:58:36] DTMF[636][C-00000009] channel.c: DTMF begin '1' received on SIP/inbound-0000000e [Mar 23 22:58:36] DTMF[636][C-00000009] channel.c: DTMF begin ignored '1' on SIP/inbound-0000000e [Mar 23 22:58:36] DTMF[636][C-00000009] channel.c: DTMF end '1' received on SIP/inbound-0000000e, duration 51 ms [Mar 23 22:58:36] DTMF[636][C-00000009] channel.c: DTMF end emulation of '0' queued on SIP/inbound-0000000e [Mar 23 22:58:36] DTMF[636][C-00000009] channel.c: DTMF end '1' received on SIP/inbound-0000000e, duration 51 ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DTMF規格は40ミリ秒以上の期間の「数字」をサポートしていますが、アスタリスクはデフォルトで80ミリ秒であり、短い期間のすべての送信はこの値にエミュレートされます。 連絡先IDでは、数字の長さは50〜60ミリ秒として定義されています。 幸いなことに、2012年以降の一般の要望により、channel.cの対応する#DEFINEはasterisk.confのmindtmfdurationパラメーターと重複しており、50に設定した後、この問題は解決されました。



2番目の問題は、受信したデータをどのように保存および送信するかでした。 デフォルトでは、1つのオブジェクトからの転送セッション全体が次の形式のファイルに書き込まれます。

 [metadata] PROTOCOL=ADEMCO_CONTACT_ID CALLINGFROM= CALLERNAME=<unknown> TIMESTAMP=Mon Mar 23, 2015 @ 22:59:17 PDT [events] 6238181401000042 623818340100004C
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、それを処理するために、alarmreceiver.confファイルのeventcmdパラメーターで指定されたコマンドが呼び出されます。 これは2つの理由で私には向いていませんでした：



まず、この場合、イベントは、通信セッションが完了した後にのみ処理のためにディスパッチャに送信されます。 施設で違法なことが実際に発生し、アラームセンサーが次々にトリガーされる場合、そのようなトリガーとその後の復元はそれぞれ新しいイベントを生成し、通信セッションの終了（およびその結果、アラームで戦闘機を送信）が発生します他の誰も施設に留まらないため（そして潜在的に価値のないもの）。



次に、連絡先IDイベント自体はタイムスタンプを提供せず、イベントはディスパッチャに表示され、イベントが到着するとコンソールプログラムのデータベースに書き込まれます。 データベースで「1つの大きなバンドル」でイベントを受信すると、すべてのタイムスタンプが同じになります。将来、オブジェクトの所有者と通信するときに混乱が生じ、実際のイベントの時系列を復元することが困難になります。



このような状況を防ぐために、logindividualeventsパラメーターが作成され、alarmreceiverはイベントごとに個別のファイルを作成します。 しかし、軟膏にハエがありました-彼は別々のファイルを作成しますが、eventcmdはセッションの最後に一度だけすべてを同じように呼び出します。 その結果、彼らは通常の処理メカニズムを拒否し、イベントファイルを含むフォルダーのIN_CLOSE_WRITEルールをincronに追加しました。受信後すぐに処理が開始されました。



3番目に、イベントファイルのメタデータは、着信呼び出しがどの番号から来たかを示しますが、どの番号に来たかは示しません。 また、いくつかの組織的な機能により、独自のデータベースとそれぞれの保護機能を備えたいくつかの独立したディスパッチプログラムがあります。 さらに、異なるオブジェクトからのデータは、異なる着信番号になります。 app_alarmreceiver.cを修正し、そこに追加してast_channelからDNIDを取得し、それを残りのメタデータとともに発行する必要がありました。

さらに処理して転送する

特別な問題はありませんでしたが、ディスパッチプログラムは非常に独自のものであり、原則としてサードパーティ製の機器では動作しません。 しかし、彼女はUDPを介して機器からデータを受信する方法を知っており、処理はAsteriskによって作成されたイベントファイルを解析し、「機器から」パケットを形成し、DNIDに応じて適切なディスパッチャPCに転送する単純なbashスクリプトに要約されます：

 #!/bin/bash dialednum="" exec < $1 while read s do if [ "${s:0:10}" = "DIALEDNUM=" ] then dialednum=${s:10} fi if [ "$s" == "[events]" ] then break fi done while read s do if [ "$s" != "" ] then r=<  hex-,    «»    > if [ "$dialednum" == "xxxxxx" ] then echo $r | xxd -r -p > /dev/udp/192.168.1.xxx/3322 fi if [ "$dialednum" == "yyyyyy" ] then echo $r | xxd -r -p > /dev/udp/192.168.1.yyy/3322 fi break fi done rm -f $1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

利益

記事の冒頭に記載されている「マイナス」はすべて削除されました。 さらに、ログの思慮深い喫煙の後、問題は1つのオブジェクトで解決されましたが、それ以前は定期的に「シャットダウン」していました。 そこに設置された古代の機器は、標準に従って「完全ではない」チェックサムを送信し、正直で正しいハードウェアレシーバーがそれを消化することを拒否したことが判明しました。 新しいバージョンでは、app_alarmreceiver.cのチェックサム検証手順で小さな松葉杖の後にすべてが機能しました。



PSこの記事の内容を適用して少し補足すると、既存のアラームシステムとアスタリスクから独自の受信機を作成し、イベントコードをテキストに復号化して自分に送信することができます。 さらに、施設設備の大部分は同時に複数の番号へのイベントの転送をサポートしているため、これを警察/民間警備員と組み合わせることもでき、そのようなシステムを使用して施設を監視し、警備員の動作を制御できます。 誰か興味があれば、私の経験を喜んで共有します。