あるプロジェクトのストーリー、またはアスタリスクと Php をベースにした PBX の作成に 7 年を費やした方法

確かに、私と同じように、何かユニークなことをしたいというアイデアを持っている人はたくさんいるでしょう。 この記事では、PBX の開発時に直面した技術的な問題とその解決策について説明します。 おそらくこれは、誰かが自分のアイデアを決定するのに役立ち、誰かがよく踏まれた道をたどるのに役立つでしょう。私も先駆者の経験から恩恵を受けたからです。

アイデアと主要な要件

そしてそれはすべて単にへの愛から始まりました アスタリスク (通信アプリケーションを構築するためのフレームワーク)、電話とインストールの自動化 FreePBX (ウェブインターフェース アスタリスク）。 企業のニーズが具体的ではなく、能力の範囲内である場合 FreePBX - すべてが素晴らしいです。 設置全体は XNUMX 時間以内に完了し、同社は設定済みの PBX、ユーザーフレンドリーなインターフェイス、および必要に応じて短いトレーニングとサポートを受けました。

しかし、最も興味深いタスクは標準的ではなく、それほど素晴らしいものではありませんでした。 アスタリスク は多くのことができますが、Web インターフェイスを正常に動作し続けるには、何倍もの時間を費やす必要がありました。 そのため、細かい部分を修正すると、PBX の残りの部分を設置するよりもはるかに時間がかかる可能性があります。 重要なのは、Web インターフェイスの作成に長い時間がかかるということではなく、むしろ重要なのはアーキテクチャ上の機能にあります FreePBX。 アーキテクチャのアプローチと手法 FreePBX php4 の時点で策定され、その時点ではすでに php5.6 があり、すべてをよりシンプルかつ便利にすることができました。

最後の課題は、図の形式のグラフィカルなダイヤルプランでした。 このようなものを構築しようとしたとき、 FreePBX、大幅に書き直す必要があり、新しいものを構築する方が簡単であることに気づきました。

主な要件は次のとおりです。

• シンプルなセットアップで、初心者の管理者でも直感的にアクセスできます。 したがって、企業は当社側でPBXのメンテナンスを行う必要がなく、
• タスクを適切な時間内に解決できるように簡単に変更できます。
• PBXとの統合が容易です。 U FreePBX 設定を変更するための API がありませんでした。 たとえば、サードパーティ アプリケーションからグループや音声メニューを作成することはできません。API 自体からのみ作成できます。 アスタリスク,
• オープンソース - プログラマーにとって、これはクライアント向けに変更を加える上で非常に重要です。

開発を迅速化するという考えは、すべての機能をオブジェクトの形式のモジュールで構成することでした。 すべてのオブジェクトには共通の親クラスが必要でした。これは、すべての主要な関数の名前がす​​でにわかっているため、デフォルトの実装がすでに存在することを意味します。 オブジェクトを使用すると、文字列キーを含む連想配列の形式で引数の数を大幅に減らすことができます。これについては、次のとおりです。 FreePBX 関数全体と入れ子関数を調べることで可能でした。 オブジェクトの場合、平凡なオートコンプリートですべてのプロパティが表示され、一般に作業が何倍も簡素化されます。 さらに、継承と再定義により、変更に関する多くの問題がすでに解決されています。

次に、再作業時間を遅くするものであり、避ける価値があるのは重複です。 従業員にダイヤルするモジュールがある場合、従業員に電話をかける必要がある他のすべてのモジュールはそれを使用する必要があり、独自のコピーを作成する必要はありません。 したがって、何かを変更する必要がある場合は、XNUMX か所のみを変更する必要があり、「どのように機能するか」の検索は XNUMX か所で実行する必要があり、プロジェクト全体で検索する必要はありません。

最初のバージョンと最初のエラー

最初のプロトタイプは XNUMX 年以内に完成しました。 計画どおり、PBX 全体はモジュール式であり、モジュールは通話を処理するための新しい機能を追加するだけでなく、Web インターフェイス自体を変更することもできました。

はい、そのようなスキームの形でダイヤルプランを構築するというアイデアは私のものではありませんが、非常に便利なので、私も同じようにしました アスタリスク.

モジュールを作成することで、プログラマーはすでに次のことを行うことができます。

• 通話処理用の独自の機能を作成し、図上や左側の要素のメニューに配置できます。
• Web インターフェース用に独自のページを作成し、既存のページにテンプレートを追加します (ページ開発者がこれを提供している場合)。
• 設定をメイン設定タブに追加するか、独自の設定タブを作成します。
• プログラマは既存のモジュールを継承したり、機能の一部を変更して新しい名前で登録したり、元のモジュールを置き換えたりできます。

たとえば、次のようにして独自の音声メニューを作成できます。

......
class CPBX_MYIVR extends CPBX_IVR
{
 function __construct()
 {
 parent::__construct();
 $this->_module = "myivr";
 }
}
.....
$myIvrModule = new CPBX_MYIVR();
CPBXEngine::getInstance()->registerModule($myIvrModule,__DIR__); //Зарегистрировать новый модуль
CPBXEngine::getInstance()->registerModuleExtension($myIvrModule,'ivr',__DIR__); //Подменить существующий модуль

最初の複雑な実装は、最初の誇りと最初の失望をもたらしました。 うまく機能し、主な機能をすでに再現できたことがうれしかったです FreePBX。 人々がこの計画のアイデアを気に入ってくれたことがうれしかったです。 開発を簡素化するためのオプションはまだたくさんありましたが、その時点でさえ、一部のタスクはすでに簡素化されていました。

PBX 構成を変更するための API は残念でした。結果は私たちが望んでいたものではありませんでした。 と同じ原理を採用しました FreePBX、「適用」ボタンをクリックすると、構成全体が再作成され、モジュールが再起動されます。

これは次のようになります。

*ダイヤルプランは、通話が処理されるルール (アルゴリズム) です。

ただし、このオプションを使用すると、PBX 設定を変更するための通常の API を作成することはできません。 まず、変更を適用する操作 アスタリスク 長すぎてリソースを大量に消費します。
次に、XNUMX つの関数を同時に呼び出すことはできません。 どちらも構成を作成します。
XNUMX 番目に、管理者が行った設定を含むすべての設定が適用されます。

このバージョンでは、次のように アスコジアでは、変更されたモジュールのみの構成を生成し、必要なモジュールのみを再起動することは可能でしたが、これらはすべて中途半端な対策です。 アプローチを変える必要がありました。

XNUMX 番目のバージョン。 鼻が抜けた尻尾が詰まっている

問題を解決するためのアイデアは、構成とダイヤルプランを再作成することではありませんでした。 アスタリスクただし、情報をデータベースに保存し、通話の処理中にデータベースから直接読み取ります。 アスタリスク データベースから設定を読み取る方法はすでに知っていました。データベース内の値を変更するだけで、次の呼び出しは変更を考慮して処理されます。この関数はダイヤルプランのパラメーターを読み取るのに最適でした。 REALTIME_HASH.

結局再起動する必要もなかった アスタリスク 設定を変更すると、すべての設定がすぐに適用され始めました アスタリスク.

ダイヤルプランへの唯一の変更は、内線番号と ヒント。 しかし、これらは小さな点的な変化でした

exten=>101,1,GoSub(‘sub-callusers’,s,1(1)); - точечное изменение, добавляется/изменяется через ami

; sub-callusers – универсальная функция генерится при установке модуля.
[sub-callusers]
exten =>s,1,Noop()
exten =>s,n,Set(LOCAL(TOUSERID)=${ARG1})
exten =>s,n,ClearHash(TOUSERPARAM)
exten =>s,n,Set(HASH(TOUSERPARAM)=${REALTIME_HASH(rl_users,id,${LOCAL(TOUSERID)})})
exten =>s,n,GotoIf($["${HASH(TOUSERPARAM,id)}"=""]?return)
...

次を使用すると、ダイヤルプランの回線を簡単に追加または変更できます。 アミ (制御インターフェース アスタリスク)、ダイヤルプラン全体を再起動する必要はありません。

これにより、構成 API の問題が解決されました。 データベースに直接アクセスして、新しいグループを追加したり、たとえばグループの「ダイヤル時間」フィールドのダイヤルアップ時間を変更したりすることもできます。そうすれば、次の通話はすでに指定された時間続くことになります (これは推奨事項ではありません)。一部の API 操作ではアクションが必要となるため、 アミ 電話)。

最初の困難な実装では、再び最初の誇りと失望がもたらされました。 うまくいってよかったです。 データベースがクリティカル リンクになり、ディスクへの依存度が高まり、リスクが増加しましたが、すべてが安定して問題なく動作しました。 そして最も重要なことは、Web インターフェイスを通じて実行できるすべての操作が API を通じて実行できるようになり、同じメソッドが使用されるようになったということです。 さらに、管理者が忘れがちだった「PBX に設定を適用」ボタンが Web インターフェイスから削除されました。

残念だったのは、開発がより複雑になったことです。 最初のバージョン以来、PHP 言語は次の言語でダイヤルプランを生成してきました。 アスタリスク 見た目も言語自体も全く読めない アスタリスク ダイヤルプランを作成する場合、それは非常に原始的です。

その様子:

$usersInitSection = $dialplan->createExtSection('usersinit-sub','s');
$usersInitSection
 ->add('',new Dialplanext_gotoif('$["${G_USERINIT}"="1"]','exit'))
 ->add('',new Dialplanext_set('G_USERINIT','1'))
 ->add('',new Dialplanext_gosub('1','s','sub-AddOnAnswerSub','usersconnected-sub'))
 ->add('',new Dialplanext_gosub('1','s','sub-AddOnPredoDialSub','usersinitondial-sub'))
 ->add('',new Dialplanext_set('LOCAL(TECH)','${CUT(CHANNEL(name),/,1)}'))
 ->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="SIP"]','sipdev'))
 ->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="PJSIP"]','pjsipdev'))

XNUMX 番目のバージョンでは、ダイヤルプランがユニバーサルになり、パラメータに応じて可能なすべての処理オプションが含まれ、サイズが大幅に増加しました。 これらすべてが開発時間を大幅に遅らせ、またダイヤルプランに干渉する必要があると考えるだけで悲しくなりました。

XNUMX番目のバージョン

問題を解決するためのアイデアは、生成することではありませんでした。 アスタリスク PHPからダイヤルプランを作成して使用する FastAGI すべての処理ルールを PHP 自体に記述します。 FastAGI 許可する アスタリスク、呼び出しを処理するには、ソケットに接続します。 そこからコマンドを受信し、結果を送信します。 したがって、ダイヤルプランのロジックはすでに境界の外にあります アスタリスク どの言語でも書くことができますが、私の場合は PHP です。

たくさんの試行錯誤がありました。 主な問題は、すでにたくさんのクラス/ファイルがあることでした。 オブジェクトの作成、初期化、相互の登録には約 1,5 秒かかりました。呼び出しごとのこの遅延は無視できるものではありません。

初期化は 1 回だけ実行する必要があるため、解決策の検索は、次を使用して php でサービスを記述することから始まりました。 Pスレッド。 XNUMX 週間の実験の後、この拡張機能の仕組みが複雑であるため、このオプションは見送られました。 XNUMX か月のテストの後、PHP での非同期プログラミングも放棄する必要がありました。シンプルで PHP 初心者にとって馴染みのあるものが必要であり、PHP の拡張機能の多くは同期型です。

解決策は、C でコンパイルされた独自のマルチスレッド サービスでした。 PHPLIB。 すべての ATS PHP ファイルをロードし、すべてのモジュールが初期化されるのを待ち、相互にコールバックを追加し、すべての準備ができたらキャッシュします。 お問い合わせの際は FastAGI ストリームが作成され、すべてのクラスとデータのキャッシュからのコピーがその中で再作成され、リクエストが php 関数に渡されます。

このソリューションでは、サービスに呼び出しを送信してから最初のコマンドが送信されるまでの時間が短縮されます。 アスタリスク 時間は 1,5 秒から 0,05 秒に短縮され、この時間はプロジェクトのサイズにわずかに依存します。

その結果、ダイヤルプランの開発時間が大幅に短縮されました。PHP ですべてのモジュールのダイヤルプラン全体を書き直す必要があったので、これは高く評価できます。 第一に、データベースからオブジェクトを取得するためのメソッドがすでに php で記述されている必要があります。それらは Web インターフェイスでの表示に必要でした。第二に、これが重要なことですが、ついに数値と配列を含む文字列を便利に操作できるようになりました。データベースと多くの PHP 拡張機能を備えています。

モジュール クラスでダイヤルプランを処理するには、関数を実装する必要があります。 ダイヤルプラン動的コール そして議論 pbxCallRequest 対話するオブジェクトが含まれます アスタリスク.

また、ダイヤルプランをデバッグできるようになり（phpにはxdebugがあり、弊社のサービスで動作します）、変数の値を確認することで段階的に進めることができます。

通話データ

分析やレポートには正しく収集されたデータが必要ですが、この PBX ブロックも、最初のバージョンから XNUMX 番目のバージョンまで、多くの試行錯誤が行われました。 多くの場合、通話データは兆候です。 XNUMX 回の通話 = XNUMX 回の録音: 誰が電話をかけ、誰が応答し、どのくらい話したか。 さらに興味深いオプションでは、通話中にどの PBX 従業員に電話があったかを示す追加の標識があります。 しかし、これはニーズの一部しかカバーしていません。

初期要件は次のとおりです。

• PBX が誰に電話をかけたかだけでなく、誰が応答したかも保存されます。 傍受があり、通話を分析する際にはこれを考慮する必要があります。
• 従業員と連絡を取るまでの時間。 で FreePBX および他の一部の PBX では、PBX が電話を受けるとすぐに通話に応答したとみなされます。 ただし、音声メニューの場合は、電話を取る必要があるため、すべての電話に応答し、応答までの待ち時間は 0 ～ 1 秒になります。 そこで、応答までの時間だけでなく、主要なモジュール（モジュール自体がこのフラグを設定します。現在は「従業員」、「外線」）に接続するまでの時間を節約することにしました。
• より複雑なダイヤルプランでは、通話が異なるグループ間を移動するときに、各要素を個別に検査できる必要がありました。

最良のオプションは、PBX モジュールが通話中に自分自身に関する情報を送信し、最終的にその情報をツリー形式で保存することであることが判明しました。

これは次のようになります。

まず、通話に関する一般的な情報です (他の皆さんと同様、特別なことは何もありません)。

1. 外線で電話がかかってきました」生地のため「05:55:52に、番号89295671458から番号89999999999まで、最終的には従業員が応答しました。」秘書2» 番号 104。クライアントは 60 秒待機し、36 秒間通話しました。
2. 従業員 "秘書2「112番に電話すると従業員が出た」マネージャー1» 8秒後。 彼らは14秒間話します。
3. クライアントは従業員に転送されます。」マネージャー1” そこで彼らはさらに 13 秒間話し続けます

ただし、これは氷山の一角であり、PBX を通じてレコードごとに詳細な通話履歴を取得できます。

すべての情報は呼び出しのネストとして表示されます。

1. 外線で電話がかかってきました」生地のため» 05:55:52、番号 89295671458 から番号 89999999999 まで。
2. 05:55:53 に、外線が着信回線にコールを送信します。test»
3. スキームに従って通話を処理するとき、モジュール「マネージャーの電話」、通話時間は16秒です。 これはクライアント向けに開発されたモジュールです。
4. モジュール「マネージャーの電話「その番号を担当する従業員（クライアント）に電話を送信します」マネージャー1」と入力し、応答を 5 秒待ちます。 マネージャーは答えなかった。
5. モジュール「マネージャーの電話「グループに電話を送信します」CORPマネージャー」 これらは同じ方向の他のマネージャー (同じ部屋に座っています) で、応答を 11 秒待っています。
6. グループ "CORPマネージャー「従業員に電話をかける」マネージャー1, マネージャー2, マネージャー3「同時に11秒間。 答えはありません。
7. マネージャーの電話が終わります。 そして回路はモジュールに呼び出しを送信します。1cからルートを選択する」 クライアント用に書かれたモジュールでもあります。 ここでは、通話は 0 秒間処理されました。
8. 回線は音声メニューに通話を送信します。基本と追加ダイヤル」 クライアントはそこで 31 秒間待機しましたが、追加のダイヤルはありませんでした。
9. このスキームはグループに呼び出しを送信します。秘書"、クライアントは 12 秒待機しました。
10. グループでは2人の社員が同時に呼び出されます。」秘書1"そして"秘書2「そして 12 秒後に従業員が答えます」秘書2」 呼び出しに対する応答は、親呼び出しに複製されます。 グループの中で彼はこう答えたことがわかりました。秘書2"、回線に電話すると応答されました"秘書2」と外線で電話に出ました。秘書2'。

各操作とそのネストに関する情報を保存することで、簡単にレポートを作成できるようになります。 音声メニューに関するレポートは、音声メニューがどの程度役立つか、または妨げるかを知るのに役立ちます。 従業員が不在着信に関するレポートを作成します。その際、通話は傍受されたため不在とはみなされないこと、また、グループ通話であり、他の人が先に応答していたため、通話も不在ではなかったことを考慮します。

このような情報ストレージを使用すると、各グループを個別に取得して、それがどの程度効果的に機能するかを判断し、時間ごとに回答したグループと欠席したグループのグラフを作成することができます。 また、マネージャーに接続した後の転送を分析することで、担当マネージャーへの接続がどの程度正確であるかを確認することもできます。

また、データベースにない番号が正しい内線番号にダイヤルする頻度や、発信通話の何パーセントが携帯電話に転送されるかなど、非常に特殊な調査を行うこともできます。

その結果は？

PBX の保守には専門家は必要ありません。実際にテスト済みで、ごく普通の管理者が保守できます。

変更には、高度な資格を持つ専門家は必要ありません。PHP の知識があれば十分です。 SIP プロトコル、キュー、従業員への通話などのモジュールがすでに作成されています。 のラッパークラスがあります アスタリスク。 モジュールを開発するために、プログラマは既製のモジュールを呼び出すことができます (そして、良い方法で呼び出す必要があります)。 そして知識 アスタリスク クライアントが新しいレポートを含むページの追加を要求した場合は、これらはまったく必要ありません。 しかし、実際の経験から、サードパーティのプログラマは対処できるものの、文書化やコメントの通常のカバーがないと不安を感じることがわかっており、まだ改善の余地があります。

モジュールは次のことができます。

• 新しい通話処理機能を作成し、
• 新しいブロックを Web インターフェイスに追加し、
• 既存のモジュールのいずれかを継承するか、関数を再定義して置き換えるか、あるいは単にわずかに変更を加えたコピーであるか、
• 他のモジュールの設定テンプレートなどに設定を追加します。

API経由でPBX設定を行います。 上で説明したように、すべての設定はデータベースに保存され、通話時に読み取られるため、API を通じてすべての PBX 設定を変更できます。 API を呼び出すとき、構成は再作成されず、モジュールは再起動されません。そのため、設定数や従業員の数は関係ありません。 API リクエストは迅速に実行され、相互にブロックされません。

PBX は、通話時間 (待機/会話)、ネスト、および PBX 用語 (従業員、グループ、外線、非チャネル、番号) を持つ通話に関するすべての主要な操作を保存します。 これにより、特定のクライアント向けにさまざまなレポートを作成できるようになり、作業のほとんどは使いやすいインターフェイスを作成することになります。

次に何が起こるかは時間が教えてくれるでしょう。 まだやり直す必要のあるニュアンスが多く、計画もたくさんありますが、第 3 バージョンの作成から 3 年が経過し、そのアイデアはすでに機能していると言えます。 バージョン XNUMX の主な欠点はハードウェア リソースですが、通常、これは開発を容易にするために支払わなければならないものです。

出所： habr.com