TalkPadに関する最初の紹介記事が公開されてからほぼ1年が経過しました 。 サービスの運用および開発中に、多くの技術的な問題に遭遇しましたが、そのうちのいくつかは成功裏に克服されました。 今日は、TalkPadサーバー側の配置方法をお伝えしたいと思います。
TalkPadは、プラグインをインストールすることにより、ブラウザから直接固定電話と携帯電話を呼び出す機能を提供するサービスであることを思い出させてください。
それでは、負荷の高い電話サービスのバックエンドをどのように配置できますか？
TalkPadは、いくつかのデータ転送プロトコル上に構築されています。 SIP（セッション開始プロトコル）とSDP（セッション記述プロトコル）を使用してユーザー間のセッションを確立し、メタデータを転送し、RTP（リアルタイムトランスポートプロトコル）を使用して音声データを直接転送します。 接続タスクには他のプロトコル（Jingle、H.323など）がありますが、現在はSIPが最も一般的です。
1.ユーザーの場所
このプロジェクトでは、高性能のOpenSIPSソフトウェアSIPスイッチを使用します。これは、とりわけ、登録データベースについて説明しています。
サーバーが着信呼び出しの送信先を正確に知るために、各クライアントはサーバーにネットワークアドレスとポートを報告するSIP REGISTERメッセージを送信します。 ユーザーがSIP登録で他の人の呼び出しを受け入れることができないようにするには、認証と承認が必要です。
登録データベースは、状態をローカルPostgreSQLに定期的に（タイマーで）リセットすることにより、各OpenSIPSサーバーのメモリに保持されます（メモリ内のデータの同期方法が少し低くなります）。
2.また、ユーザーがNATルーターの背後にいる場合はどうなりますか？
ほとんどすべてのユーザーは、自宅/オフィス/パブリックルーター（NATルーター）の背後にいます。 この場合、クライアントは外部ネットワークアドレスを知りません。 この問題を解決するために、プロトコルSTUN（NATのセッショントラバーサルユーティリティ）があります。 ユーザーのSTUNクライアントは、要求をSTUNサーバー（OpenSIPSモジュールの1つ）に送信するだけで、サーバーはパケットが到着したネットワークアドレスからの情報で応答します。 さまざまなSTUNテストを組み合わせることで、ユーザーは自分のタイプのNATを判別できます。
定義したNATのタイプは、SIPメッセージREGISTERおよびINVITEに記録されます。 一般に、音声トラフィックはP2Pモードのクライアント間で直接行われます。 ただし、ユーザーの1人のNATタイプが対称として定義されている場合、これを行うことはできません。 これを行うために、OpenSIPSはSIPメッセージを書き換えて、ユーザー間のトラフィックがRTPProxyサーバー（OpenSIPSモジュール）を介してルーティングされるようにします。 TalkPad統計によると、サーバーを通過する音声トラフィックは、ユーザーの約28〜30％を通過します。
3. SBCと請求
TalkPadユーザーが互いに通信できるだけでなく、固定電話や携帯電話に電話をかけることができるように、SIPおよびRTPプロトコルを使用して通信する地元の電話サービスプロバイダーと協力しています。
ユーザーのお金の支出を正しく計算するには、ユーザーのSIPメッセージをオペレーターにプロキシするだけでは不十分です。この場合、通話を制御できなくなるからです。 より適切なソリューションは、オペレーターとの新しいSIPセッションを確立することですが、RTPトラフィックがユーザーとオペレーターの間で（または音声トランスコーディングが必要な場合はサーバーを介して）直接ルーティングされるようにします。
これらの機能は、セッションボーダーコントローラー（またはB2BUA）によって実行されます。 OpenSIPSの最新バージョンでは、B2BUAモジュールはすでに統合されています。 または、 Sippy SoftwareのB2BUAを使用できます。 ただし、TalkPadの場合、 YATE -PBXとSBCの機能を自然に組み合わせたクラシックなATC企業Null Teamの使用に決めました 。
YATEの利点の1つは、Extmoduleモジュールです。これにより、拡張機能をPythonで簡単に記述できます。 Twistedは 、非同期イベントを処理するためのエンジンとして使用されます。 これがTalkPadの請求書を作成した方法です。これにより、複数の同時通話の場合でも、ユーザーのバランスを2番目の精度で制御できます。 これは、RADIUSプロトコルに基づいた課金ソリューションと比較しても有利です。
4.フェイルオーバー
図に示すように、TalkPadはDNSバランシングとCARPフォールトトレランスを組み合わせています。
OpenSIPSは、使用するモジュールに応じて、ステートレスプロキシモードとステートフルプロキシモードの両方でプロキシできます。 私たちの場合、これはステートフルであるため、セッション全体で同じOpenSIPSと通信するにはSIPクライアント（voipプラグイン）が必要です。 したがって、SIPクライアントは、起動時に1回DNSレコードを解決し、セッションの終了までそれを使用する必要があります。
各OpenSIPSサーバーは、REGISTERを近隣サーバーに複製し、自身をPathヘッダーに追加します。 これは、クライアントが必要に応じて応答する必要があるアドレスを別のOpenSIPSが認識するために必要です。
OpenSIPS-Server＃1がクラッシュするとどうなりますか？
この場合、サーバー＃2のCARP1インターフェイスは自動的にマスターの位置に切り替わり、DNSレコードの両方のIPアドレスは既にサーバー＃2にルーティングされます。 これは、写真で最も明確に示されています。
YATEサーバーの1つがクラッシュすると、OpenSIPSのロードバランサーモジュールはこの状況を認識し、2番目のサーバーのみを使用します。落ちたサーバーは定期的にチェックされ、有効になったかどうかが確認されます。
2人のユーザーだけが2つの異なるIPをスナップして、ブラウザを介して話すときのスキーム：
5.データベース
このプロジェクトでは、PostgreSQLとオープンソースのSkytoolsスイート （Skypeから）のアプリケーション、pgbouncer接続プーラーとwalmanagerレプリケーションマネージャーを使用します。
この記事では、TalkPadの主な動作ポイントについて簡単に説明しました。 次回は、ブラウザ用のVoIPプラグインのクロスプラットフォーム開発の機能について説明します。
この機会を利用して、TalkPadチームは才能のある売り手、電話をサービスに統合したいパートナー、投資家を積極的に探していることをお知らせします。