本文說明直接路由如何實作 SIP) (會話發起協定。 為了在 SBC) (會話邊界控制器與 SIP 代理之間路由流量，某些 SIP 參數必須有特定值。 本文主要針對負責配置本地 SBC 與 SIP 代理服務連線的語音管理員。
處理來函請求：尋找租戶與使用者
在來電或出電處理前，SIP 代理與 SBC 之間會交換 OPTIONS 訊息。 這些 OPTIONS 訊息允許 SIP 代理提供 SBC 允許的功能。 OPTIONS 協商必須成功 (200OK 回應) ，這有助於 SBC 與 SIP 代理之間進一步通訊以建立通話。 以下為 OPTIONS 訊息中對 SIP 代理的標頭範例：
| 參數名稱 | 價值範例 |
|---|---|
| 請求-URI | 期權 sip:sip.pstnhub.microsoft.com：5061 SIP /2.0 |
| 來源 | 透過：SIP/2.0/TLS sbc1.adatum.biz:5058;別名;分支=z9hG4bKac2121518978 |
| Max-Forwards 標頭 | 最大前鋒：68 |
| 摘自標題 | 摘自標題： sip：sbc1.adatum.biz：5058 |
| 到標題 | 收件人： sip:sip.pstnhub.microsoft.com：5061 |
| CSeq 標頭 | CSeq：1 邀請函 |
| 接點標頭 | 聯絡方式： sip：sbc1.adatum.biz：50588;傳輸=TLS |
備註
- SIP 標頭不包含正在使用的 SIP URI 中的使用者資訊。 根據 RFC 3261，第 19.1.1 節，URI 中的 userinfo 部分是可選的，當目的主機沒有使用者概念，或主機本身就是被識別的資源時，URI 中可能缺少。 如果 @ 符號存在於 SIP URI，使用者欄位不得為空。
- SIPS URI 與直接路由不支援。
- 檢查你的會話邊界控制器設定，確保你沒有在 SIP 請求中使用「替換」標頭。 直接路由會拒絕定義替換標頭的 SIP 請求。
來電時，SIP 代理需要找到該通話目的地的租戶，並找到該租戶內的特定使用者。 租戶管理員可能會在多個租戶中配置非 DID 號碼，例如 +1001。 因此，找到要執行號碼查詢的特定租戶非常重要，因為非 DID 的號碼在多個 Microsoft 365 或 Office 365 組織中可能相同。
本節說明 SIP 代理如何找到租戶與使用者，並在進站連線上對 SBC 進行認證。
以下是來電中 SIP 邀請訊息的範例：
| 參數名稱 | 價值範例 |
|---|---|
| 請求-URI | 邀請 sip：+18338006777@sip.pstnhub.microsoft.com SIP /2.0 |
| 來源 | 透過：SIP/2.0/TLS sbc1.adatum.biz:5058;別名;分支=z9hG4bKac2121518978 |
| Max-Forwards 標頭 | 最大前鋒：68 |
| 摘自標題 | 摘自標題： <sip：+17168712781@sbc1.adatum.biz;transport=UDP;標籤=1c747237679 |
| 到標題 | 收件人：啜飲：+183338006777@sbc1.adatum.biz |
| CSeq 標頭 | CSeq：1 邀請函 |
| 接點標頭 | 聯絡方式： sip：+17168712781@sbc1.adatum.biz：5058;傳輸=TLS |
收到邀請後，SIP 代理會執行以下步驟：
請檢查證書。 在初始連線時，直接路由服務會將聯絡標頭中顯示的 FQDN 名稱與所呈現憑證的通用名稱或主體替代名稱相匹配。 SBC 名稱必須符合以下選項之一：
選項一。 聯絡人標頭中完整 FQDN 名稱必須與所呈現憑證的通用名稱/主體替代名稱相符。
選項二。 例如，聯絡人 (標頭中 FQDN 名稱的網域部分，例如 FQDN 名稱的 adatum.biz，sbc1.adatum.biz) 必須與通用名稱/主體替代名稱 (中的通配符值相符，例如 *.adatum.biz) 。
試著用聯絡人標頭中完整的 FQDN 名稱找到租戶。
檢查聯絡標頭 (sbc1.adatum.biz) 的 FQDN 名稱是否在任何 Microsoft 365 或 Office 365 組織中註冊為 DNS 名稱。 若找到，使用者的查詢會在將 SBC FQDN 註冊為網域名稱的租戶中執行。 若未找到，則適用第三步。
第三步只有在第二步失敗時才適用。
移除 FQDN 中 FQDN 聯絡 (標頭中的主機部分：sbc12.adatum.biz，移除主機部分：adatum.biz) ，並檢查該名稱是否在任何 Microsoft 365 或 Office 365 組織中註冊為 DNS。 若找到，使用者查詢會在該租戶中執行。 若未找到，通話即告失敗。
利用 Request-URI 中提供的電話號碼，在第 2 或第 3 步的租戶內執行反向查詢。 將提供的電話號碼與前一步租戶內的使用者 SIP URI 進行匹配。
套用主線設定。 找到租戶管理員為這個 SBC 設定的參數。
Microsoft 不支援在 Microsoft SIP 代理與配對 SBC 之間設置第三方 SIP 代理或使用者代理伺服器，這可能會修改配對 SBC 所產生的請求 URI。
第二步和第三步驟的兩次查詢需求 () 一個 SBC 互連多個租戶 (電信業者情境下) 後文會介紹。
聯絡標頭與請求-URI的詳細需求
接觸式接頭
對於所有收到的 SIP 訊息 (選項，邀請) 進入 Microsoft SIP 代理，聯絡標頭的 URI 主機名稱必須包含配對的 SBC FQDN，具體如下：
語法：聯絡方式： <sip：phone 或 sip 在 SBC address@FQDN;傳輸=TLS>
根據 RFC 3261，第 11.1 節，OPTIONS 訊息中可以有聯絡標頭欄位。 在直接路由中，接點標頭是必需的。 邀請訊息必須依上述格式發送。 對於 OPTIONS 訊息，使用者資訊可從 SIP URI 中移除，且僅以以下格式傳送 FQDN：
語法：聯絡方式： <sip：SBC 的 FQDN;傳輸=TLS>
此名稱 (FQDN) 也必須出現在所呈憑證的通用名稱或主題替代名稱欄位中。 Microsoft 支援在憑證的通用名稱或主體替代名稱欄位中使用名稱的萬用字元值。
對萬用字組的支援說明見 RFC 2818，第 3.1 節。 具體來說：
「名稱可能包含萬用字元*，該字元被視為與任何單一網域名稱元件或元件片段相符。 例如，*.a.com 匹配 foo.a.com，但不匹配 bar.foo.a.com。 f*.com 配得 foo.com 但不配 bar.com。」
如果 SBC 在 SIP 訊息中傳送多個 Contact 標頭的值，則僅使用第一個 Contact 標頭值的 FQDN 部分。
對於直接路由來說，重要的是使用 FQDN 來填充 SIP URI，而非 IP。 若主機名稱以 IP 而非 FQDN 標頭為 SIP 代理，收到 INVITE 或 OPTIONS 訊息，連線會被拒絕，並標示為 403 禁止。
請求-URI
對於所有來電，Request-URI 會用來將電話號碼與使用者匹配。
目前 電話號碼必須包含加號 (+) ，如下範例所示。
INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
摘自標題
對於所有來電，From 標頭用於將來電者的電話號碼與被撥者封鎖的電話號碼清單比對，並用於反向查詢號碼，從現有租戶及使用者紀錄中找到來電者姓名。
為了讓這些查詢有效，電話號碼必須包含 +，如下例所示。
From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679
接觸與 Record-Route 接頭的考量
SIP 代理需要計算新的對話中客戶端交易的下一跳 FQDN， (例如) Bye 或 Re-Invite，以及回覆 SIP 選項時。 會使用接觸或 Record-Route。
根據 RFC 3261 第 8.1.1.8 節，任何可能產生新對話的請求都必須有聯絡標頭。 只有當代理想要保持在對話框中未來請求的路徑上時，才需要 Record-Route。 若代理 SBC 與 Local Media Optimization for Direct Routing 一起使用，則需設定記錄路由，因為代理 SBC 必須留在該路由中。
Microsoft 建議如果沒有使用代理 SBC，則只使用 Contact 標頭：
根據 RFC 3261 第 20.30 節，Record-Route 用於代理希望保持在對話中未來請求路徑上，但若未設定代理 SBC，則非必要，因為所有流量都在 Microsoft SIP 代理與配對 SBC 之間。
Microsoft SIP 代理在發送出站 ping 選項時，僅使用 Contact 標頭 (不使用 Record-Route) 來決定下一跳。 若未使用代理 SBC，僅設定一個參數 (聯絡) 而非兩個 (聯絡與記錄路由) ，可簡化管理。
為了計算下一跳，SIP 代理使用：
優先事項一。 頂級紀錄路線。 若頂層 Record-Route 包含 FQDN 名稱，則使用 FQDN 名稱來建立出站對話內連線。
優先事項二。 聯絡人標頭。 如果沒有 Record-Route，SIP 代理會查詢 Contact 標頭的值來建立出站連線。 建議採用接點接頭配置。
若同時使用聯絡與 Record-Route，SBC 管理員必須保持兩者的值值一致，這會造成行政負擔。
聯絡或 Record-Route 中使用 FQDN 名稱
Record-Route 和 Contacts 都不支援使用 IP 位址。 唯一支援的選項是 FQDN，必須與 SBC 憑證的通用名稱或主體替代名稱相符， (憑證中的通配符值) 支援。
若 IP 位址出現在記錄路由或聯絡人中，憑證檢查失敗，通話也會失敗。
若 FQDN 與所呈現憑證中公共或主題替代名稱的值不符，呼叫即告失敗。
來電：SIP 對話描述
下表總結了非繞過與繞過模式之間的通話流程差異與相似之處：
| 參數名稱 | 非旁路模式 | 旁通模式 |
|---|---|---|
| 媒體候選人在183和200條訊息中出現 | 媒體處理器 | 用戶端 |
| SBC 可接收的 183 則訊息數量 | 每場一節 | 多重 |
| 電話可撥打臨時接聽 (183) | 是 | 是 |
| 通話可無暫定回覆 (183) | 是 | 是 |
非媒體旁通流
Teams 使用者可能同時擁有多個端點。 例如，Teams for Windows 用戶端、Teams 用戶端 iPhone 用戶端，以及 Teams Phone (Teams Android 用戶端) 。 每個端點可能以以下方式發出 HTTP 靜止訊號：
通話進度——由 SIP 代理轉換成 SIP 訊息 180。 收到訊息 180 時，SBC 必須產生本地鈴聲。
媒體回應——由 SIP 代理轉換為訊息 183，並以 SDP) (Session Description Protocol 中媒體候選。 收到訊息183後，SBC預期能連接SDP訊息中收到的媒體候選人。
備註
在某些情況下，媒體接聽可能未被產生，終端端可能會回應「來電已接聽」訊息。
來電已接受——由 SIP 代理轉換成 SDP 的 SIP 訊息 200。 收到第200則訊息後，SBC預期會與所提供的社會民主黨候選人之間發送和接收媒體。
備註
直接路由不支援延遲邀請邀請 (沒有 SDP) 的邀請。
多個端點響起暫時接聽
收到 SBC 的第一個邀請後，SIP 代理會發送訊息「SIP SIP/2.0 100 嘗試中」，並通知所有終端用戶來電。
通知後，每個端點會開始響鈴並向 SIP 代理發送「通話進度」訊息。 由於 Teams 使用者可以擁有多個端點，SIP 代理可能會收到多個通話進度訊息。
每收到一個來自用戶端的通話進度訊息，SIP 代理會將通話進度訊息轉換為「SIP SIP/2.0 180 鈴聲」的 SIP 訊息。 發送此類訊息的間隔與呼叫控制器接收訊息的間隔相符。 在下圖中，SIP 代理產生了兩則 180 訊息。 這些訊息來自使用者的兩個 Teams 端點。 每個客戶端都有獨特的標籤 ID。 來自不同端點的每則訊息都是獨立的會話 (「收件人」欄位中的「標籤」參數也不同於) 。 但端點可能不會立即產生訊息 180 並傳送訊息 183，如下圖所示。
一旦端點產生包含媒體候選 IP 位址的媒體回應訊息，SIP 代理會將收到的訊息轉換成「SIP 183 會話進度」訊息，並將用戶端的 SDP 替換為媒體處理器的 SDP。 在下圖中，Fork 2 的端點回應了呼叫。 若中繼未被繞過，183 SIP 訊息僅會在 Ring Bot 或用戶端端點) 產生一次 (。 183 可能會接在現有的前叉上，或是開始新的前叉。
接收來電接收訊息會隨接收該終端的最後候選者一同發送。 來電接聽訊息會轉換成 SIP 訊息 200。
多個端點響起卻沒有臨時接聽
收到 SBC 的第一個邀請後，SIP 代理會發送訊息「SIP SIP/2.0 100 嘗試中」，並通知所有終端用戶來電。
通知後，每個端點會開始響鈴並向 SIP 代理發送「通話進度」訊息。 由於 Teams 使用者可能擁有多個端點，SIP 代理可能會收到多個通話進度訊息。
每收到一個來自用戶端的通話進度訊息，SIP 代理會將通話進度訊息轉換為「SIP SIP/2.0 180 鈴聲」的 SIP 訊息。 發送訊息的間隔與接收呼叫控制器訊息的間隔相符。 下圖中，SIP 代理產生兩則 180 訊息，表示使用者登入三個 Teams 用戶端，每個用戶端都會傳送通話進度。 每則訊息都是獨立的會話 (「收件人」欄位中的參數「標籤」不同，)
接收來電接收訊息會隨接收該終端的最後候選者一同發送。 來電接聽訊息會轉換成 SIP 訊息 200。
媒體旁通流程
媒體繞過情境中也會使用相同的訊息 (100 Trying、180、183) 。
以下結構展示了繞過通話流程的範例。
備註
媒體候選人可能來自不同的背景。
替換選項
南方浸信會必須支持邀請與替代。
社會民主黨規模考量
直接路由介面可能會傳送超過 1,500 位元組的 SIP 訊息。 SDP 內容主要是造成過多的體積。 不過，如果 SBC 背後有 UDP 中繼，若訊息是從 Microsoft SIP 代理轉發到中繼且未修改，它可能會拒絕該訊息。 Microsoft 建議在將訊息傳送到 UDP 幹線時，在 SBC 上移除部分 SDP 的值。 例如，可以移除 ICE 候選或未使用的編解碼器。
來電轉接
直接路由支援兩種通話轉接方式：
選項一。 SIP 代理程序從用戶端本地引用，並如 RFC 3892 第 7.1 節所述的裁判角色。
有了這個選項，SIP 代理會終止傳輸並新增一個邀請。
選項二。 SIP 代理將 Refer 傳送給 SBC，並如 RFC 5589 第 6 節所述的轉介者。
使用此選項時，SIP 代理會向 SBC 發送 Refer 訊息，並期望 SBC 能完整處理傳輸。
SIP 代理根據 SBC 回報的能力選擇方法。 若 SBC 表示支援「Refer」方法，SIP 代理會使用選項 2 進行通話轉帳。
以下是一個 SBC 發送 Refer 方法支援訊息的範例：
ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
若 SBC 未標示 Refer 為支援方法，直接路由會使用選項 1， (SIP 代理作為裁判) 。 SBC 也必須標示其支援 Notify 方法：
SBC 表示不支援 Refer 方法的範例：
ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS
SIP 代理程序從用戶端本地轉入，並擔任審判角色
如果 SBC 顯示不支援 Refer 方法，SIP 代理會扮演 Referee 的角色。
來自用戶端的 Refer 請求會在 SIP 代理上終止。 用戶端的 Refer 請求在下圖中顯示為「Call transfer to Dave」。 欲了解更多資訊，請參閱 RFC 3892第7.1節。
SIP 代理會將 Reference 傳送給 SBC，並充當 Transferor
這是通話轉接的首選方式，對於尋求媒體繞過認證的裝置來說是強制的。 在媒體繞過模式下，SBC 無法處理 Refer 的通話轉移不被支援。
該標準在 RFC 5589 第 6 節中有說明。 相關的RFC包括：
此選項假設 SIP 代理作為傳輸者，並向 SBC 發送 Reference 訊息。 SBC 作為受讓人，負責轉介以產生新的轉讓要約。 有兩種可能的情況：
- 通話會轉接給外部的PSTN參與者。
- 通話會透過 SBC 從同一租戶中的一位 Teams 使用者轉移到另一位 Teams 使用者。
當通話從 Teams 用戶轉接到另一位 Teams 用戶或透過 SBC 轉接至 PSTN 號碼時，收到轉介後，SBC 預期會發出新的邀請 (啟動新的對話) ，針對轉接目標 (，該轉接目標是 Teams 用戶或 PSTN 號碼) 向 SIP 代理，並利用轉接訊息中收到的資訊。
為了在內部填充請求交易的 To/Transferor 欄位，SIP 代理需要在 REFER-TO/REFERRED-BY 標頭中傳達這些資訊。
SIP 代理以 SIP URI 形式形成 REFER-TO，由主機名稱中的 SIP 代理 FQDN 及以下任一組成：
在用戶名稱部分加上 E.164 電話號碼，以防傳輸目標是電話號碼，或
x-m 與 x-t 參數分別編碼完整轉移目標 MRI 與租戶 ID
REFERRED-BY 標頭是一個包含傳輸器 MRI 的 SIP URI，並包含傳輸者租戶 ID 及其他傳輸上下文參數，如下表所示：
| 參數 | 值 | 描述 |
|---|---|---|
| X-M | 核磁共振 | 全程MRI掃描轉移/轉移目標，並由CC填充 |
| X-T | 租用戶識別碼 | x-t 租戶識別碼 由抄送填入的可選租戶識別碼 |
| X-TI | 轉移相關性 ID | 轉讓方的通話關聯性 |
| X-TT | 轉移目標呼叫 URI | 編碼呼叫替換 URI |
此時 Refer 標頭的大小可達 400 個符號。 SBC 必須支援處理大小可達 400 個符號的 Refer 訊息。
來電轉接
Teams 用戶可以將來電轉接給其他號碼或 Teams 用戶，並行 (同時響鈴) ，或是同時呼叫一組用戶或號碼。 請考慮下列事項：
INVITE 從 SIP 代理到使用者 C 的請求中，Request-URI 包含 cause 參數。
根據中繼配置 (ForwardCallHistory 參數) ，History-Info 標頭會被填入。
當使用者 A 是另一位 PSTN 使用者時，SIP 代理會向使用者 A 產生「SIP SIP/2.0 181 通話正在轉接中」的臨時回應。
若使用者 A 與使用者 C 是 PSTN 使用者，SIP 代理會保留「SIP SIP/2.0 181 通話正在轉接」的臨時回應。
History-Info 標頭應用於防止迴圈。
會話計時器
SIP 代理支援 (總是在非繞過通話時提供) Session 計時器，但繞過通話則不提供。 SBC 使用 Session 計時器並非強制。
Request-URI 參數 user=phone 的使用
SIP 代理會分析 Request-URI，若參數為 user=phone，服務會將 Request-URI 視為電話號碼，並將號碼與使用者匹配。 若參數不存在，SIP 代理會套用啟發式方法來判斷 Request-URI 使用者類型 (電話號碼或 SIP 位址) 。
Microsoft 建議始終套用 user=phone 參數，以簡化通話建立流程。
History-Info 標頭
History-Info 標頭用於重新定位 SIP 請求，並「提供 (一個標準機制) 擷取請求歷史資訊的標準機制，以促進網路與終端用戶的多種服務。」 欲了解更多資訊，請參閱 RFC 4244 – 第 1.1 節。 對於 Microsoft 電話系統，此標頭用於模擬與來電轉接場景。
若正在發送，History-Info 的啟用方式如下：
SIP 代理會在構成 History-Info 標頭的個別 History-Info 條目中插入包含相關電話號碼的參數，這些標頭會傳送給 PSTN 控制器。 PSTN 控制器僅使用帶有電話號碼參數的條目，重建新的 History-Info 標頭，並透過 SIP 代理傳送給 SIP 中繼服務提供者。
History-Info 標頭用於同時響鈴與來電轉接的情況。
History-Info 標頭不會被新增給呼叫轉移案件。
重建後的 History-Info 標頭中的個別歷史項目會結合提供的電話號碼參數，並設定為 URI 的主機部分的直接路由 FQDN (sip.pstnhub.microsoft.com) ;SIP URI 中會加入「user=phone」這個參數。 與原始 History-Info 標頭相關的其他參數（電話上下文參數除外）會在重建後的 History-Info 標頭中傳遞。
備註
依據RFC 4244第3.3節定義的機制所判定的私有 (條目) 因SIP中繼提供者為受信任對等端而被原封不動地轉發。
啟用 ForwardCallHistory 參數時，入站 History-Info 會被保留。 保存 History-Info 可用於防止迴圈。
以下是 SIP 代理伺服器傳送的 History-info 標頭格式：
<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2
若通話多次重定向，則每次重定向的資訊會以逗號分隔的順序，並附上適當的理由。
標頭範例：
History-Info:
<sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
<sip:+14257123456@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。
History-Info 受到強制性的 TLS 機制保護。
SBC 與直接路由及故障轉移機制的連接
請參閱「 直接路由計畫」中「SIP訊號的故障轉移機制」章節。
Retry-After
如果直接路由資料中心忙碌，服務可以以一秒間隔發送一則 Retry-After 訊息給 SBC。 當 SBC 收到帶有 Retry-After 標頭的 503 訊息以回應邀請時，SBC 必須終止該連線並嘗試下一個可用的Microsoft資料中心。
處理重試 (603 回應)
如果終端使用者在拒絕來電後發現同一通電話有多個未接來電，表示 SBC 或 PSTN 中繼服務提供者的重試機制設定錯誤。 SBC 必須重新配置，以停止對 603 回應的重試。
ICE 重啟：媒體繞過通話轉移到不支援媒體繞過的端點
SBC 必須依照 RFC 5245 第 9.1.1.1 節所述支援 ICE 重啟。
直接路由中的重啟實作依據RFC的以下段落：
要重新啟動 ICE，代理人必須同時更改 offer 中媒體串流的 ice-pwd 和 ice-ufrag。 允許在一個方案中使用會話層級屬性，但在後續的優惠中提供與媒體層級屬性相同的 ice-pwd 或 ice-ufrag 屬性。 這不是密碼的變更，只是顯示方式的改變，且不會導致 ICE 重啟。
代理人會像初次提供該媒體串流時一樣，在 SDP 中設定其餘欄位 (詳見第 4.3 節) 。 因此，候選人集合可能包含部分、無或全部先前該流的候選人，也可能包含如第4.1.1節所述所收集的新候選人集合。
如果通話最初是透過媒體繞過建立，然後通話轉接到 商務用 Skype 用戶端、Teams 網頁用戶端或 VDI 用戶端的 Teams 用戶端，則直接路由需要插入媒體處理器。 直接路由無法用於 商務用 Skype、Teams 網頁或帶有媒體繞過功能的 Teams VDI 用戶端。 直接路由透過更改 ice-pwd 和 ice-ufrag 來啟動 ICE 重啟流程，並在重新邀請中提供新的媒體候選。