當您設定 Google SIP Link 時，需要進行一系列複雜的整合作業。請參閱本文說明來排解整合過程中出現的問題。
事前準備
如要排解 SIP 連結相關問題，請確認您可以：
- 使用 SBC 封包擷取功能
- 使用防火牆封包擷取功能
- 使用工具來查看封包擷取項目
- 存取 SBC 記錄
注意：如需疑難排解的額外說明，請與 SBC 供應商或電信業者聯絡。
確認與 SIP 連結的信號連線
SIP 連結的信號傳遞機制會使用傳輸層安全標準 (TLS)。TLS 內含公開憑證授權單位 (CA) 所建立的憑證套件。您可以在管理控制台的SIP 連結到達網頁中查看 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 或 > traceroute 74.125.39.139
- 如果是 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 工作階段
如何解決這個問題：
- 確認與 PCA 相關聯的根憑證和中繼憑證已上傳到金鑰庫，這個金鑰庫已針對 SIP Link 與您的 TLS 設定檔建立關聯。當您產生 SBC 憑證的 CSR 時，請按照個別 SBC 供應商互通性文件中的規範操作。
- 確認 SBC 憑證符合以下規範：
- 金鑰大小為 2,048
- 提供 RSA 或 ECDSA 加密
- 一般名稱 (CN) 與針對 SIP Link 建立的主機名稱相符
- 憑證中的 CN 網域與 Workspace 網域相符
- 已啟用雙向驗證機制
- 已啟用伺服器和用戶端驗證機制
- 不支援萬用字元憑證
- 確保在 pki.goog 找到的 Google 憑證 GTSR1 也已在 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 SIP 標頭。系統會在您設定 SIP 連結時產生這組金鑰。
- 確認電話號碼採用 P-Asserted-Identity 標頭中的 E. 164 格式。
來自 Voice 的「403 Forbidden」回應
排解常見的媒體連線問題
開始排解媒體連線問題前，請確認網路符合下列條件：
- 您的網路正在使用資料元傳輸層安全標準 (DTLS) 或用於媒體串流 (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 提議和應答不同的通訊埠。
有雙向封包流量，但通話沒有音訊
Google 以 486 (SDES) 回覆邀請
如果邀請包含 SIP 連結不支援的 MKI，請停用 MKI。
相關主題
Google、Google Workspace 與相關符號和標誌均為 Google LLC 的商標。所有其他公司名稱和產品名稱則為相關公司的商標。
