Azure 通訊服務 直接路由：SIP 通訊協定詳細數據
本文說明直接路由如何實作會話初始通訊協定 （SIP），以確保會話邊界控制器 （SBC） 與 SIP Proxy 之間的適當流量路由。 它也會醒目提示需要特定值的特定 SIP 參數的重要性。 本文適用於負責設定 SBC 與 SIP Proxy 服務之間連線的語音系統管理員。
處理傳入要求：尋找通訊服務資源
注意
在 Azure 通訊服務 預設會啟用直接路由 SIP 選項，而且無法停用。 SBC 必須先起始 OPTIONS 交換，因為 SIP Proxy 會等候 SBC 啟動交換。
在處理傳入或輸出呼叫之前，OPTIONS 訊息會在 SIP Proxy 與 SBC 之間交換。 這些 OPTIONS 訊息可讓 SIP Proxy 提供 SBC 允許的功能。 選項交涉必須成功 （200 OK 回應），以便進一步通訊 SBC 和 SIP Proxy 來建立通話。 提供 OPTIONS 訊息至 SIP Proxy 中的 SIP 標頭作為範例：
| 參數名稱 | 值的範例 |
|---|---|
| Request-URI | OPTIONS sip:sip.pstnhub.microsoft.com：5061 SIP /2.0 |
| 透過標頭 | 透過：SIP/2.0/TLS sbc1.contoso.com:5061;別名;branch=z9hG4bKac2121518978 |
| Max-Forwards 標頭 | 最大轉寄：68 |
| 從標頭 | 從標頭來源： sip:sbc1.contoso.com：5061 |
| To Header | 至： sip:sip.pstnhub.microsoft.com：5061 |
| CSeq 標頭 | CSeq： 1 邀請 |
| 聯繫人標頭 | 聯繫人： sip:sbc1.contoso.com：5061;transport=tls |
注意
SIP 標頭不包含使用中 SIP URI 中的 userinfo。 根據 RFC 3261 第 19.1.1 節，URI 的 userinfo 部分是選擇性的，而且當目的地主機沒有使用者的概念或主機本身是所識別的資源時，可能不存在。 如果 SIP URI 中存在 @ 符號，則使用者欄位不得空白。 請注意，SIPS URI 不應與直接路由搭配使用，因為它不受支援。 檢查您的會話邊界控制器設定，並確定您未在 SIP 要求中使用「取代」標頭。 直接路由將會拒絕已定義 Replaces 標頭的 SIP 要求。
在來電中，SIP Proxy 必須尋找呼叫目的地的 Azure 通訊資源。 本節說明 SIP Proxy 如何尋找資源，並在連入連線上執行 SBC 的驗證。
來電的 SIP 邀請訊息範例：
| 參數名稱 | 值的範例 |
|---|---|
| Request-URI | 邀請 sip：+54321@sip.pstnhub.microsoft.com SIP /2.0 |
| 透過標頭 | 透過：SIP/2.0/TLS sbc1.contoso.com:5061;別名;branch=z9hG4bKac2121518978 |
| Max-Forwards 標頭 | 最大轉寄：68 |
| 從標頭 | 從標頭來源： <sip：+12345@sbc1.contoso.com;transport=udp;tag=1c68821811 |
| To Header | 至：sip：+54321@sbc1.contoso.com |
| CSeq 標頭 | CSeq： 1 邀請 |
| 聯繫人標頭 | 聯繫人： sip：+12345@sbc1.contoso.com：5061;transport=tls |
接收邀請時，SIP Proxy 會執行下列步驟：
檢查憑證。 在初始連線上，直接路由服務會採用聯繫人標頭中顯示的 FQDN 名稱，並將其與所呈現憑證的一般名稱或主體別名相符。 SBC 名稱必須符合下列其中一個選項：
選項 1。 聯繫人標頭中顯示的完整 FQDN 名稱必須符合所呈現憑證的一般名稱/主體別名。
選項 2。 在聯繫人標頭中顯示的 FQDN 名稱網域部分（例如，FQDN 名稱 contoso.com sbc1.contoso.com）必須符合通用名稱/主體別名（例如 *.contoso.com） 中的通配符值。
嘗試使用聯繫人標頭中顯示的完整 FQDN 名稱來尋找 Microsoft 365 租使用者。
檢查聯繫人標頭 （sbc1.contoso.com） 中的 FQDN 名稱是否已在任何 Microsoft 365 或 Office 365 組織中註冊為 DNS 名稱。 如果找到，則會在註冊為功能變數名稱的 SBC FQDN 租用戶中執行使用者查閱。 如果找不到，則會套用步驟 3。
嘗試使用聯繫人標頭中顯示的完整 FQDN 名稱來尋找 Azure 通訊資源。
檢查連絡人標頭 （sbc1.contoso.com） 中的 FQDN 名稱是否已在任何 Azure 通訊資源中註冊為 SBC FQDN。 如果找到，則會將呼叫傳送至該資源。 如果找不到，則會套用步驟 4。
只有在步驟 2 和 3 失敗時，才適用步驟 4。
拿掉 FQDN 中的主機部分，並顯示在聯繫人標頭中（FQDN:sbc1.contoso.com，移除主機部分之後：contoso.com），並檢查此名稱是否已在任何 Microsoft 365 或 Office 365 組織中註冊為 DNS 名稱。 如果找到，則會在此租用戶中執行使用者查閱。 如果找不到，呼叫會失敗。
只有在步驟 2、3 和 4 失敗時，才適用步驟 5。
從 FQDN 中移除主機部分，並顯示在聯繫人標頭中（FQDN:sbc1.contoso.com，移除主機部分之後：contoso.com），並檢查此名稱是否已在任何 Azure 通訊資源中註冊為 SBC FQDN。 如果找到，則會將呼叫傳送至該資源。 如果找不到，呼叫會失敗。
如果資源有相關聯的 Dynamics Omnichannel 部署，請執行 Request-URI 中顯示的電話號碼查閱。 將呈現的電話號碼與上一個步驟中找到的 Omnichannel 使用者（佇列）相符。
只有在步驟 6 失敗時，才會套用步驟 7。
如果通訊資源不存在 Omnichannel 部署，或 Request-URI 中的號碼不符合任何已設定的 Omnichannel 號碼，請將呼叫傳送至事件方格。
只有在步驟 7 失敗時，才會套用步驟 8。
如果未設定事件方格，或沒有管理來電的規則，則會捨棄呼叫。
聯繫人標頭和 Request-URI 的詳細需求
聯繫人標頭
對於所有連入 SIP 訊息 （OPTIONS， INVITE） 至 Microsoft SIP Proxy，聯繫人標頭必須在 URI 主機名中具有配對的 SBC FQDN，如下所示：
語法：聯繫人： <sip：phone 或 sip address@FQDN SBC;transport=tls>
根據 RFC 3261 第 11.1 節，[聯繫人標頭] 欄位可能會出現在 OPTIONS 訊息中。 在直接路由中，需要聯繫人標頭。 在OPTIONS訊息方面，userinfo可以從SIP URI中排除，而且只能以下列格式傳送 FQDN：
語法：聯繫人： <SBC 的 sip：FQDN;transport=tls>
此名稱 （FQDN） 也必須位於所呈現憑證的 [一般名稱] 或 [主體別名] 字段中。 Microsoft 支援在憑證的 [一般名稱] 或 [主體別名] 字段中使用 name（s） 的通配符值。 RFC 2818 第 3.1 節會說明通配符的支援。 具體而言：
「名稱可能包含通配符 *，這會被視為符合任何單一域名元件或元件片段。 例如，*.a.com 會比對 foo.a.com，但不符合 bar.foo.a.com。 f*.com符合 foo.com，但不符合 bar.com」。
如果 SBC 在 SIP 訊息中顯示的聯繫人標頭中有一個以上的值，則只會使用聯繫人標頭第一個值的 FQDN 部分。 作為直接路由的經驗法則，請務必使用 FQDN 來填入 SIP URI，而不是 IP。 連入的 INVITE 或 OPTIONS 訊息到 SIP Proxy 與連絡人標頭，其中主機名是以 IP 表示，而不是 FQDN，因此會拒絕 403 禁止連線。
Request-URI
針對所有連入呼叫，會使用 Request-URI 來識別被呼叫者。 目前電話號碼必須包含加號 （+），如下列範例所示。
INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0
From 標頭
針對所有來電，From Header 是用來比對來電者的電話號碼。
電話號碼必須包含 +，如下列範例所示。
From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811
聯繫人和記錄路由標頭考慮
SIP Proxy 必須計算新對話內用戶端交易的下一個躍點 FQDN（例如 Bye 或 Re-Invite），以及回復 SIP OPTIONS 時。 這可以使用聯繫人或記錄路由來完成。 根據 RFC 3261 第 8.1.1.8 節，任何可能導致新對話框的要求都需要聯繫人標頭。 只有在 Proxy 想要留在對話框中未來要求的路徑時，才需要 Record-Route。
若要計算下一個躍點，SIP Proxy 會使用：
優先順序 1。 最上層的 Record-Route。 如果最上層的 Record-Route 包含 FQDN 名稱，則會使用 FQDN 名稱來建立對話內輸出連線。
優先順序 2。 聯繫人標頭。 如果 Record-Route 不存在，SIP Proxy 會查閱聯繫人標頭的值，以建立輸出連線。 （建議的設定。）
如果使用 Contact 和 Record-Route，SBC 系統管理員必須保留相同的值，這會導致系統管理額外負荷。
在連絡人或記錄路由中使用 FQDN 名稱
記錄路由或聯繫人不支援使用IP位址。 唯一支援的選項是 FQDN，必須符合 SBC 憑證的一般名稱或主體別名（支持憑證中的通配符值）。
如果記錄路由或聯繫人中顯示IP位址，憑證檢查就會失敗，而呼叫會失敗。
如果 FQDN 不符合所呈現憑證中 Common 或 Subject Alternative Name 的值，則呼叫會失敗。
呼叫內容標頭
通話內容標頭目前僅適用於通話自動化 SDK。 呼叫自動化 SDK 支援使用者對用戶標頭和最多五個自定義 SIP 標頭。 INVITE 和 REFER 方法支援這些標頭。
用戶對用戶標頭
SIP 使用者對使用者 （UUI） 標頭是業界標準，在呼叫設定程式期間傳遞內容資訊。 UUI 標頭索引鍵的最大長度為 64 個字元。 UUI 標頭值的最大長度為 256 個字元。 UUI 標頭值可能包含英數位元和一些選取的符號，包括 、、、、.%*!_、+、 。 -~;=
自定義標頭
Azure 通訊服務 也支援最多五個自定義 SIP 標頭。 自定義 SIP 標頭金鑰必須以強制前置 X-MS-Custom- 詞開頭。 SIP 標頭金鑰的最大長度為 64 個字元，包括前置 X-MS-Custom- 詞。 SIP 標頭機碼可能包含英數位元和一些選取的符號，包括 .、!、_*%+、 。 ~- SIP 標頭值的最大長度為 256 個字元。 SIP 標頭值可能包含英數位元和幾個選取的符號，包括 =、、、.、%!*_、、 ~-;+
如需實作詳細數據， 請參閱如何在呼叫之間傳遞內容數據。
輸入呼叫：SIP 對話框描述
以下是 SIP Proxy 如何處理輸入呼叫的詳細數據。
| 參數名稱 | 值 |
|---|---|
| 來自 183 和 200 條訊息的媒體候選人 | 媒體處理器 |
| SBC 可以接收的 183 則訊息數目 | 每個會話一個 |
| 通話可以是臨時接聽 （183） | Yes |
| 通話可以是沒有臨時答案 （183） | Yes |
Azure 通訊服務 身分識別可能會同時用於多個端點（應用程式）。 例如，Web 應用程式、i 電話 應用程式和 Android 應用程式。 每個端點可能會發出 HTTP 待用訊號，如下所示：
呼叫進度 – 由 SIP Proxy 轉換為 SIP 訊息 180。 在接收訊息 180 時，SBC 必須產生本機響鈴。
媒體回應 – 由 SIP Proxy 轉換成訊息 183，其中包含會話描述通訊協定 （SDP） 中的媒體候選專案。 在接收訊息 183 時，SBC 預期會連線到 SDP 訊息中收到的媒體候選專案。
注意
在某些情況下，可能不會產生媒體答案，而且端點可能會以「已接受通話」訊息回應。
已接受的呼叫 – 由 SIP Proxy 轉換為具有 SDP 的 SIP 訊息 200。 在接收訊息 200 時，SBC 預計將從提供的 SDP 候選專案來回傳送和接收媒體。
注意
直接路由不支援延遲供應項目邀請（不含 SDP 的邀請）。
具有暫時答案的多個端點響鈴
從 SBC 接收第一個邀請時，SIP Proxy 會傳送「SIP SIP/2.0 100 嘗試」訊息，並通知所有終端使用者端點有關連入呼叫。
通知後，每個端點都會開始響鈴，並將「通話進度」訊息傳送至 SIP Proxy。 當多個端點使用 Azure 通訊服務 身分識別時，SIP Proxy 可能會收到多個通話進度訊息。
對於從端點接收的每個通話進度訊息，SIP Proxy 會將通話進度訊息轉換為 SIP 訊息“SIP SIP/2.0 180 Ringing”。 傳送這類訊息的間隔會與從呼叫控制器接收訊息的間隔相互關聯。 在下圖中，SIP Proxy 會產生兩個 180 個訊息。 這些訊息來自兩個SDK端點。 端點各有唯一的標籤標識碼。 來自不同端點的每個訊息都是不同的會話（“To” 字段中的參數 “tag” 不同）。 但端點可能不會產生訊息 180 並立即傳送訊息 183，如下圖所示。
端點產生具有端點媒體候選專案 IP 位址的媒體回應訊息之後，SIP Proxy 會將收到的訊息轉換成「SIP 183 會話進度」訊息，並將來自媒體處理器 SDP 取代的端點 SDP 的 SDP。 在下圖中，來自 Fork 2 的端點接聽了呼叫。 183 SIP 訊息只會產生一次。 183 可能位於現有的分叉上，或啟動新的分支。
呼叫接受訊息會傳送至 SIP Proxy，其中包含接受呼叫之端點的最終候選專案。 通話接受訊息會轉換成SIP訊息 200。
多個端點沒有暫時答案的響鈴
從 SBC 接收第一個邀請時，SIP Proxy 會傳送「SIP SIP/2.0 100 嘗試」訊息，並通知所有終端使用者端點有關連入呼叫。
通知後，每個端點都會開始響鈴，並將訊息「通話進度」傳送至 SIP Proxy。 由於相同的 Azure 通訊服務 身分識別可用於多個應用程式，因此 SIP Proxy 可能會收到多個通話進度訊息。
對於從端點接收的每個通話進度訊息，SIP Proxy 會將通話進度訊息轉換為 SIP 訊息“SIP SIP/2.0 180 Ringing”。 傳送訊息的間隔會與從呼叫控制器接收訊息的間隔相互關聯。 圖片中有兩個 SIP Proxy 產生的 180 則訊息，這表示呼叫會派生至兩個不同的用戶端，而每個用戶端都會傳送呼叫進度。 每個訊息都是個別的工作階段（“To” 欄位中的參數 「tag」 不同）
呼叫接受訊息會傳送至 SIP Proxy，其中包含接受呼叫之端點的最終候選專案。 通話接受訊息會轉換成SIP訊息 200。
取代選項
SBC 必須支援使用 Replaces 的 INVITE。
SDP 考慮的大小
直接路由介面可能會傳送超過 1,500 個字節的 SIP 訊息。 SDP 的大小主要會導致這類行為。 不過，如果 SBC 後方有 UDP 主幹，則從 Microsoft SIP Proxy 轉送至未修改主幹時，可能會拒絕該訊息。 Microsoft 建議在將訊息傳送至 UDP 主幹時，在 SBC 上移除 SDP 中的一些值。 例如，可以移除 ICE 候選專案或未使用的編解碼器。
通話轉移
直接路由支援兩種呼叫轉移方法：
選項 1。 SIP Proxy 進程從用戶端本機參考，並作為參考者，如 RFC 3892 第 7.1 節所述。
使用此選項時，SIP Proxy 會終止傳輸，並新增新的邀請。
選項 2。 SIP Proxy 會傳送參考 SBC，並做為 RFC 5589 第 6 節中所述的傳送者。
使用此選項時，SIP Proxy 會傳送參考 SBC，並預期 SBC 能夠完整處理傳輸。
SIP Proxy 會根據 SBC 所報告的功能來選取 方法。 如果 SBC 表示它支援 「參考」方法，SIP Proxy 會使用選項 2 進行通話轉移。 SBC 傳送支援 Refer 方法之訊息的範例：
ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
如果 SBC 未指出參考為支援的方法，直接路由會使用選項 1 （SIP Proxy 作為裁判）。 SBC 也必須發出其支援 Notify 方法的訊號：指出不支援 Refer 方法的 SBC 範例：
ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS
SIP Proxy 進程從用戶端本機參考，並作為裁判
如果 SBC 指出不支援 Refer 方法，SIP Proxy 會做為裁判。 來自用戶端的 Refer 要求會在 SIP Proxy 上終止。 下圖中的 [參考用戶端要求] 會顯示為「通話轉移至 Dave」。 如需詳細資訊，請參閱 RFC 3892 的 7.1 節。
SIP Proxy 會傳送參考 SBC，並做為傳輸者
SIP Proxy 作為轉接器是呼叫轉移的慣用方法。
RFC 5589 的第 6 節會說明標準。 相關的 RFC 包括：
此選項假設 SIP Proxy 會作為傳送者，並將 Refer 訊息傳送至 SBC。 SBC 會作為被轉移者，並處理參考以產生新的轉移供應專案。 有兩種可能的情況：
- 通話會轉移給外部 PSTN 參與者。
- 呼叫會透過 SBC，從一個 SDK 端點傳輸到相同資源中的另一個 SDK 端點。
如果呼叫是透過 SBC 從一個 SDK 端點傳輸到另一個 SDK 端點，則 SBC 會使用 [參考] 訊息中收到的資訊，為傳輸目標發出新的邀請（啟動新的對話框）。 若要在內部填入要求交易的 To/Transferor 字段，SIP Proxy 必須在 REFER-TO/REFERRED-BY 標頭內傳達此資訊。 SIP Proxy 會將 REFER-TO 形成為由主機名中的 SIP Proxy FQDN 所組成的 SIP URI，以及下列其中一項：
如果傳輸目標為電話號碼，則 URI 用戶名稱部分的 E.164 電話號碼，或
x-m 和 x-t 參數分別編碼完整傳輸目標 MRI 和通訊資源識別碼。
REFERRED-BY 標頭具有 SIP URI，其中傳輸器 MRI 編碼，以及傳輸器資源標識元和其他傳輸內容參數，如下表所示：
| 參數 | 數值 | Description |
|---|---|---|
| x-m | Mri | 由CC填入的完整傳輸者/傳輸目標 MRI |
| x-t | 租用戶識別碼 | x-t 資源識別符 選擇性資源標識符，如 CC 填入 |
| x-ti | 傳送器相互關聯標識碼 | 呼叫傳送器的相互關聯標識碼 |
| x-tt | 轉移目標呼叫 URI | 編碼的呼叫取代 URI |
在此案例中，參考標頭的大小最多可以是 400 個符號。 SBC 必須支持處理大小高達 400 個符號的參考訊息。
呼叫轉接
Azure 通訊服務 通話自動化 SDK 可以將來電重新導向至另一個號碼或 SDK/Teams 端點、平行撥打其他使用者或使用者（同時響鈴），或撥打一組使用者或號碼。 需考量的事項：
從 SIP Proxy 到使用者 C 的 INVITE 要求中的要求 URI 包含 原因 參數。
已填入 History-Info 標頭。
當使用者 A 是另一位 PSTN 使用者時，SIP Proxy 會產生「正在轉送 SIP SIP/2.0 181 通話」暫時回應給使用者 A。
如果使用者 A 和使用者 C 是 PSTN 使用者，SIP Proxy 會保留「正在轉送 SIP SIP/2.0 181 通話」臨時回應。
History-Info 標頭應該用於迴圈預防。
會話定時器
SIP Proxy 支援會話定時器（一律提供）。 使用 SBC 的工作階段定時器並非必要專案。
使用 Request-URI 參數 user=phone
SIP Proxy 會分析 Request-URI，如果參數 user=phone 存在，服務會以電話號碼處理 Request-URI，並將號碼與使用者相符。 如果參數不存在，SIP Proxy 會套用啟發學習法來判斷 Request-URI 使用者類型（電話號碼或 SIP 位址）。
Microsoft 建議一律套用 user=phone 參數，以簡化通話設定程式。
History-Info 標頭
注意
在 Azure 通訊服務 預設會啟用直接路由 History-Info 標頭，而且無法停用。
History-Info 標頭用於複位 SIP 要求的目標，並「提供標準機制來擷取要求歷程記錄資訊，以便為網路和使用者啟用各種不同的服務」。 如需詳細資訊，請參閱 RFC 4244 – 第 1.1 節。 針對直接路由，此標頭會用於同時響鈴和呼叫轉接案例。
歷程記錄資訊已啟用，如下所示：
SIP Proxy 會插入參數，其中包含個別 History-Info 專案中相關聯的電話號碼，其中包含傳送至 PSTN 控制器的 History-Info 標頭。 僅使用具有電話號碼參數的專案，PSTN 控制器會重建新的 History-Info 標頭，並透過 SIP Proxy 將它傳遞至 SIP 主幹提供者。
已針對同時響鈴和呼叫轉接案例新增 History-Info 標頭。
通話轉移案例不會新增歷程記錄信息標頭。
重新建構的 History-Info 標頭中的個別歷程記錄專案具有提供的電話號碼參數，並結合設定為 URI 主機部分的直接路由 FQDN （sip.pstnhub.microsoft.com）。 新增為 SIP URI 一部分之 'user=phone' 的參數。 與原始 History-Info 標頭相關聯的任何其他參數，除了電話內容參數外，會在重建的 History-Info 標頭中傳遞。
注意
屬於私用的專案，如 RFC 4244 第 3.3 節中所定義的機制所決定，因為 SIP 主幹提供者是受信任的對等。
輸入歷程記錄資訊會保留以進行迴圈預防。
以下是 SIP Proxy 所傳送的歷程記錄資訊標頭格式：
<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2
如果呼叫已重新導向數次，則每個重新導向的相關信息會以時間順序依時間順序包含在逗號分隔清單中。
標頭範例：
History-Info:
<sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
<sip:+113579@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1
History-Info 標頭中的 SIP URI 會根據 RFC 3261 的第 25 節來格式化（請參閱 的定義 addr-spec）。 在上一個範例中，URI 標頭 Reason 的原始文字是 SIP;cause=496;text="User Busy"，它會分別取得其 ;、 "、 和 = 字元逸出至其 ASCII 十六進位值 %3B、 %22和 3D。
歷程記錄資訊受到強制 TLS 機制的保護。
直接路由和故障轉移機制的 SBC 連線
請參閱直接路由基礎結構需求中 SIP 訊號的故障轉移機制一節。
Retry-after
如果直接路由數據中心忙碌中，服務可以將一秒間隔的 Retry-After 訊息傳送至 SBC。 當 SBC 收到具有 Retry-After 標頭的 503 訊息以回應 INVITE 時，SBC 必須終止該連線，並嘗試下一個可用的 Microsoft 數據中心。
處理重試 （603 回應）
如果使用者在拒絕來電後觀察到一個通話的數個未接聽通話，這表示 SBC 或 PSTN 主幹提供者的重試機制設定不正確。 必須重新設定 SBC，才能停止 603 回應的重試工作。