Retell が独自のSIP・WebRTCゲートウェイを構築した理由

Retell が独自のゲートウェイを構築する以前は、大手ベンダーが電話やブラウザからの通話を Retell のAIエージェントに接続していました。そのベンダーのプラットフォームでは障害が繰り返し発生し、1件の復旧に平均で約50〜60分かかっていました。私たちには障害をより早く解決する手段がありませんでした。一部の着信は Retell に届かず、システムにはその記録すら残りませんでした。通話が失われていたことを知ったのは、カスタマーサポートへの問い合わせチケットからでした。

すべての通話の品質と可用性を自らコントロールしたいと考え、私たちは独自のSIP・WebRTCゲートウェイを構築しました。2026年10月時点で、Retell の電話およびブラウザ通話の100%をこのゲートウェイが処理しています。

Retell のゲートウェイは、電話網やWebブラウザを Retell のAI音声エージェントに接続するシステムです。電話システムが通話の確立と終了に使う標準規格であるSIP（Session Initiation Protocol）と、ブラウザがリアルタイム音声に使う標準規格であるWebRTC（Web Real-Time Communication）に対応しています。

ゲートウェイは各通話を確立し、音声を伝送して通話の参加者全員に向けてミキシングするほか、転送、ライブモニタリング（スーパーバイザーが通話をリアルタイムで聞く機能）、テイクオーバー（通話中にスーパーバイザーや担当者がAIエージェントに代わって対応する機能）、通話終了を処理します。

この変更を実現するため、私たちは3つのステップでベンダーを置き換えました。

主な成果：

• インフラのレイテンシが50 msから0.5 msへと約90%低下しました。
• 失敗した通話も含め、すべての電話がまず Retell に届くようになりました。
• 通話機能を Retell 独自のリリーススケジュールで提供できるようになりました。

発信者とAIエージェントの間にあるもの

音声AIのデモでは、通常、複雑なシステムの最終段階、つまり聞き取って応答するモデルだけが示されます。しかし本番環境の電話エージェントには、それ以上のものが必要です。モデルの手前には通常、いくつものレイヤーが存在します。これらのレイヤーが、通話がつながるかどうか、音声がどれだけ速く伝わるか、そして障害時に何が起こるかを決定します。

Retell のエージェントへの通話は、次の4つのレイヤーを通過します。

1. PSTN（公衆交換電話網）は世界規模の電話システムです。ブラウザ通話はWebサイトやWebアプリから届きます。
2. セッションボーダーコントローラー（SBC）は、電話の安全な入口です。外部からの通話を受け付け、各通話の行き先を決定します。ブラウザ通話はSBCを経由せず、ゲートウェイに直接接続します。
3. メディアレイヤー。各通話を確立し、音声を双方向に伝送し、参加者全員に向けてミキシングし、転送や通話終了などの通話制御を実行します。電話はSIP経由で、ブラウザ通話はWebRTC経由でこのレイヤーに到達します。Retell では、ゲートウェイがメディアレイヤーにあたります。
4. Retell のAIインフラ。発信者との会話を実行します。

ゲートウェイ導入前は、ベンダーがレイヤー2と3を担当していました。Retell はその間でオーディオリレーと呼ばれるソフトウェアを1つ運用していました。音声はベンダーとリレーの間でパブリックインターネットを経由し（約50 msのホップ）、その後リレーが Retell のAIインフラへ受け渡していました。

ベンダーのプラットフォームが不十分だった理由

ベンダーのプラットフォームはすべての通話の経路上にあったため、その障害は Retell のお客様に直接影響していました。

ベンダーが障害から復旧するまでには平均で約50〜60分かかっていました。一部の障害では、着信がベンダーから Retell まで届きませんでした。失われた通話は通話記録もイベントも私たちのシステムに残さないため、私たち自身で障害を検知する手段がありませんでした。

ベンダーのサービスを利用することには、ほかにも問題がありました。

• お客様の要件がベンダーの対応範囲に左右されるため、サポートされていない機能は提供できませんでした。
• ベンダーのプラットフォームを介してセキュリティやコンプライアンスの要件を満たすことが困難でした。
• パブリックインターネットのホップがすべての通話にレイテンシを上乗せしていました。
• ベンダーへの支払いは年間数百万ドルに達していました。

私たちはほかのベンダーも評価しました。その結果、製品品質をコントロールするには独自のゲートウェイを構築する必要があるという、もともとの考えが裏付けられました。

3つのステップでベンダーを置き換えた方法

各ステップで、通話経路の一部を Retell のインフラに移しました。

Retell のセッションボーダーコントローラーをベンダーの前段に配置

私たちは自社のSBCをデプロイし、すべてのSIPシグナリングをそこに向けました。お客様は電話の送信先をベンダーのアドレスから Retell のアドレスに変更しました。また、Retell のIPアドレスを許可リスト（お客様の電話システムが通話を受け付けるアドレスの一覧）に追加しました。当初、SBCはすべての通話をベンダーに転送していました。

SBCを自社で保有したことで、ルーティングをコントロールできるようになりました。すべての電話がまず Retell のインフラに届くようになり、接続の成否にかかわらず通話を把握できるようになりました。

しばらくの間、通話はより長い経路をたどっていました。Retell のSBCと Retell のAIインフラの間で、各通話はいったん私たちのネットワークを出てベンダーを経由し、再び戻ってきていました。その過程でパブリックインターネットを2回通過していたのです。ブラウザ通話は引き続きベンダーに直接つながっていました。

電話を1%から100%へ段階的にゲートウェイへ移行

次に、ゲートウェイを構築し、Retell のネットワーク内のSBCの背後にデプロイしました。ゲートウェイが稼働すると、各電話はベンダー経由とゲートウェイ経由の2つの経路のいずれかを取れるようになりました。

着信の経路はSBCが、発信の経路は Retell のAIインフラが選択しました。ゲートウェイが処理する電話の割合は、1%、5%、10%、20%、30%、50%、そして100%と段階的に引き上げました。ゲートウェイ経路では、SBCとゲートウェイがともに Retell のネットワーク内にあるため、両者間のホップは約0.5 msです。

Retell のWebRTC SDKでブラウザ通話をゲートウェイへ移行

最後までベンダーに残っていたのはブラウザ通話でした。私たちは独自のWebRTC SDK（ソフトウェア開発キット。WebサイトやWebアプリがブラウザ通話を発信するためのコード）を構築し、ブラウザ通話をゲートウェイ経由でルーティングしました。

ブラウザ通話の移行が完了したことで、ベンダーとオーディオリレーを廃止しました。現在、通話は到着した瞬間から Retell のAIインフラに届くまで、Retell のネットワーク内にとどまります。

移行が難しかった理由

課題は、お客様が依存している動作を一切変えずに、所有権を引き継ぐことでした。難しかったのは、お客様に負担をかけることなく、通話が稼働している最中にベンダーを置き換えることです。移行期間中ずっと、着信、発信、転送、ブラウザ通話、通話制御のすべてが従来どおりに機能し続ける必要がありました。

そのためには、次の4点を維持する必要がありました。

• プロトコルの動作（ゲートウェイが通話の相手側システムとSIPでやり取りする方法）：通信キャリアやお客様の電話システムが、期待どおりの動作を得られる必要がありました。
• 音声のタイミング（通話の各側に音声が届くタイミング）：新たな途切れや遅延なく、音声を双方向に伝送する必要がありました。
• 参加者の権限（通話中に誰が聞き、話し、テイクオーバーを開始できるか）：ライブモニタリングを利用するスーパーバイザーが同じ権限を保持する必要がありました。
• 通話ライフサイクルのセマンティクス（通話がどのように開始、変更、終了するか）：すべての通話が同じ方法で開始、転送、終了し、Retell のシステムに同じイベントを送信する必要がありました。

段階的なロールアウトにより、実際の電話のごく一部で各動作を検証できました。動作に問題がないことを確認してから、初めて割合を拡大しました。

私たちにとっての主な教訓は、このようなゲートウェイ移行の成否は、ルーティングを自社で保有すること、強力なオブザーバビリティ、そして通話ライフサイクル全体をカバーするテストにかかっているということです。オブザーバビリティとは、各通話の状況をリアルタイムで把握できることを意味します。

現在の Retell の通話経路：SBC、ゲートウェイ、WebRTC SDK

新しい通話経路は3つの要素で構成されています。

Retell のSBCは外部との接点です。通信キャリアやお客様の電話システムからSIPシグナリングを受信し、各通話をルーティングします。

ゲートウェイは、かつてベンダーが担っていた処理を行います。通話を確立し、音声を伝送・ミキシングし、通話制御を実行します。Retell のAIインフラとは、サーバー間でリクエストのやり取りやデータのストリーミングを行う2つの標準的な方式であるHTTPとWebSocketで通信します。

Retell のWebRTC SDKにより、WebサイトやWebアプリはブラウザ通話をゲートウェイに直接送信できます。

セキュリティとコンプライアンスの制御は設計の一部として組み込まれています。認証済みアクセス、参加者の権限、機密性の高い音声の取り扱い、機密情報の秘匿化などが含まれます。

ゲートウェイを自社で保有して変わったこと

通話経路を自社で保有するということは、通話品質のあらゆる要素に私たちが責任を持つということです。

通話機能の開発をベンダーに待たされることはもうありません。ある保険業界のお客様は、キャンペーンの1つでSIP BYEメッセージにカスタムSIPヘッダーを付与する必要がありました。SIPヘッダーとは、通話とともに追加情報を伝えるフィールドです。BYEメッセージは通話を終了させるシグナルです。当時ベンダーはBYEメッセージへのカスタムヘッダーに対応していなかったため、私たちはこの機能をゲートウェイに実装しました。コードとリリースプロセスを自社で管理しているため、独自のリリーススケジュールで提供できます。

現在では、お客様のセキュリティ要件（HIPAA、SOC 2など）を自社で満たすことができます。また、お客様の必要に応じて、Retell は新しいクラウドリージョンにゲートウェイをデプロイすることも可能です。

自社構築が誤った選択となる場合

リアルタイム通信インフラを運用するだけのエンジニアリング体制がないチームや、それを正当化する製品要件がないチームにとって、ゲートウェイの構築は適切なプロジェクトではありません。

私たち自身の取り組みも、リリース後も続いています。ゲートウェイの運用には、熟練したチームに加えて、次の領域への継続的な投資が必要です。

• 電話の相互運用性
• ネットワーク
• メディア処理
• セキュリティ
• モニタリング
• オンコール運用

電話の相互運用性とは、ゲートウェイが接続する多数の通信キャリアや電話システムとの互換性を維持し続けることを意味します。

ゲートウェイを自社で保有することは、障害対応、キャパシティプランニング、保守、安全なデプロイにも責任を持つことを意味します。Retell がこの投資を行ったのは、通話品質、可用性、カスタマイズ性、そして迅速な改善が私たちの製品の中核だからです。

同じ取り組みを行うチームへのアドバイス

独自のゲートウェイを構築する場合に、私たちがうまくいったと感じた方法をご紹介します。

1. メディアレイヤーを置き換える前に、まずSIPの入口をコントロールし、ルーティングを管理してすべての電話を把握できるようにします。
2. SBCの背後にゲートウェイを構築し、電話を段階的に移行します。
3. SDK、認証、接続の確立、音声伝送を含む完全なインテグレーションとしてブラウザ通話を扱います。
4. Retell のゲートウェイで実践したように、最初からセキュリティとコンプライアンスの制御を組み込みます。
5. アプリケーションに届く前に失敗した通話も含め、移行期間全体を通じてレイテンシ、音声品質、障害時の挙動を計測します。

電話システムを Retell に接続する

電話関連の要件が音声AIの導入の妨げになっている場合は、カスタムテレフォニーガイドからお始めください。SIPトランク（2つの電話システム間の直接的なSIP接続）を介して電話システムを Retell に接続する方法や、許可リストに追加すべき Retell のアドレスを説明しています。その他の技術的な内容については、Real-Time Reliability、Retell Workflows、Retell Memoryに関する記事もぜひご覧ください。

大量の通話を処理している場合や、厳格なコンプライアンス要件に対応している場合は、私たちのチームにご相談ください。