直接路由 - SIP 通訊協定
本文說明直接路由如何實作會話初始通訊協定 (SIP) 。 若要在會話框線控制器 (SBC) 和 SIP Proxy 之間路由流量，某些 SIP 參數必須具有特定值。 本文適用於負責設定內部部署 SBC 與 SIP Proxy 服務之間連線的語音系統管理員。
處理傳入要求：尋找租用戶和使用者
在處理來電或撥出電話之前，SIP Proxy 和 SBC 之間會交換 OPTIONS 訊息。 這些選項訊息可讓SIP Proxy 為 SBC 提供允許的功能。 請務必交涉 OPTIONS，以成功 (200OK 回應) ，以便在 SBC 和 SIP Proxy 之間進一步溝通，以建立通話。 將選項訊息中的 SIP 標頭提供給 SIP Proxy 的範例：
| 參數名稱 | 值的範例 |
|---|---|
| Request-URI | 選項sip:sip.pstnhub.microsoft.com：5061 SIP /2.0 |
| 透過頁首 | Via：SIP/2.0/TLS sbc1.adatum.biz:5058;別名;branch=z9hG4bKac2121518978 |
| Max-Forwards 頁首 | Max-Forwards：68 |
| 從頁首 | 從頁首： sip：sbc1.adatum.biz：5058 |
| 移至頁首 | To： sip:sip.pstnhub.microsoft.com：5061 |
| CSeq 標頭 | CSeq：1 邀請 |
| 連絡頁首 | 聯繫 人：sip：sbc1.adatum.biz：50588;transport=tls |
備註
SIP 標頭在使用中的 SIP URI 中不包含 userinfo。 根據 RFC 3261，區段 19.1.1，URI 的 userinfo 部分為選用，當目的地主機沒有使用者概念，或當識別的資源為主機本身時，可能會遺失。 如果 @ 符號出現在 SIP URI 中，則使用者欄位不得為空白。 SIPS URI 不應搭配直接路由使用，因為它不受支援。 檢查會話框線控制器設定，並確認您未在 SIP 要求中使用「取代」標頭。 直接路由會拒絕已定義取代標頭的 SIP 要求。
在來電中，SIP Proxy 必須尋找來電目的地的租使用者，並在此租用戶中尋找特定使用者。 租用戶系統管理員可能會在多個租用戶中設定非 DID 號碼，例如 +1001。 因此，請務必尋找要執行數位查閱的特定租用戶，因為非 DID 的數位在多個 Microsoft 365 或 Office 365 組織中可能相同。
本節說明 SIP Proxy 如何尋找租使用者和使用者，並在傳入連線上執行 SBC 驗證。
以下是來電上的SIP 邀請訊息範例：
| 參數名稱 | 值的範例 |
|---|---|
| Request-URI | INVITE sip：+18338006777@sip.pstnhub.microsoft.com SIP /2.0 |
| 透過頁首 | Via：SIP/2.0/TLS sbc1.adatum.biz:5058;別名;branch=z9hG4bKac2121518978 |
| Max-Forwards 頁首 | Max-Forwards：68 |
| 從頁首 | 從頁首來源： <sip：+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679 |
| 移至頁首 | To：sip：+183338006777@sbc1.adatum.biz |
| CSeq 標頭 | CSeq：1 邀請 |
| 連絡頁首 | 聯繫 人：sip：+17168712781@sbc1.adatum.biz：5058;transport=tls |
收到邀請時，SIP Proxy 會執行下列步驟：
檢查憑證。 在初始連線上，直接路由服務會採用聯繫人標頭中顯示的 FQDN 名稱，並將其與所呈現憑證的通用名稱或主旨替代名稱相符。 SBC 名稱必須符合下列其中一個選項：
選項 1. 在聯繫人標頭中顯示的完整 FQDN 名稱必須符合所呈現憑證的通用名稱/主旨替代名稱。
選項 2. 在聯繫人標頭 (顯示之 FQDN 名稱的網域部分，例如 FQDN 名稱 sbc1.adatum.biz) adatum.biz 必須符合常見名稱/主旨替代名稱 (例如 *.adatum.biz) 中的通配符值。
嘗試使用聯繫人標頭中顯示的完整 FQDN 名稱尋找租使用者。
檢查聯繫人標題中的 FQDN 名稱 (sbc1.adatum.biz) 是否在任何 Microsoft 365 或 Office 365 組織中註冊為 DNS 名稱。 如果找到，使用者的查閱會在已註冊為功能變數名稱的 SBC FQDN 租用戶中執行。 如果找不到，則適用步驟 3。
步驟 3 僅適用於步驟 2 失敗時。
拿掉 FQDN 中的主機部分，此部分在移除主機部分后，於 [連絡人] 標題 (FQDN 中顯示：sbc12.adatum.biz：adatum.biz) ，並檢查此名稱是否在任何 Microsoft 365 或 Office 365 組織中註冊為 DNS 名稱。 如果找到，使用者查閱會在此租用戶中執行。 如果找不到，通話會失敗。
使用 Request-URI 中顯示的電話號碼，在步驟 2 或 3 找到的租用戶內執行反向號碼查閱。 將呈現的電話號碼與上一個步驟找到之租使用者內的使用者SIP URI 相符。
套用主幹設定。 尋找此 SBC 租用戶系統管理員所設定的參數。
Microsoft 不支援在 Microsoft SIP Proxy 與配對 SBC 之間擁有第三方 SIP Proxy 或使用者代理伺服器，這可能會修改由配對 SBC 建立的要求 URI。
這兩種查閱的需求 (本文稍後所說明的一個 SBC 與許多租使用者相互連線至許多租使用者 (電信業者案例時，需要執行步驟 2 和 3) ) 。
聯繫人標頭和要求 URI 的詳細需求
連絡頁首
針對 [選項] (所有內送 SIP 訊息，邀請) 至 Microsoft SIP Proxy，聯繫人標頭必須在 URI 主機名中擁有配對的 SBC FQDN，如下所示：
語法：聯繫人： <sip：phone 或 sip address@FQDN of SBC;transport=tls>
根據 RFC 3261，區段 11.1，[選項] 訊息中可能會出現 [聯繫人標題] 字段。 在直接路由中，需要聯繫人標頭。 對於上述格式的 INVITE 郵件，您可以從 SIP URI 移除對選項訊息的使用資訊，而且只能從下列格式傳送 FQDN：
語法：聯繫人： <SBC 的 sip：FQDN;transport=tls>
此名稱 (FQDN) 也必須位於所呈現憑證) 的 [通用名稱] 或 [主旨替代名稱] 字段 (。 Microsoft 支援在憑證的 [通用名稱] 或 [主旨替代名稱] 欄位中使用名稱 () 的通配符值。
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 與聯繫人標頭，其中 hostname 以 IP 表示，而非 FQDN，則會拒絕連線 403 禁止。
Request-URI
針對所有來電，會使用 Request-URI 來比對電話號碼與使用者。
目前電話號碼必須包含加號 (+) ，如下列範例所示。
INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
從頁首
針對所有來電，[發件人標頭] 會用來比對來電者的電話號碼與來電者的封鎖電話號碼清單，並用來執行反向號碼查閱，從現有的租使用者和用戶記錄中尋找來電者的名稱。
若要讓這些查閱正常運作，電話號碼必須包含 +，如下列範例所示。
From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679
連絡和 Record-Route 標頭考慮
SIP Proxy 需要針對新的對話框用戶端交易計算下一個躍點 FQDN (例如 Bye 或重新邀請) ，以及回復 SIP 選項時。 使用連絡人或 Record-Route。
根據 RFC 3261，區段 8.1.1.8，任何可能導致新對話框的要求中都必須有聯繫人標頭。 只有 Proxy 想要維持在對話框中未來要求的路徑時，才需要 Record-Route。 如果 Proxy SBC 正與 「本機媒體優化」搭配直接路由使用，記錄路由必須設定為 Proxy SBC 需要留在路由中。
如果不使用 Proxy SBC，Microsoft 建議只使用聯絡人標頭：
每個 RFC 3261，區段 20.30，如果 Proxy 想要留在對話框中的未來要求路徑，則會使用 Record-Route。如果沒有設定 Proxy SBC，因為 Microsoft SIP Proxy 和配對 SBC 之間的流量都沒關係。
Microsoft SIP Proxy 只會使用聯繫人標頭 (而非 Record-Route) 來判斷傳送輸出 ping 選項時的下一個躍點。 只要設定一個參數 (聯繫人) ，而不是兩個 (聯繫人和 Record-Route) 簡化不使用 Proxy SBC 的系統管理。
若要計算下一個躍點，SIP Proxy 會使用：
優先順序 1. 頂層記錄路由。 如果頂層 Record-Route 包含 FQDN 名稱，則會使用 FQDN 名稱來建立輸出對話框連線。
優先順序 2. 連絡頁首。 如果 Record-Route 不存在，SIP Proxy 會查閱聯繫人標頭的值，以建立輸出連線。 (這是建議的設定。)
如果同時使用 [聯繫人] 和 [Record-Route]，則 SBC 系統管理員必須保持其值的相同，因而導致系統管理負荷過重。
在連絡人或 Record-Route 中使用 FQDN 名稱
Record-Route 或聯繫人不支援使用IP位址。 唯一支援的選項是 FQDN，必須符合 SBC 憑證的通用名稱或主旨替代名稱 (憑證中的通配符值) 支援。
如果在 [記錄路由] 或 [聯繫人] 中顯示IP位址，憑證檢查會失敗且通話失敗。
如果 FQDN 與所呈現憑證中通用或主旨替代名稱的值不符，通話便會失敗。
撥入通話：SIP 對話框描述
下表摘要列出非略過和略過模式之間的通話流程差異和相似處：
| 參數名稱 | 非略過模式 | 略過模式 |
|---|---|---|
| 來自183和200封郵件的媒體候選字 | 媒體處理器 | 用戶端 |
| SBC 可接收的 183 封郵件數目 | 每個會話一個 | 多個 |
| 通話可以與接聽的接聽 (183) | 是 | 是 |
| 183 (183) 通話不含任何答案 | 是 | 是 |
非媒體略過流程
Teams 使用者可能同時有多個端點。 例如，適用於 Windows 用戶端的 Teams、iPhone 版 Teams 用戶端，以及 Teams 電話 (Teams Android 用戶端) 。 每個端點可能會發出 HTTP 休憩訊號，如下所示：
通話進度 - 由 SIP Proxy 轉換為 SIP 訊息 180。 在收到郵件 180 時，SBC 必須產生本機響鈴。
媒體答案 – 在 SDP) 的工作階段描述通訊協定 (中，由 SIP Proxy 轉換為訊息 183 與媒體候選字。 在收到訊息 183 時，SBC 預期會連線到 SDP 訊息中收到的媒體候選字。
注意事項
在某些情況下，可能不會產生媒體接聽，端點可能會以「通話已接受」訊息來接聽。
已接受通話 ： 使用 SIP 將 SIP Proxy 轉換為 SIP 訊息 200。 在收到訊息 200 時，SBC 預期會傳送和接收所提供 SDP 候選字的媒體。
備註
直接路由不支持沒有 SDP) 的延遲優惠邀請 (邀請。
多個端點隨著附著答案響鈴
收到 SBC 的第一次邀請時，SIP Proxy 會傳送「SIP SIP/2.0 100 試用」訊息，並通知所有使用者端點與來電有關。
通知時，每個端點都會開始響鈴，並傳送「通話進度」訊息到SIP Proxy。 由於 Teams 使用者可以有多個端點，SIP Proxy 可能會收到多個通話進度訊息。
針對從用戶端收到的每封通話進度訊息，SIP Proxy 會將通話進度訊息轉換為 SIP 訊息「SIP SIP/2.0 180 響鈴」。 傳送這類訊息的間隔是根據從呼叫控制器接收郵件的時間間隔所定義。 在下列圖表中，有兩封由 SIP Proxy 產生的 180 封郵件。 這些訊息來自使用者的兩個 Teams 端點。 每個用戶端都有唯一的標籤標識碼。 每個來自不同端點的郵件都是個別的會話， (「收件者」欄位中的參數「標籤」不同) 。 但端點可能不會產生訊息 180，並立即傳送郵件 183，如下圖所示。
當端點產生含有端點媒體候選字 IP 位址的 Media Answer 訊息後，SIP Proxy 會將收到的郵件轉換為「SIP 183 會話進度」訊息，而來自用戶端的 SDP 由媒體處理器的 SDP 取代。 在下列圖表中，Fork 2 的端點已接聽來電。 如果未略過主幹，183 SIP 訊息只會在通道機器人或用戶端端點) (產生一次。 183 可能在現有的筆跡上，或是開始新的一個。
通話接受訊息會傳送至接受通話之端點的最後候選字。 通話接受訊息會轉換為SIP訊息 200。
多個端點響鈴而不傳入解答
收到 SBC 的第一次邀請時，SIP Proxy 會傳送「SIP SIP/2.0 100 試用」訊息，並通知所有使用者端點與來電有關。
收到通知時，每個端點都會開始響鈴，並傳送「通話進度」訊息至 SIP Proxy。 由於 Teams 使用者可以有多個端點，SIP Proxy 可能會收到多個通話進度訊息。
針對從用戶端收到的每一封通話進度訊息，SIP Proxy 會將通話進度訊息轉換為 SIP 訊息「SIP SIP/2.0 180 試用」。 傳送郵件的間隔是根據從撥號控制器接收郵件的時間間隔所定義。 在下列圖表中，SIP Proxy 會產生兩則 180 封郵件，這表示使用者登入三個 Teams 用戶端，而每個用戶端都會傳送通話進度。 每封郵件都是個別的會話 (“To” 字段中的參數「標籤」不同)
通話接受訊息會傳送至接受通話之端點的最後候選字。 通話接受訊息會轉換為SIP訊息 200。
媒體略過流程
相同的訊息 (100 試用、180、183) 用於媒體略過案例。
下列架構顯示略過通話流程的範例。
備註
媒體候選字可以來自不同的端點。
[取代] 選項
SBC 必須支援 [以取代邀請]。
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 傳送郵件的範例，該訊息支援 [參考] 方法：
ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
如果 SBC 不指出 「參考為支援的方法」，則直接路由會使用選項 1 (SIP Proxy 做為「裁判員」) 。 SBC 也必須表示它支援[通知] 方法：
表示不支持參照方法的 SBC 範例：
ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS
SIP Proxy 程式 從本機客戶端推薦並做為裁判員
如果 SBC 表示不支援 [參考] 方法，SIP Proxy 會做為 [裁判員]。
來自用戶端的 「參考」要求在 SIP Proxy 上終止。 在下列圖表中，用戶端的 [推薦] 要求會顯示為「呼叫轉移給 Dave」。 如需詳細資訊，請參閱 RFC 3892 第 7.1 節。
SIP Proxy 會傳送 [參照至 SBC]，並做為移轉者
這是呼叫轉移的慣用方法，對於尋求媒體略過認證的裝置而言是必要的。 媒體旁路模式不支持沒有 SBC 處理 [推薦] 的呼叫轉移。
此標準會在 RFC 5589 的第 6 節中說明。 相關的 RFC 為：
此選項假設 SIP Proxy 做為轉接器，並傳送 [參考] 訊息至 SBC。 SBC 會做為轉接者，並處理 [參考] 以產生新的傳輸優惠。 有兩種可能的情況：
- 通話會轉接給外部 PSTN 參與者。
- 通話會透過 SBC 從一個 Teams 用戶轉移到同一租使用者中的另一個 Teams 使用者。
如果通話是透過 SBC 從一個 Teams 使用者轉接至另一個使用者，則預期 SBC 會發出新的邀請 (啟動轉接目標的新對話框) ， (Teams 使用者) 使用 [參考] 訊息中收到的資訊。
若要在內部填入要求交易的 To/Transferor 字段，SIP Proxy 必須在 REFER-TO/REFER-BY 標頭內傳達此資訊。
SIP Proxy 會將 REFER-TO 做為 SIP URI，包含主機名中的 SIP Proxy FQDN，以及下列其中一項：
URI 使用者名稱部分中的 E.164 電話號碼，以防移轉目標為電話號碼或
x-m 和 x-t 參數分別編碼完整傳輸目標 MRI 和租用戶標識碼
REFERRED-BY 標頭是 SIP URI，其中包含編碼的移轉器 MRI，以及移轉器租使用者識別碼和其他傳輸上下文參數，如下表所示：
| 參數 | 值 | 描述 |
|---|---|---|
| x-m | Mri | CC 填入之傳輸器/傳輸目標的完整 MRI |
| x-t | 租用戶識別碼 | x-t 租使用者標識符 選擇性租用戶標識碼由 CC 填入 |
| x-ti | 傳輸器相互關聯標識碼 | 呼叫轉移器的相互關聯標識碼 |
| x-tt | 轉接目標通話 URI | 編碼呼叫取代用URI |
在此情況下，[推薦頁首] 的大小最多可以是 400 個符號。 SBC 必須支持處理最多 400 個符號大小的 [參考] 郵件。
呼叫轉移
Teams 使用者可以將來電轉接給其他號碼或 Teams 使用者、同時撥打給其他使用者或使用者 (同時撥打) 或撥打一組使用者或號碼。 請考慮下列事項：
從 SIP Proxy 到 User C 的 INVITE 要求中的 Request-URI 包含 原因 參數。
根據 forwardCallHistory 參數) (主幹設定，會填入 History-Info 標頭。
當 User A 是另一個 PSTN 使用者時，SIP Proxy 會針對 User A 產生「SIP SIP/2.0 181 呼叫正在轉接」的回應。
如果 User A 和 User 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 會套用語言來判斷 (電話號碼或 SIP 位址) 的 Request-URI 用戶類型。
Microsoft 建議一律套用 user=phone 參數，以簡化通話設定程式。
History-Info 頁首
History-Info 標頭用於重新設定 SIP 要求，以及「提供 () 擷取要求歷程記錄資訊的標準機制，以便為網路和使用者啟用各種服務」。 如需詳細資訊，請參閱 RFC 4244 – 節 1.1。 對於 Microsoft Phone System，此標頭用於 Simulring 和呼叫轉移案例。
如果傳送，History-Info 會以下列方式啟用：
SIP Proxy 會在包含傳送至 PSTN 控制器之 History-Info 標頭的個別 History-Info 專案中插入包含相關聯電話號碼的參數。 PSTN 控制器只會使用具有電話號碼參數的專案，重建新的 History-Info 標頭，並透過SIP Proxy 將它傳遞給 SIP 主幹提供者。
系統會針對同時撥打和呼叫轉移案例新增 History-Info 標頭。
History-Info 呼叫轉移案例不會新增標頭。
重新建立 History-Info 頁首中的個別歷程記錄專案會將提供的電話號碼參數與直接路由 FQDN (sip.pstnhub.microsoft.com) 設為 URI 的主機部分;'user=phone' 的參數會新增為 SIP URI 的一部分。 除了手機上下文參數以外，與原始 History-Info 頁首相關的任何其他參數都會在重新建構的 History-Info 頁首中傳遞。
備註
由 RFC 4244) 第 3.3 節定義的私密 (專案會轉寄，因為 SIP 主幹提供者是受信任的對等。
啟用 ForwardCallHistory 參數時，會保留輸入 History-Info。 保留 History-Info 可用於防迴圈防護。
以下是 SIP Proxy 所傳送之歷程記錄資訊標頭的格式：
<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 郵件以回應 INVITE 時，SBC 必須終止該連線，並嘗試下一個可用的 Microsoft 數據中心。
處理 603 回應 (重述)
如果使用者在拒絕來電後觀察到多個未接來電，表示 SBC 或 PSTN 主幹提供者的重試機制設定錯誤。 SBC 必須重新設定，才能停止 603 回應的重試。
ICE 重新啟動：媒體略過呼叫轉移至不支持媒體略過的端點
SBC 必須支援 如 RFC 5245 第 9.1.1.1 節中所述的 ICE 重新啟動。
直接路由中的重新啟動會根據 RFC 的下列段落實作：
若要重新啟動 ICE，專員必須變更優惠中媒體串流的 ice-pwd 和 ice-ufrag。 在一個優惠中使用會話層級屬性是允許的，但若要在後續優惠中提供與媒體層級屬性相同的 ice-pwd 或 ice-ufrag。 這不是密碼變更，只是變更其表示方式，也不會造成 ICE 重新啟動。
代理程式會針對此媒體串流設定 SDP 中其餘的欄位，就像在此媒體串流的初始優惠中設定一樣， (請參閱第 4.3 節) 。 因此，該候選字組可能包含該串流的部分、無或所有先前的候選字，而MAY則包含如第4.1.1節所述收集的新候選字集。
如果通話最初是在媒體略過的情況下建立，且呼叫轉移至 商務用 Skype 用戶端，則直接路由需要插入媒體處理器，這是因為直接路由無法與媒體略過的 商務用 Skype 用戶端搭配使用。 直接路由會變更冰塊和 ice-ufrag，並在重新邀請中提供新的媒體候選字，以啟動 ICE 重新啟動程式。