事前準備
如要排解 SIP Link 問題，請確認你能執行以下操作：
- 使用 SBC 封包擷取功能
- 使用防火牆封包擷取功能
- 運用工具查看封包擷取項目
- 存取 SBC 記錄
注意：如需疑難排解的額外說明，請與 SBC 供應商或電信業者聯絡。
確認與 SIP Link 的信號連線
SIP Link 的信號傳遞機制會使用傳輸層安全標準 (TLS)。TLS 內含公開憑證授權單位 (CA) 所建立的憑證套件。你可以在管理控制台的 SIP Link 到達網頁中查看 TLS 連線狀態。
- 確認您的 TLS 憑證來自以下任一 CA：
- DigiCert
- Entrust DataCard
- GlobalSign
- GoDaddy
- Sectigo
- 啟動 3 向傳輸控制通訊協定 (TCP) 握手作業，隨後再執行 TLS 握手作業。
憑證交換時，Voice 會先傳送一個憑證，接著才會是 SBC 的多個憑證。
- 這項交換作業開始後，即可在 Voice 和 SBC 之間交換應用程式資料。
排解通話品質問題
如果通話品質發生問題，請確認網路延遲時間短暫且穩定。當 Voice 流量在 Voice 和 SBC 之間的路徑最短時，通話品質最佳。請確保往返延遲時間不超過 100 毫秒。
如何測試網路延遲時間：
- 從 SBC 的外部介面連線偵測 (ping) Voice 媒體前端伺服器。
- 至少與 Voice 保持 4 小時的連線。
- 確認延遲時間穩定維持在 100 毫秒以下。請檢查延遲時間偶爾出現的數值高峰，而非計算平均延遲時間。
- 如果延遲時間高於 100 毫秒，請使用路徑追蹤 (traceroute) 公用程式，輸出從你的 SBC/用戶端電腦到 Voice 媒體前端的網路路徑。這個路徑應盡量簡短，例如：
- 如果是桌機，請使用 > traceroute lens.voice.google.com
- 如果是 Chromebook，請使用 > tracepath lens.voice.google.com
- 如果是 SBC，請使用 traceroute siplink.telephony.goog 或 traceroute lens.voice.google.com
排解常見的信號連線問題
無法在 SBC 和 Voice 之間建立 TCP 工作階段
如果您的 TCP 工作階段尚未建立，可能是防火牆或網路連線問題造成。SBC 或許會傳送 SYN 訊息，但無任何回應。
如要解決這個問題，請按照以下說明操作：
- 連線偵測 (ping) siplink.telephony.google，確保網路連線可用。
- 為 Voice 啟用目的地通訊埠 5672。
- 確認 DNS 能正確解析 siplink.telephony.goog。
- 確保防火牆允許來自 SBC 的流量，且 siplink.telephony.goog:5672 通訊埠已開啟。
無法在 SBC 和 Voice 之間建立 TLS 工作階段
如果 TLS 工作階段並未建立，可能是 PCA 認證問題所致。你或許會收到憑證不明的嚴重警示。
如要解決這個問題，請按照以下說明操作：
- 確認與 PCA 相關聯的根憑證和中繼憑證已上傳到 KeyStore，且該 KeyStore 已與 SIP Link 的 TLS 設定檔建立關聯。產生 SBC 憑證的 CSR 時，請按照個別 SBC 供應商的互通性文件中的規範操作。
- 確認 SBC 憑證符合以下規範：
- 金鑰大小為 2,048
- 提供 RSA 或 ECDSA 加密
- 一般名稱 (CN) 與為 SIP Link 建立的主機名稱相符
- 憑證中的 CN 網域與 Workspace 網域相符
- 已啟用雙向驗證機制
- 已啟用伺服器和用戶端驗證機制
- 不支援萬用字元憑證
- 確保在 pki.goog 找到的 Google 憑證 GTSR1 也已於 KeyStore 中上傳，且該 KeyStore 已由 SIP Link 的 TLS 設定檔指定。
- 檢查從 SBC 到 Google 的憑證是否已失效。
在 SBC 邀請期間出現「404 或 604 Not Found」回應
如果在 SBC 邀請期間收到「404 或 604 Not Found」回應，可能是因為你尚未將 SBC 號碼指派給 Voice。
如要解決這個問題，請按照以下說明操作：
- 確認 SBC 的電話號碼已指派給 Voice 中的使用者、自動總機或來電響鈴群組。
- 確認電話號碼採用 PAI 標頭中的 E. 164 格式。
在 SBC 邀請期間出現「400 Bad Request」回應
如果在 SBC 邀請期間收到「400 Bad Request」回應，可能是因為你使用的密鑰有誤。
如要解決這個問題，請按照以下說明操作：
- 檢查邀請訊息，確認內含標有正確值的「X-Google-Pbx-Trunk-Secret-Key」X-Google-Pbx-Trunk-Secret-KeySIP 標頭。系統會在您設定 SIP Link 時產生這組金鑰。
- 確認電話號碼採用 P-Asserted-Identity 標頭中的 E. 164 格式。
來自 Voice 的「403 Forbidden」回應
如果收到「403 Forbidden」回應，表示在從 SBC 傳送到 Voice 的邀請中，可能有錯誤的要求 URI (RURI)。確認 RURI 的主機為 trunk.sip.voice.google.com。
排解常見的媒體連線問題
開始排解媒體連線問題前，請確認網路符合下列條件：
- 網路採用資料元傳輸層安全標準 (DTLS) 或媒體串流 SDP 安全描述 (SDES) 的加密功能，但未同時使用兩者。
- 您目前未使用未加密的 SDP 提議。系統會自動終止透過這個方式進行的通話。
- 必須停用 MKI 或加密編譯生命週期。
- 若採用 DTLS，使用的會是 SBC 的自行簽署憑證，這不需要是 CA 簽署的憑證。
- 確認在 SBC 的 Voice 設定檔中，已設定下列任一支援的轉碼器：G711 mulaw (PCMU)、G711 alaw (PCMA)、Opus 或 G722。
- 雙音多頻 (DTMF) 是電話形式事件。
- 將專屬的公開 IP 指派給 SBC 的外部介面。
- 設定防火牆的來源和目標網路位址轉譯 (NAT)。
憑證協商失敗 (DTLS)
如果收到警示訊息 (級別：嚴重；說明：不明 CA)，表示用於 DTLS 的憑證可能尚未經過認證。
DTLS 協商程序始於握手作業，該作業會在提議中指定的媒體端點，以及應答 SDP 連線欄位間執行。這項程序成功後，媒體即會透過加密連線在 SBC 和 Google Voice 之間流動。
如要解決這個問題，請確認該憑證具備 SBC 自行簽署的憑證。請勿使用由公開 CA 簽署的憑證，因為這類憑證會導致透過 UDP 進行拆分，從而造成問題。
從 SBC 到 Voice 的 Client Hello 訊息沒有回應 (DTLS)
使用 DTLS 加密功能時，您可能會收到從 SBC 傳送到 Voice 的幾則 Client Hello 訊息，但都沒有回應。
如要解決這個問題，請按照以下說明操作：
- 檢查防火牆通訊埠，確保 SBC 擁有到 Voice 媒體 IP 子網路 (74.125.39.0/24) 通訊埠 19305 或 26500 的雙向媒體流量。
- 如果是 SBC 公開 IP，則適用媒體通訊埠 <> 74.125.39.0/24:(19302-19308、26500)。詳情請參閱「SIP Link 的防火牆通訊埠」一節。
- Google Voice 媒體 IP 可透過連線偵測 (ping) 存取，因此若要測試能否從 SBC 存取，也可採用此方式。
對於從 SBC 傳送到 Voice 的 UDP，我並未收到任何回應
如要解決這個問題，請按照以下說明操作：
- 檢查防火牆通訊埠，確保 SBC 擁有到 Voice 媒體 IP 子網路 (74.125.39.0/24) 通訊埠 19305 或 26500 的雙向媒體流量。
- 如果是 SBC 公開 IP，則適用媒體通訊埠 <> 74.125.39.0/24:(19302-19308、26500)。詳情請參閱「SIP Link 的防火牆通訊埠」一節。
- Google Voice 媒體 IP 可透過連線偵測 (ping) 存取，因此若要測試能否從 SBC 存取，也可採用此方式。
- 執行網路位址轉譯 (NAT) 時，防火牆不應修改 SBC 傳送的通訊埠。這會導致 Voice 捨棄 SBC 的傳送媒體封包，因為 Voice 會將此來源視為 SBC 的公開 IP，但這是與協商的 SDP 提議和應答不同的通訊埠。
有雙向封包流量，但通話沒有音訊
如要解決這個問題，請檢查媒體的加密編譯機制，為 AES_CM_128_HMAC_SHA1_80。
Google 以 486 (SDES) 回覆邀請
如要解決這個問題，請檢查媒體的加密編譯機制。
如果邀請包含 SIP Link 不支援的 MKI，請停用 MKI。
相關主題
Google、Google Workspace 和其他相關符號及標誌均為 Google LLC 的商標。所有其他公司名稱和產品名稱則為相關公司的商標。