本文說明 Azure 通訊服務中的呼叫流程。 訊號和媒體流程取決於使用者正在發出的通話類型。 通話類型的範例包括一對一 VoIP、一對一公用電話交換網 （PSTN），以及包含 VoIP 和 PSTN 連線參與者組合的群組通話。 如需詳細資訊，請參閱 呼叫類型。
訊號和媒體通訊協定
當您建立點對點或群組呼叫時，會在幕後使用兩種通訊協定 -HTTPS（REST）來表示訊號，並針對媒體使用安全實時傳輸通訊協定（SRTP）。
SDK 之間的訊號或 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 中的裝置可以彼此聯機）。
案例 2：無法在裝置之間直接連線的 VoIP，但 NAT 裝置之間的連線是可能的
如果兩個裝置位於無法彼此連線的子網中，但網路位址轉換 （NAT） 裝置之間的連線是可行的，則用戶端 SDK 會透過 NAT 裝置建立連線。 例如，如果Alice 從咖啡店工作，而Bob則從家庭辦公室工作。
對於Alice來說，這是咖啡店的NAT，而對於Bob來說，這是家庭辦公室的NAT。 Alice 的裝置會傳送 NAT 的外部位址，而 Bob 的裝置會執行相同的動作。 SDK 會從 Azure 通訊服務免費提供的適用於 NAT (STUN) 的工作階段周遊公用程式服務獲知外部位址。 處理 Alice 與 Bob 之間交握的邏輯會內嵌在 Azure 通訊服務提供的 SDK 中。 您不需要任何新增的設定。
案例 3：無法進行直接或 NAT 連線的 VoIP
如果一個或兩個用戶端裝置都位於對稱 NAT 後方，則需要個別的雲端服務，才能在兩個 SDK 之間轉接媒體。 這項服務稱為 Traversal Using Relays around NAT (TURN)，同樣由 Azure 通訊服務所提供。 通訊服務呼叫 SDK 會根據偵測到的網路狀況自動使用 TURN 服務。 TURN料金包含在通話費用中。
案例 4：使用 PSTN 進行群組通話
PSTN 通話的訊號和媒體都會使用 Azure 通訊服務電話語音資源。 此資源與其他電信業者互連。
PSTN 媒體流量會流經媒體處理器元件。
備註
媒體處理器也是背對背使用者代理程式，如 RFC 3261 SIP：工作階段初始通訊協定中所定義，這表示其可以在處理 Microsoft 與電信業者網路之間的通話時轉譯轉碼器。 Azure 通訊服務的訊號控制器是 Microsoft 根據相同 RFC 進行的 SIP Proxy 實作。
針對群組呼叫，媒體和訊號一律會透過 Azure 通訊服務後端流動。 來自所有參與者的音訊和/或視訊會混合在媒體處理器中。 群組呼叫的所有成員都會將其音訊和視訊串流傳送至媒體處理器，以傳回混合媒體串流。
群組呼叫的預設即時通訊協定 （RTP） 是用戶數據報通訊協定 （UDP）。
備註
媒體處理器可作為多點控制單位（MCU）或選擇性轉送單位（SFU）。
如果 SDK 因防火牆限制而無法使用 UDP 進行媒體，則會嘗試使用傳輸控制通訊協定 （TCP）。 媒體處理器元件需要 UDP，因此在此情況下，通訊服務 TURN 服務會新增至群組呼叫，以將 TCP 轉譯為 UDP。 TURN 費用包含在通話價格中。
案例 5：排程 Teams 會議中的通訊服務 SDK 和 Microsoft Teams
訊號會流經訊號控制器。 媒體會流經媒體處理器。 通訊服務和Microsoft Teams 之間會共享訊號控制器和媒體處理器。
案例 6：早期媒體
是指在被呼叫者接受會話之前交換的媒體，例如音訊和視訊。 如果有接通通知流程，工作階段邊界控制器 (SBC) 必須閂鎖到啟動串流媒體的第一個端點；媒體流程可以在提名候選項目之前開始。 SBC 必須在此階段期間支援傳送雙音多頻（DTMF），才能啟用 IVR/語音信箱功能。 如果提名尚未完成，SBC 應使用其收到檢查的最高優先順序路徑。