私の会社は、5,000を超えるIPステーション（従業員が使用する電話セット）を備えたロシア連邦の領土に分散した電話ネットワークを使用しています。 タスクは、内部サブスクライバー（タンデムコールを含む）からの発信外部（PSTNに向けられた）コールのロガーを作成し、それに続いて関税機能を追加することでした。 内部通話（電話ネットワーク内）と着信通話は重要ではありませんでしたが、説明した情報収集方法を使用すると、これらの種類の通話を処理できます。 通話料金を請求するための既製の商用ソリューションがいくつかありますが、当社ではそれらの一部をテストしましたが、これらの製品のコストは使いやすさと実装の品質のレベルと一致しませんでした。
特定のポイントの実装の詳細が興味深い場合は、別の記事でさらに詳しく説明して、これをオーバーロードしたり、PMで伝えたりしないようにします。
理論
CDRは、 Legacy（従来型）CDRとSurvivable CDRの 2つのタイプに分けられます。 最初のタイプは、より便利で柔軟なメカニズムが登場するまで、主にCMの初期リリースで使用されていました-Survivable CDR。 違いは、第1の実施形態では、すべてのCDRデータがネットワークを介していわゆるCDR付属物に 「ブロードキャスト」され（CDRリンクを受信ホストのIPアドレスにバインドすることにより）、2番目に、蓄積されたすべての情報がPBXサーバーのESSまたはLSPのハードディスクに書き込まれることです。 クライアントがCDRリンクの反対側にある場合（「 ロガー」と呼びます）、レガシーCDRは「リスニング専用」モードで動作します。このモードでは、特定のポートにテキスト形式で到着するテキストストリームを受信します。 何らかの理由でロガーが情報の受信を停止した場合、サーバーはバッファにデータを蓄積し始め、その完了時にCDRリンクがダウンします。 そして、その瞬間から、通話に関するすべての情報は記録されなくなり、収集されたデータにギャップが生じます。 Survivable CDRの場合、すべてが異なります。CDRデータはディスクにテキストファイルとして書き込まれ、ファイル数が一定の制限に達すると手動または自動で削除されるまでそこに保存されます。 レガシーCDRの場合、1つではなく2つのCDRリンク（異なるホスト上の2つの独立したロガー、メカニズムの信頼性を高める）を使用できますが、2番目の収集方法はより便利で信頼性が高くなります（1つ目の方法は、たとえばCMバージョンがPBXはSurvivable CDRをサポートしていません。
レガシーCDRの場合、任意のネットワークロガー（少なくとも自己記述型）-ネットワークポートから読み取ったデータを収集して処理するプログラムを使用できます。 ADVANCED PBX DATA LOGGER-非常に強力で高品質で直感的なロガーを使用しました。このロガーは特定のポートから情報を受信し、カスタムテンプレートに従って解析し、消化可能なデータを問題なくデータベースまたはファイルに送信するように構成できます。 さらに、私たちのPBXによって送信されるデータの形式の説明と引き換えに、この製品のライセンスを取得できるほど幸運でした:)最初のCDRフィードバックテストには、 Netcatユーティリティも役立ちます。これにより、ネットワークポートのデータを「聞く」ことができます。
Survivable CDRの場合、サードパーティのロガーの構成を処理したり、独自の自転車を作成したりする必要はありません。SFTPを介してサーバーに接続し、テキストファイルを受信して解析し、受信したデータをデータベースに追加できるスクリプト言語の知識があるだけです。 たとえば、このためにPHPを使用できます。これは、関税のWebインターフェースを整理するのにも役立ちます。 同じスクリプトを使用して、処理されたすべてのファイルをサーバーから削除できます。 何らかの理由でスクリプトが時間どおりに機能しない場合、データは長時間にわたって蓄積し（レガシーCDRと比較して、多数の呼び出しでバッファーが数時間オーバーフローする）、後で完全に受信できます。
出力形式の説明、Survivable CDRファイルの命名規則、および必要なすべてのCM設定は、 Avaya Aura機能の説明と実装ドキュメントに記載されています（ 公式サポートサイトで簡単に見つけることができます ）。 厳密に定義されたフィールドを目的の順序で返すようにCMを構成できます（いわゆるFormated Output ）。
関税
そのため、CMはCDRデータをロガーに送信するように構成され、すべての情報は構造化された方法でデータベースに蓄積されます。 ここで、セキュリティで保護された通話に課金し、すべての情報を美しく便利な方法で表示する必要があります。 ここではWebプログラミングの経験が役に立ちました。PHPおよびJS言語を使用して、課金システムのWebインターフェースを作成しました。
最初に、さまざまなインターネットソースから電話番号のプレフィックスのテーブルを収集しました。これを利用して、ロシア連邦とそれに対応する連邦地区の主題である通話方向が決定されます。 プレフィックステーブルが使用され、大規模な通信事業者（ MTT 、 Rostelecom 、 Comstarなど）のWebサイトやWikipediaで利用できます。
次に、会社で使用される通信事業者からの情報に基づいて、各トランクグループについて、トランクグループを介して各サブジェクトに1分間の通話のコストを設定する料金表が編集されました。 ここでは、次の困難が生じました。1人の被験者内の固定電話番号への通話は、被験者の所属ではなく、都市までの距離に応じて課金されるため、費用が異なる場合があります。 そのようなエンティティを個別のゾーンに分割する必要がありました。たとえば、モスクワ地域を地区に分割するためです。 一般に、料金表をコンパイルするタスクは、電話プロバイダーが料金を提供する形式に応じて個別に解決されます。 理想的には、もちろん、各エンティティまたは都市に規定された価格の表を達成する必要がありますが、これは常に可能とはほど遠いです。
ロガーによって収集されたデータは、プレフィックスとタリフのテーブルを介して実行され、各コールに対して、方向とコストのフィールドが追加されます。
このPBXのCDRの機能の1つは、6秒間隔で通話時間を切り上げることです。 別の重要なポイント：呼び出しログを異なるデータベーステーブルに分割するタスクが発生します（データ量に応じて、たとえば、毎月新しいテーブルを作成できます）-そうしないと、データベースからの選択が長すぎます。
Active Directoryから内部番号（内線番号）の所有者に関するデータを取得するためのメカニズムが、料金表に追加されました。 通話の日付/時刻、継続時間、発信元と受信先の加入者数などによる表示データのフィルタリングメカニズムも実装されています。 -CDRで指定されたフィールドのいずれか（コールタイプ、アカウントコード、FRLなどを含む）に従って選択できます。
したがって、Avaya PBXに独自のロガーや発信コールレート計算機を実装したいHabréの専門家がいる場合は、自分の経験を最大限に活用する準備ができています。