通話流程基本概念
下一節將概略說明 Azure 通訊服務中的通話流程。 訊號和媒體流程取決於您的使用者所進行的通話類型。 通話類型的範例包括一對一 VoIP、一對一 PSTN，以及包含 VoIP 與 PSTN 連線參與者組合的群組通話。 請參閱通話類型。
關於訊號和媒體通訊協定
當您建立點對點或群組通話時，幕後會使用兩個通訊協定 - HTTPS (REST) 用來處理訊號，SRTP 則用於媒體。
在 SDK 之間或在通訊服務訊號控制器之間的訊號，會使用 HTTPS REST (TLS) 來處理。 Azure 通訊服務使用的是 TLS 1.2。 對於即時媒體流量 (RTP)，建議採用使用者資料包通訊協定 (UDP)。 如果防火牆會阻止 UDP 的使用，則 SDK 會將傳輸控制通訊協定 (TCP) 用於媒體。
我們來回顧一下各種案例中適用的訊號和媒體通訊協定。
通話流程案例
案例 1：可在兩個裝置之間直接連線的 VoIP
在一對一 VoIP 或視訊通話中，流量會優先採用最直接的路徑。 「直接路徑」指的是，如果兩個 SDK 可以直接互相連線，則會建立直接連接。 當兩個 SDK 位於相同的子網路中 (例如，在子網路 192.168.1.0/24 中)，或兩個裝置分別位於可彼此查看的子網路時 (位於子網路 10.10.0.0/16 和 192.168.1.0/24 中的 SDK 可互相連線)，通常就可直接連接。
案例 2：無法在裝置之間直接連線、但 NAT 裝置之間可以連線的 VoIP
如果兩個裝置位於無法彼此連線的子網路中 (例如，Alice 在咖啡廳工作，而 Bob 在家裡工作)，但 NAT 裝置之間可以連線，則用戶端的 SDK 將透過 NAT 裝置建立連線。
對於 Alice，這會是咖啡廳的 NAT，對 Bob 而言則是家裡的 NAT。 Alice 的裝置會傳送其 NAT 的外部位址，而 Bob 的裝置也會執行相同的動作。 SDK 會從 Azure 通訊服務免費提供的 STUN (適用於 NAT 的工作階段周遊公用程式) 服務獲知外部位址。 處理 Alice 與 Bob 雙方交握的邏輯會內嵌在 Azure 通訊服務提供的 SDK 內。 (您不需要進行額外的設定)
案例 3：直接連線和 NAT 連線皆不可行的 VoIP
如果有一或兩個用戶端裝置位於對稱式 NAT 後方，則需要以個別的雲端服務在兩個 SDK 之間轉送媒體。 這項服務稱為 TURN (Traversal Using Relays around NAT)，同樣由通訊服務所提供。 通訊服務的通話 SDK 會根據偵測到的網路狀況自動使用 TURN 服務。 TURN 費用包含在通話的價格中。
案例 4：PSTN 的群組通話
PSTN 通話的訊號和媒體均使用 Azure 通訊服務的電話語音資源。 這項資源會與其他電信業者互相連線。
PSTN 媒體流量會通過名為「媒體處理器」的元件。
注意
如果您熟悉媒體處理，我們的媒體處理器也是背對背使用者代理程式，如 RFC 3261 SIP：工作階段初始通訊協定中所定義，這表示其可以在處理 Microsoft 與電信業者網路之間的通話時轉譯轉碼器。 Azure 通訊服務的訊號控制器是 Microsoft 根據相同 RFC 進行的 SIP Proxy 實作。
進行群組通話時，媒體和訊號一律會透過 Azure 通訊服務後端傳輸。 所有參與者的音訊和/或視訊都會混合在媒體處理器元件中。 群組通話的所有成員都會將其音訊和/或視訊串流傳送至媒體處理器，再由處理器傳回混合的媒體串流。
群組通話的預設即時通訊協定 (RTP) 為使用者資料包通訊協定 (UDP)。
注意
媒體處理器可作為 Multipoint 控制單位 (MCU) 或選擇性轉送單位 (SFU)
如果 SDK 因防火牆限制而無法將 UDP 用於媒體，則會嘗試使用傳輸控制通訊協定 (TCP)。 請注意，媒體處理器元件需要 UDP，因此在發生這種情況時，將會在群組通話中新增通訊服務 TURN 服務，以將 TCP 轉譯為 UDP。 TURN 費用包含在通話的價格中。
案例 5：排程 Teams 會議中的通訊服務 SDK 和 Microsoft Teams
訊號流經訊號控制器。 媒體流經媒體處理器。 訊號控制器和媒體處理器會在通訊服務與 Microsoft Teams 之間共用。
案例 6：接通通知
指的是在受話使用者接受特定工作階段之前交換的媒體 (例如音訊和視訊)。 如果有接通通知流程，SBC 必須閂鎖到啟動串流媒體的第一個端點；媒體流程可以在提名候選項目之前開始。 SBC 應該在此階段支援傳送 DTMF，以啟用 IVR/語音信箱案例。 如果提名尚未完成，SBC 應該使用其收到檢查的最高優先順序路徑。
下一步
您可能會對下列文件感興趣：