使用直接路由連線到現有的電話語音服務
Azure 通訊服務直接路由可讓您將現有的電話語音基礎結構連線至 Azure。 本文列出將支援的工作段邊界控制器 (SBC) 連線至直接路由所需的高階步驟,以及語音路由對於已啟用通訊資源的運作方式。
如需 Azure 通訊服務直接路由是否為貴組織的正確解決方案的相關資訊,請參閱 Azure 電話語音概念。 如需必要條件和規劃部署的詳細資訊,請參閱通訊服務直接路由基礎結構需求。
使用 Azure 通訊服務連線 SBC
驗證網域擁有權
請遵循這些指示來驗證 SBC 的網域所有權
設定輸出語音路由
請參閱語音路由快速入門來新增 SBC 並設定輸出語音路由規則。
工作階段框線控制器連線狀態
SBC 連線的健康情況現在會在 Azure 入口網站中公開。 會考慮傳輸層安全性 (TLS) 狀態和 SIP OPTIONS。
每個健康情況指標的可能值
TLS 狀態 - 主幹的 TLS 連線狀態:
- 未知 - 表示 SBC 在過去 15 分鐘內未嘗試 TLS 交握。
- 使用中 - 指出已建立 TLS 連線。
- CertExpiring - 指出 SBC 憑證即將到期。
- CertExpired - 指出 SBC 憑證已過期。
SIP OPTIONS (Ping) - SIP OPTIONS 訊息交換的狀態:
- 未知 - 表示 SBC 尚未傳送任何 SIP 選項。
- 使用中 - 指出正在傳送和接收 OPTIONS。
- 已過期 - 表示 SBC 正在傳送 SIP OPTIONS,但我們在過去 15 分鐘內未收到任何 OPTIONS 訊息。
- 錯誤 - 指出 OPTIONS 交換中的錯誤。
狀態 - 主幹的整體健全狀態:
- 未知 - 表示未知的健全狀態。
- 在線 - 表示 SBC 連線狀況良好。
- 警告 - 指出 TLS 或 Ping 已過期。
注意
如果您剛設定新的主幹,最多可能需要 15 分鐘才能更新狀態。
重要
在撥打或接聽電話之前,請確定 SBC 狀態為在線
輸出語音路由考慮
Azure 通訊服務直接路由具有路由機制,允許根據撥打的號碼模式將通話傳送至特定 SBC。
當您將直接路由組態新增至資源時,從此資源的執行個體 (身分識別) 進行的所有通話都會先嘗試直接路由主幹。 路由是以撥號號碼及針對資源所設定語音路由中的相符項目為基礎。
- 如果有相符項目,則通話會通過直接路由主幹。
- 如果沒有相符項目,下一個步驟是處理
callAgent.startCall
方法的alternateCallerId
參數。 - 如果資源已啟用語音通話 (PSTN),且至少已從 Microsoft 購買一個號碼,則會核取
alternateCallerId
。 - 如果
alternateCallerId
符合資源的購買號碼,則通話會透過使用 Microsoft 基礎結構的語音通話 (PSTN) 路由傳送。 - 如果
alternateCallerId
參數不符合任何購買號碼,通話就會失敗。
此圖示範 Azure 通訊服務語音路由邏輯。
語音路由範例
下列範例會在通話流程中顯示語音路由。
注意
在所有範例中,雖然較高的語音路由具有較高的優先順序,但路由中的 SBC 會以隨機順序嘗試。
一個路由範例:
如果您使用模式 ^\+1(425|206)(\d{7})$
建立了一個語音路由並將 sbc1.contoso.biz
和 sbc2.contoso.biz
新增至其中,則當使用者打電話到 +1 425 XXX XX XX
或 +1 206 XXX XX XX
時,通話會先路由傳送至 SBC sbc1.contoso.biz
或 sbc2.contoso.biz
。 如果兩個 SBC 都無法使用,則會捨棄通話。
兩個路由範例:
如果您使用模式 ^\+1(425|206)(\d{7})$
建立了一個語音路由並將 sbc1.contoso.biz
和 sbc2.contoso.biz
新增至其中,然後使用具有 sbc3.contoso.biz
和 sbc4.contoso.biz
的相同模式建立了第二個路由。 在此情況下,當使用者打電話到 +1 425 XXX XX XX
或 +1 206 XXX XX XX
時,通話會先路由傳送至 SBC sbc1.contoso.biz
或 sbc2.contoso.biz
。 如果 sbc1 和 sbc2 都無法使用,則會嘗試優先順序較低的路由 (sbc3.contoso.biz
和 sbc4.contoso.biz
)。 如果沒有第二個路由的 SBC 可用,則會捨棄通話。
三個路由範例:
如果您使用模式 ^\+1(425|206)(\d{7})$
建立了一個語音路由並將 sbc1.contoso.biz
和 sbc2.contoso.biz
新增至其中,然後使用具有 sbc3.contoso.biz
和 sbc4.contoso.biz
的相同模式建立了第二個路由,以及使用具有 sbc5.contoso.biz
的 ^\+1(\d{10})$
建立了第三個路由。 在此情況下,當使用者打電話到 +1 425 XXX XX XX
或 +1 206 XXX XX XX
時,通話會先路由傳送至 SBC sbc1.contoso.biz
或 sbc2.contoso.biz
。 如果 sbc1 和 sbc2 都無法使用,則會嘗試優先順序較低的路由 (sbc3.contoso.biz
和 sbc4.contoso.biz
)。 如果沒有第二個路由的 SBC 可用,會嘗試第三個路由。 如果 sbc5 也無法使用,則會捨棄通話。 此外,如果使用者撥打 +1 321 XXX XX XX
,則通話會移至 sbc5.contoso.biz
且無法使用,還會捨棄通話。
注意
容錯移轉至語音路由中的下一個 SBC 僅適用於回應碼 408、503 和 504。
注意
在所有範例中,如果撥打的號碼與模式不符,除非通訊資源有購買的號碼存在,否則會捨棄通話,而此號碼在應用程式中作為 alternateCallerId
。
管理輸入呼叫
針對一般輸入通話管理,請使用通話自動化 SDK 來建置應用程式,以接聽及管理撥打至電話號碼或透過 Azure 通訊服務直接路由接收的輸入通話。 針對客戶服務客戶的全通路,請參閱這些指示。