--- title: "VoIPプロバイダーを接続" description: "すでに使用しているプロバイダー（APIキーによるTwilioまたはTelnyx、SIP経由のSignalWire、Vonage、Plivo、または任意のSIPトランク）を接続するか、ガイド付きセットアップで新しいTelnyxアカウントを開設します。" --- 本番トラフィックには、所有する電話番号を自社の VoIPプロバイダー経由で使用してください。ダッシュボードの **接続 → VoIP** ページ (`/dashboard/voip-connections`) でプロバイダーアカウントを接続します。接続後、 着信**と発信**通話に対応した電話番号をインポートできます。 **新しい接続**をクリックし、次の 2 つの方法から選択します。**現在利用しているプロバイダーに接続**、または **新しい Telnyx アカウントを設定**。 ## すでに利用しているプロバイダーに接続 番号を利用しているプロバイダーを選択します。 | プロバイダー | 接続方法 | |----------|-----------------| | Twilio | API キー: Account SID と Auth Token を貼り付け | | Telnyx | API キー: v2 API キーを貼り付け | | SignalWire | SIP 設定 | | Vonage | SIP 設定 | | Plivo | SIP 設定 | | その他のプロバイダー | 他の通信事業者または運用中の PBX 向けに、ThunderPhone の設定アシスタントを使用した SIP 設定 | Twilio と Telnyx では、認証情報を貼り付けて **接続してテスト** をクリックします。ThunderPhone が認証情報を検証し、プロバイダー側を 設定します。 Telnyx では、ThunderPhone が Telnyx アカウントに独自の SIP 接続を 1 つ追加し （名前は `thunderphone-production--outbound-`）、それを通じて 発信通話を行うため、Telnyx はその通話をアカウントに請求します。番号が 接続されている Telnyx 接続の発信音声プロファイルを使用するため、その プロファイルで許可されている国と利用上限が適用されます。その接続に 発信音声プロファイルがなく、アカウントで有効なプロファイルが 1 つだけの場合、 ThunderPhone はそのプロファイルを使用します。別のプロファイルを使用するには、 Telnyx ポータルでその接続にプロファイルを割り当て、ThunderPhone の 接続を再度保存します。アカウントに有効なプロファイルがない場合、 または複数ある場合は、Telnyx ポータルで接続にプロファイルを割り当て、 ThunderPhone の接続を再度保存します。それまでの間、発信通話は `outbound_trunk_unavailable` で失敗しますが、着信通話は引き続き機能します。 Telnyx が発信通話を拒否する場合（たとえば SIP 403 Forbidden）、その拒否は Telnyx アカウントから行われています。一般的な原因は、利用可能なクレジットがない、 発信者番号がその Telnyx アカウントに存在しない、または発信音声プロファイルで 宛先の国が許可されていないことです。 ### SignalWire、Vonage、Plivo の SIP 設定 この 3 つでは、上部にそのプロバイダー向けの手順、プロバイダー独自の 設定ガイドへのリンク、SIP ドメインの例が表示された [手動 SIP フォーム](#manual-sip-configuration)が開きます。 - **SignalWire:** 発信通話用の SIP 認証情報を作成し、SIP ドメイン、 ユーザー名、パスワードを入力します。さらに、各番号に着信通話を ThunderPhone SIP エンドポイントへ接続する SWML スクリプトを設定します。 - **Vonage:** SIP Trunking ダッシュボードで発信認証情報を持つトランクを作成し、 ドメイン（たとえば `your-trunk.sip-us.vonage.com`）と認証情報を入力します。 ThunderPhone SIP エンドポイントをトランクの着信 SIP URI として追加し、 番号をトランクにリンクします。 - **Plivo:** 認証情報を持つ発信トランクを作成し、Termination SIP Domain （`.zt.plivo.com`）、ユーザー名、パスワードを入力します。Primary URI が ThunderPhone SIP エンドポイントの後に `;transport=tcp` を付けた値である着信トランクを 作成し、各番号の Application Type をそのトランクに設定します。 結果として、手動で入力した接続とまったく同じようにテストおよび検証される手動 SIP 接続 （API では `provider: "manual"`）が作成されます。接続カードには、たとえば **SignalWire · SIP** のようにプロバイダー名が表示されます。 ## 新しいTelnyxアカウントを設定する プロバイダーがまだありませんか？ガイド付きフローでTelnyx アカウントの作成と接続を行えます。 **Telnyx登録を開く** をクリックしてアカウントを作成し、 「アカウントを作成しました」を確認します。 **APIキーページを開く** をクリックしてキーを生成し、 **APIキー（v2）** に貼り付けます。必要に応じて接続に名前を付けます。 **接続してテスト** をクリックします。ThunderPhoneが認証情報を検証し、 保存前にTelnyx側で必要なリソースをプロビジョニングします。 ### ThunderPhone が Telnyx で設定する内容 独自の Connection ID を入力しない限り、Telnyx のどちらの方法（ガイド付き セットアップと API キーの貼り付け）でも、Telnyx アカウントには同じ設定が残ります。つまり、 `thunderphone-` という名前の SIP 接続が 1 つ作成されます。 これは **FQDN 接続**であり、その FQDN レコードは ThunderPhone の SIP エンドポイントを指し、 インポートしたすべての番号がこの接続に割り当てられます。Telnyx はそれらの 番号への通話を SIP 経由で直接 ThunderPhone に送信します。 - Webhook フィールドは意図的に空です。Webhook、Call Control アプリケーション、TeXML アプリケーション、登録済み SIP 電話はいずれも使用されません。 - インポートした番号を別の接続やアプリケーションに移動したり、 その接続に対してデバイスを登録したりしないでください。 - 接続時に独自の Connection ID を入力した場合、ThunderPhone は 代わりにその接続を使用し、変更することはありません。その接続は ThunderPhone の SIP エンドポイントを指す FQDN 接続である必要があります。 2026 年 8 月 30 日より前は、ThunderPhone が作成した `thunderphone-…` 接続は着信を受けられない **Credential 接続**でした。Credential 接続として 表示されている場合は、サポートにお問い合わせください。変換します。 ## 手動SIP設定 SignalWire、Vonage、Plivo のタイル、および **その他のプロバイダー** の **すべての設定を自分で入力する** から、このフォームを開けます。DIDWW や自身で運用する PBX を含め、どの SIP トランクでも使用できます。接続名、**SIP ドメイン / URI**、 任意のユーザー名とパスワード、ポート、トランスポートを入力します。**詳細 設定** ではメディア暗号化（SRTP）を追加できます。フォームには、トランクが着信通話の送信先として使用する SIP アドレスも表示されます: `sip.thunderphone.com`。 UDP または TCP ではポート 5060、TLS では 5061 を使用します。TLS では、SIP シグナリングは ThunderPhone が通話を処理する LiveKit Cloud まで暗号化されたままです。音声は `sip.thunderphone.com` を経由しないため、SRTP は従来どおり機能します。各通話は E.164 形式の発信先番号に送信し、 リクエストラインと `To` ヘッダーの両方で、`+` を含む同じ番号を使用します。たとえば `sip:+14155550142@sip.thunderphone.com` です。`+` により、 ThunderPhone は適切なリージョンで通話を処理できます（[IP 許可リスト](#ip-allowlisting-and-trunk-authentication)の 注記を参照）。 以前に `.sip.livekit.cloud` アドレスで設定したトランクは、**許可する送信元 IP** が空の間も引き続き動作するため、 変更は不要です。ThunderPhone は これらの設定を LiveKit Cloud 上の専用 SIP トランクのペアに変換します。発信通話は、 接続の番号から認証情報を使用して SIP ドメインに発信され、着信通話は、任意の **許可する送信元 IP** フィールドに 入力しない限り、どのアドレスからでもこれらの番号宛てに受け付けられます。 通信事業者が固定のシグナリング IP を公開している場合にのみ入力してください。誤った、または不完全なリストを指定すると、ThunderPhone は通信事業者からの着信通話を拒否します。主な処理は次の 2 つのボタンで実行します: - **AIセットアップガイドを生成** — 必要なトランク側設定について、プロバイダー固有の手順を作成します。 - **接続をテストして保存** — SIPエンドポイントがパブリックアドレスに解決されること、およびTCP/TLSでは選択したポートで接続を受け付けることを確認してから保存します（UDPホストではDNSチェックのみを実行します）。接続にはまだ番号がないため、この時点では通話を発信できません。実際の確認は番号のインポート時に行われます（以下を参照）。 後から接続を編集すると、保存前に変更した 設定に対して同じチェックが再実行され、その後トランクが再構築され、バックグラウンドで短いテスト通話を使用して接続上のすべての番号が再検証されます。テスト 通話が成功するまで、番号は *プロビジョニング中* と表示されます。*接続済み* 接続で **許可する送信元 IP** のみを変更する場合は異なります。発信通話には影響しないため、 ThunderPhone は着信トランクのリストをすぐに更新し、番号は *有効* のままです。着信通話テストは *未テスト* にリセットされます。 新しいリストで通話を受け付けられることを確認するには、再度テストを実行するか、通信事業者経由で実際の通話を発信してください。リストによりテスト通話が拒否される場合、テストは失敗します。保存済みのパスワードが再表示されることはありません。パスワードを維持するには空欄のままにするか、IP 認証トランクの場合は「保存済みのパスワードを削除」をオンにしてください。 ### IP許可リストとトランク認証 一部の通信事業者（DIDWW、Telnyx の IP 認証接続、ファイアウォールの背後にあるほとんどの PBX）は、許可リストに登録したアドレスからの SIP トラフィックのみを受け入れるか、送信元 IP によって発信通話を認証します。ThunderPhone は 2 種類のアドレスセットを使用します。 **SIP エッジ。** `sip.thunderphone.com` に送信する着信通話は、SIP シグナリングのみを伝送する ThunderPhone の SIP エッジを経由します。最初の INVITE は `sip.thunderphone.com` に送信されます。その後の通話シグナリング（ACK、切断、転送）は、通信事業者と通話を受信したエッジサーバー（`sip-1` または `sip-2`）の間で処理されます。ファイアウォールで SIP シグナリングをフィルタリングしている場合は、UDP および TCP のポート 5060 と TLS のポート 5061 で、3 つすべてを許可してください。 | ホスト | IP アドレス | |------|------------| | `sip.thunderphone.com` | `172.170.39.202` | | `sip-1.thunderphone.com` | `13.86.104.121` | | `sip-2.thunderphone.com` | `20.80.98.90` | **LiveKit Cloud。** すべての通話の音声（RTP）と発信通話の SIP シグナリングは、SIP エッジを経由せず、通信事業者と LiveKit Cloud の間で処理されます。SIP シグナリングとメディアの両方について、以下の **すべての範囲** を許可してください。 {/* generated:livekit-static-ips:start */} {/* 自動生成ブロック — 手作業で編集しないでください。 ソース: scripts/docs-freshness/data/livekit-static-ips.json 再生成: python3 scripts/docs-freshness/generate_livekit_static_ips.py CIはこのブロックを再生成し、差分があると失敗します (scripts/docs-freshness/generators.d/30-livekit-static-ips.sh)。 */} | IP範囲 | |----------| | `143.223.88.0/21` | | `161.115.160.0/19` | | `153.57.128.0/18` | LiveKitはこれらの範囲をRealtime、SIPシグナリングとメディア、Webhookに適用しており、カナダ、EU、インド、日本、米国リージョンで処理される通話をカバーします。固定エンドポイント用のリージョン名: `canada`、`eu`、`india`、`japan`、`us`。 {/* generated:livekit-static-ips:end */} `sip.thunderphone.com` に送信された通話は、対象リージョンで処理されます。`To` ヘッダー内の先頭に `+` が付いた番号で、日本、インド、EU/EEA、英国、またはスイスの国番号を持つものは、そのリージョンに送信されます。それ以外のすべての通話は、ThunderPhone の SIP エッジに最も近い LiveKit リージョン（現在は米国）で処理されます。引き続き `.sip.livekit.cloud` アドレスを指定しているトランクは、発信者に最も近い LiveKit リージョンを経由してルーティングされます。通信事業者が対象リージョン外にある場合、このリージョンも対象リージョン外になることがあります。`sip.thunderphone.com` に移行するか、`.sip.livekit.cloud` の直前にリージョン名を挿入してリージョンを固定してください。例: `.japan.sip.livekit.cloud`。着信番号の照合には影響しません。 トランク自体に関する基本的なルールは次のとおりです。 - **ThunderPhone は登録しません**。通信事業者に SIP `REGISTER` を送信しないため、トランクは登録ではなく、IP ベースおよび/または認証情報（ユーザー名 + パスワード）による認証を設定してください。 - **発信通話には認証情報を使用してください**。通信事業者側でユーザー名/パスワード認証を有効にし、手動 SIP フォームに同じ値を入力してください。IP 許可リストは唯一の対策ではなく、第 2 のレイヤーとして扱ってください。対象リージョン外の宛先への発信通話は、別のアドレスから開始される場合があります。 - **着信は逆方向です**。フォームの任意の **許可する送信元 IP** フィールドには、ThunderPhone がそのアドレスからの通話のみを受け入れるように、*通信事業者の* シグナリングアドレスを入力します。IP アドレスまたは CIDR 範囲を入力してください。ホスト名は一致しません。通信事業者が固定リストを公開している場合を除き、空欄のままにしてください。ThunderPhone は、すべての着信通話について、SIP エッジが認識するアドレスとリストを照合します。そのため、リストを設定したら、通話を `sip.thunderphone.com` に送信してください。リストにないアドレスからの通話、または `.sip.livekit.cloud` アドレスに直接送信された通話は拒否されます。失敗するか、接続後すぐに終了します。 これらの範囲はLiveKitが [リージョン、リージョナルエンドポイント、静的IP](https://docs.livekit.io/deploy/admin/regions/endpoints/)で公開しています。 ThunderPhoneはこのページを毎週確認し、変更があればこのガイドを更新します。 ## 接続後 **電話番号 → 番号を追加 → VoIPプロバイダーに接続** から番号をインポートします（接続画面から直接行うこともできます）。インポートした各番号は、有効化される前に検証されます。手動のSIP接続では、この検証により、**設定した番号からSIPトランクを経由してThunderPhone番号へ**短い（数秒間の）テスト通話が発信されます。これにより、ユーザー名、パスワード、トランスポート、通信事業者の発信ルーティングが実際にすべてテストされます。通信事業者は、この通話を通常の通話と同様に課金します。 通信事業者が通話を拒否した場合、番号は*プロビジョニング中*のままとなり、電話番号ページに通信事業者からの応答が表示されます（例: 「ThunderPhoneの認証情報が拒否されました（SIP 401）」）。接続を修正して、もう一度検証してください。通信事業者がトランクを受け入れても、ルーティングプランがThunderPhoneのテスト番号を対象としていない場合（DIDWWでは「宛先番号がルーティングプランによりブラックリスト登録されています」と応答されます）、番号は*検証済み・通信事業者承認済み*と表示されます。この番号は使用できますが、他の宛先への通話はテストされていません。この通話は、設定した番号としてトランクから通話を*発信*できることを証明します。番号の所有権を証明するものではなく、その番号への通話もテストしません。これらは、以下の任意の着信テストで確認できます。検証済みの番号は着信と発信をサポートしており、[発信キャンペーン](/ja/guides/outbound-campaigns)およびプログラムによる[発信通話](/ja/guides/place-outbound-calls)を利用できます。 ### 着信通話テスト **番号を確認**を選択すると、着信通話もテストできるダイアログが開きます。この テストでは設定した番号に発信し、通話が ThunderPhone に到達することを確認してから、 エージェントを開始せずに切断します。 - **独自の発信 SIP トランクを持つ番号**（手動 SIP 番号、および ThunderPhone が Twilio アカウントで発信通話を設定した後の Twilio 番号）は、まず自分自身に 発信します。ThunderPhone はそのトランクを介して、その番号から同じ番号へ発信します。 ダイアログには、発信前にその旨が表示されます。通話は通信事業者を経由して発信され、 着信ルーティングが正しければ、そのまま ThunderPhone に戻ります。番号自身の発信者 ID で戻ってきたこの 1 回の通話により、通信事業者が ThunderPhone からの通話をその番号として 受け入れることと、その番号への通話が ThunderPhone に到達することの両方を、どの国でも 確認できます。一部の通信事業者は番号から同じ番号への通話を拒否したり接続しなかったり しますが、これはルーティングについては何も示しません。その場合、ThunderPhone は 代わりに自社番号の 1 つから発信します。番号が別の場所へ転送される場合、その電話は 2 回鳴ることがあります。最初は番号自身の発信者 ID、次に ThunderPhone のテスト番号が 表示されます。 - **その他の番号**（および上記のフォールバック）には、ThunderPhone 自身の番号の 1 つから 発信します。現在、ThunderPhone がこの方法で発信できるのは米国およびカナダの番号のみです。 その他の番号では、テストを実行できなかったことが表示されます。自己発信が拒否された場合は、 通信事業者からの応答も表示されます。 通信事業者が途中で発信者 ID を変更すると、ThunderPhone は通話を認識できないため、 エージェントが一時的に応答する場合があります。着信テストは任意です。スキップしても 番号は引き続き使用できます。その場合、電話番号ページには *着信未テスト* と表示され、 後で **テスト** または番号の **着信通話をテスト** メニュー項目から実行できます。 インポート直後には、電話番号ページでも新しい番号の着信通話をテストするよう求められます。 ダイアログで確認するまで発信は行われません。 プロバイダーが番号を別の場所へ送信している場合、ThunderPhone が切断するまで、 その転送先は通話ごとに最大 8 秒間鳴ることがあります。別のものが先に応答した場合 （応答してから転送する Twilio アプリ、電話メニューなど）、テストは転送された通話が ThunderPhone に到達するのを待ちます。自己発信では最大 8 秒、ThunderPhone の番号からの 発信では最大 15 秒です。結果は、接続を変更するか番号を再インポートするまで、番号に （*着信* の成功または失敗として）保持されます。これらの操作を行うと *未テスト* に リセットされます。接続を変更すると、バックグラウンドで発信通話が再確認されますが、 確認なしに番号へ発信することはありません。 ## 着信通話のトラブルシューティング 接続の **テスト** ボタンは認証情報を確認し、検証では発信ダイヤルを確認します。着信を確認するには、上記の着信通話テストを実行するか、電話からその番号に発信して **通話履歴** で通話を確認します。 ブラウザの **通話** テストとボット間シミュレーションは通信事業者を経由しないため、着信が機能しているかは確認できません。電話番号を対象とするシミュレーション（SIP ループバック）は通信事業者経由でその番号に発信するため、応答されれば着信ルーティングも確認されます。 - **自身の携帯通信事業者のメッセージが聞こえる**（たとえば「Verizon へようこそ」や「おかけになった番号は現在使用されていません」）: ThunderPhone に到達する前に通話が失敗しています。プロバイダーのアカウントで番号が有効になっており、ThunderPhone の接続またはトランクに割り当てられていることを確認します。 - **話中音になる、または呼び出し音が鳴り続ける:** プロバイダーは通話を受け付けましたが、配信できませんでした。Telnyx では、Telnyx ポータルで番号の **接続** を確認します。上記で説明した `thunderphone-…` FQDN 接続、または ThunderPhone SIP エンドポイントを指す独自の FQDN 接続である必要があります。Twilio では、番号を Voice webhook や TwiML アプリではなく ThunderPhone SIP トランクに接続する必要があります。 - **通信事業者のログに `404 No trunk found` が表示される**（手動 SIP）: 通話は ThunderPhone に到達しましたが、どのトランクにも一致しませんでした。番号がこの接続にインポートされ、トランクが `sip.thunderphone.com` を指していることを確認します。トランクが `.sip.livekit.cloud` アドレスを指している場合、**許可する送信元 IP** は空である必要があります。リストが設定されている場合、`sip.thunderphone.com` に送信された通話のみ受け付けられます。 - **`sip.thunderphone.com` から `404 Not Found` が返される**（手動 SIP）: 通話が電話番号宛てではないか、リクエスト行と `To` ヘッダーで異なる番号が指定されています。上記のように、両方にダイヤルした番号を送信します。 - **`sip.thunderphone.com` から `403 Forbidden` が返される:** リクエスト行で別のホストが指定されています。たとえば `sip:+14155550142@sip.thunderphone.com` のように、通話の宛先を `sip.thunderphone.com` にします。 - **通話は ThunderPhone に到達するが、誤ったエージェントが応答する、または誰も応答しない:** **電話番号** で番号の着信エージェントを確認します。 アプリ内コパイロットで番号を確認できます。番号への通話が失敗する理由を尋ねてください。Telnyx 接続の場合は、読み取り専用で、組織管理者向けに、Telnyx がその番号に割り当てている接続も確認します。 --- ## 次のステップ 番号追加の完全なフロー、ThunderPhone番号、VoIP。 RESTで同じ接続・インポート・検証フローを実行します。 CSVリスト、発信時間帯、再試行ポリシー。 接続、検証情報、インポートに関するすべてのフィールド。