まえがき
この記事は、アスタリスクに基づいたテレフォニーサーバーとCRMシステムの統合について説明します。
この記事では 、AsteriskサーバーのセットアップやCRMシステムのニュアンスに関連する問題については取り上げておらず 、すべての長所と短所との相互作用を整理するための一般的なオプションのみが考慮されています。
はじめに
企業がCRMを「自分たちのために」開発する方法や独自の電話は、技術的な問題ではなく政治的な問題であるため、「なぜ」という質問に答えることはできません。 しかし、事実は変わりません。ある日、電話部分とCRMの相互作用を保証できるソリューションが必要でした。
ソースデータ：
- 遠く離れた2つのコールセンター（以下-KC）（ロシア連邦に1つ、エストニアに2つ目）
- それぞれ約500人の同時作業オペレーター（着信および発信）
- 1つのエントリポイント（簡単にするために、CRMサーバーが1つしかないことを考慮してください）
- ロシア連邦の両方のKCプロセス呼び出し
- 各CCには独自のAsteriskサーバーがあります（簡単にするために、すべてのAsteriskが構成され、完全に機能するモードになっていると仮定します）
- CRMは、Web銃口を持つクライアントサーバーアプリケーションです。
なすべきこと：
- 1つのエントリポイント、つまり、 オペレーターの作業インターフェースから
- アスタリスクからの呼び出しに関するデータ（呼び出し時間、呼び出し時間、ステータスなど）を受信する
- 電話の十分な安定性を確保します（「安定性」のさまざまな側面については後で説明します）
実装オプション
WebRTC / Web-SIP
最初に思いついたのは、ブラウザーに直接「ダイヤラー」を実装することでした（CRMとのやり取りはWebインターフェースを介して実行されることを覚えています）。 そして、ここでは、WebRTC仕様だけが、人気のあるブラウザー用のプラグインに間に合いました。
このアイデアは間違いなく優れていますが、ブラウザをフリーズ/閉じたり、ページを更新したりすると、接続、通話、クライアントが失われるため、ビジネスには適していません。
同じ理由で、「クラシック」SIP Webクライアントはいずれも選択されませんでした。
SIP電話+ AGI + Webソケット
別個のSIP電話機を使用するという考え方は、ビジネスにとって明らかな利点があります。予期せぬ状況では、通話を保存できます。 CRMとの対話を保証することは困難ですが、これは解決可能なタスクです。
サイフォンにオペレータインターフェースから呼び出すことを教えることは残っています。
コンピュータのサイフォンがブラウザから発信を行う方法を教えてください。 まさか？ そうです。
そのため、AGIインターフェースを介してアスタリスクコマンドを送信し始めました。これにより、彼は加入者への発信コールを整理し、オペレーターのチャネルに接続しました。 したがって、サイフォンの場合、発信コールは、テレフォニーサーバーからの自動応答コマンドで着信コールになりました。
すべてが正常になり、オペレーターはCRMシステムの特定のエッセンスを使用して作業を開始し（簡単にするために「呼び出し」と呼びます）、agiを介して「発信」呼び出しを開始するコマンドが手動または自動で送信され、呼び出しの最後にアスタリスクが呼び出しに関する情報を送信しました（オプションGETリクエストからWebSocketまで）。
ロシアでの発信電話の実装フェーズは粗さではなく、むしろ成功しました。その後、着信コールの処理を開始する必要がありました。
サイフォン経由ではなく、インターフェイスからの着信コールを受け入れるようにオペレータに教えることは残っています。
それから、少なくとも呼び出しが正常に受信されるまで、ブラウザで直接アスタリスクで作業を開始する必要がありました。その結果、Web Socketサーバーがテレフォニーサーバーに表示されました。
したがって、オペレーターへの着信呼び出しに関する情報はブラウザーに直接送られ、残りのコマンドはCRMサーバーを経由してAGIインターフェイスを経由してアスタリスクに送信されました。
CRMサーバーを介してテレフォニー管理を編成する決定は、次の要件に関連していました。
- 安全性 登録されているキューのオペレーター、コールの現在のステータスを表示したくありませんでした。 オペレーターは決定を下さないので、彼にとっては十分な情報が得られます。
- 1つのエントリポイント。 1つのポイントからすべてのテレフォニーサーバーを管理し、ここで情報を統合します。
- データの同期受信と処理。 インターフェースの状態は、データをオペレーターに（ブラウザーで）送信する前に既知です。
上記のスキームはロシアで非常にうまく機能しましたが、エストニアのKCがCRMシステムを介して電話をかけ始めたとき、AGIの不適切な操作に起因する電話に関する多くの問題が見つかりました。 Estonian AsteriskのパッケージはCRMサーバーに到達しませんでした。その結果、コマンドの実行に関する情報を受信できず、チームがまったく到達したかどうかはわかりませんでした。
1週間後、状況が改善されないことが明らかになり、ロシアとエストニアのサーバー間の通信の品質に影響を与えることはできませんでした。その結果、Web Socketを介して電話管理に完全に切り替えるという強い意思決定が行われました。
1週間後、各アスタリスクが独自のWebソケットサーバーを持ち、オペレーターのブラウザーが同じローカルネットワーク内で接続するという作業スキームを取得しました。 CRMサーバーはそのままで、ロシア連邦に残りました。
したがって、テレフォニーサーバーとのオペレーターインターフェースの通信は、遅延なしに同じローカルネットワーク内で行われ、すべてのテレフォニー管理コマンドとイベントが送信され、オペレーターのブラウザーに戻ります。
CRMとテレフォニーの相互作用は、アスタリスクからのコールバックを介して直接行われ、操作パネルからの非同期リクエストを介して間接的に行われます。
合計
- 発信コールでのみ同じローカルネットワーク内の小さなCCの動作を保証する必要がある場合、AGIを介した統合のみの実装が可能です。
- 前の段落に加えて、着信呼び出しを受信する必要がある場合は、AGI + Web Socketを組み合わせたバージョンが最適です。
- 「クリーン」なWebソケットのオプションは唯一の選択肢であり、複数の国または地域内の分散データセンターの機能を保証する一方で、Asterisk AGIインターフェースは、 （同じマシン上の）ローカル接続内で、同じローカルネットワーク内でさらに悪化し、他のすべての場合で非常に悪い。 この方法ではパケットを失わず、接続を切断しないため、Web SocketサーバーはAsteriskを搭載したマシンで動作します。
PS残念ながら、Chukchiはあまり芸術家ではなく、現在一般的な相互作用のパターンを描くのに十分な時間はありませんが、読者が記事で提起された問題に興味がある場合はそうすることを約束します。