SIP リンクを設定するには、複雑な統合プロセスが必要です。この記事では、統合プロセスにおけるトラブルシューティングについて説明します。
始める前に
SIP リンクのトラブルシューティングを行うには、以下をご確認ください。
- セッション ボーダー コントローラでのパケット キャプチャ
- ファイアウォールでのパケット キャプチャ
- パケット キャプチャを表示するツール
- セッション ボーダー コントローラ ログへのアクセス
注: トラブルシューティングについてご不明な点がある場合は、ご利用のセッション ボーダー コントローラ ベンダーまたは携帯通信会社にお問い合わせください。
SIP リンクで電波の接続を確認する
SIP リンクのシグナリングでは、Transport Layer Security（TLS）が使用されます。TLS は、Public Certificate Authority（CA）によって作成された証明書のパッケージで構成されます。TLS 接続のステータスは、管理コントロール パネルの SIP リンクのランディング ページで確認できます。
- TLS 証明書が次のいずれかの CA から発行されていることを確認します。
- DigiCert
- Entrust DataCard
- GlobalSign
- GoDaddy
- Sectigo
- まず 3 ウェイ伝送制御プロトコル（TCP）handshake を、次に TLS handshake を開始します。
証明書が交換されると、Voice は証明書とセッション ボーダー コントローラの証明書を送信します。
- これが完了すると、Voice とセッション ボーダー コントローラの間でアプリケーション データを交換できるようになります。
通話品質に関するトラブルシューティング
通話品質に問題がある場合は、ネットワークのレイテンシが低く保たれているかどうかを確認します。Voice のトラフィックが Voice とセッション ボーダー コントローラとの間を最短経路で通過すると、通話品質が最も高くなります。ラウンドトリップのレイテンシを 100 ms 以下にすることを目標とします。
ネットワークのレイテンシをテストするには:
- Voice メディア フロントエンド サーバーに対して、セッション ボーダー コントローラの外部インターフェースから ping します。
- 少なくとも 4 時間 Voice に接続したままにします。
- レイテンシが 100 ms 以下で一定していることを確認します。レイテンシの値を平均化せず、ときどきレイテンシの急増が発生していないか確認します。
- レイテンシが 100 ms を超える場合は、traceroute ユーティリティを使用して、セッション ボーダー コントローラまたはクライアント マシンから Voice メディア フロントエンドまでのネットワーク パスを出力します。パスは短ければ短いほど理想的です。次に例を示します。
- パソコンの場合は、> traceroute lens.voice.google.com または > traceroute 74.125.39.139 を使用します
- Chromebook の場合は、> tracepath lens.voice.google.com を使用します
- セッション ボーダー コントローラの場合は、traceroute siplink.telephony.goog または traceroute lens.voice.google.com を使用します
電波の接続に関する一般的な問題のトラブルシューティング
セッション ボーダー コントローラと Voice の間で TCP セッションを確立できない
TCP セッションが確立されない場合は、ファイアウォールまたはネットワーク接続に問題がある可能性があります。セッション ボーダー コントローラから SYN メッセージを送信できますが、応答がありません。
この問題を解決するには:
- siplink.telephony.google に ping してネットワーク接続が利用できることを確認します。
- Voice の宛先ポート 5672 を有効にします。
- DNS が siplink.telephony.goog の解決のために機能していることを確認します。
- ファイアウォールでセッション ボーダー コントローラからのトラフィックが許可されていることと、siplink.telephony.goog:5672 ポートが開いていることを確認します。
セッション ボーダー コントローラと Voice の間で TLS セッションを確立できない
この問題を解決するには:
- PCA に関連付けられたルート証明書と中間証明書が、SIP リンクの TLS プロファイルに関連付けられたキーストアにアップロードされていることを確認します。セッション ボーダー コントローラの証明書用の CSR を生成する際は、該当するセッション ボーダー コントローラ ベンダーの相互運用性に関するドキュメントに記載されているガイドラインに準拠してください。
- セッション ボーダー コントローラ証明書が次のガイドラインに準拠していることを確認します。
- キーのサイズが 2,048
- RSA または ECDSA による暗号化
- 一般名（CN）が SIP リンク用に作成されたホスト名と一致する
- 証明書に記載された CN のドメインが Workspace のドメインと一致する
- 相互認証が有効
- サーバーとクライアントの認証が有効
- ワイルドカード証明書がサポートされていない
- pki.goog で見つかった Google の証明書 GTSR1 が、対応する SIP リンクの TLS プロファイルのキーストアにもアップロードされていることを確認します。
- セッション ボーダー コントローラから Google への証明書の有効期限が切れていないか確認します。
セッション ボーダー コントローラからの招待時に 404 または 604 Not Found と返される
セッション ボーダー コントローラからの招待時に 404 または 604 Not Found と返される場合は、Voice にセッション ボーダー コントローラ番号が割り当てられていない可能性があります。
この問題を解決するには:
- セッション ボーダー コントローラの電話番号が Voice のユーザー、自動応答、着信グループに割り当てられていることを確認します。
- PAI ヘッダー内の電話番号が E.164 形式であることを確認します。
セッション ボーダー コントローラからの招待時に 400 Bad Request と返される
セッション ボーダー コントローラからの招待時に 400 Bad Request と返される場合は、正しい秘密鍵を使用していない可能性があります。
この問題を解決するには:
- 招待メッセージを調べて、X-Google-Pbx-Trunk-Secret-Key SIP ヘッダーに正しい値が含まれていることを確認します。この鍵は SIP リンクの設定時に生成されます。
- P-Asserted-Identity ヘッダー内の電話番号が E.164 形式であることを確認します。
Voice から 403 Forbidden と返される
メディア接続に関する一般的な問題のトラブルシューティング
メディア接続に関するトラブルシューティングを開始する前に、ネットワークが次の条件を満たしていることを確認してください。
- ネットワークで Datagram Transport Layer Security（DTLS）または Session Description Protocol Security Description for Media Streams（SDES）の暗号化のいずれか（両方ではなく）を使用している。
- 暗号化されていない SDP オファーを使用していない。この方法で発信された通話は自動的に終了します。
- MKI または暗号の期限を無効にする必要があります。
- DTLS を使用している場合は、セッション ボーダー コントローラで自己署名証明書が使用されます。証明書が CA 署名済み証明書である必要はありません。
- サポートされているコーデックのいずれかが、セッション ボーダー コントローラの Voice プロファイル、G711 mulaw（PCMU）、G711 alaw（PCMA）、または Opus、G722 で設定されていることを確認します。
- 電話のイベントとしてデュアルトーン マルチ周波数信号（DTMF）がある。
- 専用のパブリック IP をセッション ボーダー コントローラの外部インターフェースに割り当てます。
- ファイアウォールの送信元と送信先の NAT を設定します。
証明書のネゴシエーション エラー（DTLS）
アラート メッセージ（Level: Fatal, Description: Unknown CA（レベル: 致命的、説明: 不明な CA））が表示される場合は、DTLS に使用される証明書が認定されていない可能性があります。
DTLS ネゴシエーションは、オファーとアンサーの SDP 接続フィールドで指定されたメディア エンドポイント間での証明書の handshake から始まります。成功すると、暗号化された接続を介して、セッション ボーダー コントローラと Google Voice の間でメディアが送信されます。
問題を解決するには、証明書にセッション ボーダー コントローラの自己署名証明書があることを確認してください。Public CA によって署名された証明書は使用しないでください。このような証明書を使用すると UDP 上で断片化し、問題の原因になります。
セッション ボーダー コントローラから Voice への Client Hello メッセージに対する応答がない（DTLS）
DTLS 暗号化を使用している場合、セッション ボーダー コントローラから Voice へ、Client Hello メッセージが何度も届くものの、応答がないことがあります。
問題を解決するには:
- ファイアウォール ポートを調べて、セッション ボーダー コントローラから Voice メディア IP サブネット（74.125.39.0/24）のポート 19305 または 26500 へ、メディアが双方向で送られていることを確認します。
- セッション ボーダー コントローラのパブリック IP の場合: メディアポート <> 74.125.39.0/24:（19302～19308、26500）。詳しくは、SIP リンクのファイアウォール ポートについての説明をご覧ください。
- Google Voice メディア IP へは ping で到達可能なので、その方法でセッション ボーダー コントローラからのネットワーク到達性をテストできます。
セッション ボーダー コントローラから Voice への UDP に対する応答がない
問題を解決するには:
- ファイアウォール ポートを調べて、セッション ボーダー コントローラから Voice メディア IP サブネット（74.125.39.0/24）のポート 19305 または 26500 へ、メディアが双方向で送られていることを確認します。
- セッション ボーダー コントローラのパブリック IP の場合: メディアポート <> 74.125.39.0/24:（19302～19308、26500）。詳しくは、SIP リンクのファイアウォール ポートについての説明をご覧ください。
- Google Voice メディア IP へは ping で到達可能なので、その方法でセッション ボーダー コントローラからのネットワーク到達性をテストできます。
- ネットワーク アドレス変換（NAT）を行う場合、セッション ボーダー コントローラから送信されたポートをファイアウォールで変更しないようにします。ポートが変更されると、Voice はセッション ボーダー コントローラから送信されたメディア パケットをドロップします。これは、送信元がセッション ボーダー コントローラのパブリック IP であり、ネゴシエートされた SDP のオファーおよびアンサーのポートとは異なると認識されるからです。
パケットが双方向で送られているが、通話中の音声は送られない
Google が招待状に 486（SDES）で応答する
招待状に SIP リンクでサポートされていない MKI が含まれている場合は、MKI を無効にします。
関連トピック
Google、Google Workspace、および関連するマークとロゴは、Google LLC の商標です。その他すべての企業名および商品名は、関連各社の商標または登録商標です。
