直接路由 - 定義和 RFC 標準
本文說明 Teams 電話 直接路由實作 RFC 標準通訊協定。 本文適用於負責設定內部部署會話框線控制器 (SBC) 與 SIP) Proxy 服務 (會話初始通訊協定之間的連線的語音系統管理員。
客戶 SBC 介面，Microsoft Teams 後端包含下列元件：
訊號的 SIP Proxy。 此元件是直接路由的因特網元件，可處理SIP (TLS，) SBC 與直接路由之間的連線。
媒體的媒體處理器 。 此元件是處理媒體流量之直接路由的因特網元件。 此元件使用 SRTP 和 SRTCP 通訊協定。
如需直接路由的詳細資訊，請參閱 Teams 電話 直接路由]。
如需直接路由如何實作 SIP 通訊協定的詳細資訊，請參閱 直接路由 - SIP 通訊協定。
RFC 標準
直接路由符合 RFC 標準。 連線至直接路由的 SBC 也必須遵守下列 RFC (或其後續) 。
適用於支援非媒體略過模式之裝置的標準
下列標準適用於僅支援非媒體略過模式的裝置：
- RFC 3261 SIP：會話初始通訊協定
- RFC 3325 在信任的網路內針對已驗證身分識別的會話初始通訊協定專用的專用擴充功能 --關於處理 P-名片識別標頭的章節。 直接路由會傳送具有隱私權標識符標頭的 P-維護身分識別。
- RFC 4244 會話初始通訊協定的擴充功能 (SIP) 必要歷程記錄資訊。 另請參閱：路由SIP通訊協定描述以取得詳細資訊。
- RFC 3892 會話初始通訊協定 Referred-By 機制
- RFC 3891 SIP (工作階段初始通訊協定) 「取代」標頭
- RFC 6337 會話初始通訊協定 (SIP) 優惠/Answer 模型的使用方式。 See the “Deviations from RFC” section.
- RFC 3711 和 RFC 4771。 使用 SRTP 保護 RTP 流量。 SBC 必須能夠使用 SDES 建立金鑰。
- RFC 8035 會話描述通訊協定 (SDP) RTP/RTCP Multiplexing 的優惠/解答說明
適用於支持媒體略過模式之裝置的標準
除了列出適用於非密碼模式的標準之外，下列標準也適用於媒體旁路模式：
-
RFC 5245 互動式連線因媒體略過而 (ICE) 。 SBC 必須支援下列專案：
- ICE Lite - Teams 用戶端是完整的 ICE 用戶端
- ICE 隨即重新啟動。 如需更多有關 ICE 重新啟動使用案例的詳細資訊，請參閱 ICE 重新啟動中的案例和範例：媒體略過呼叫轉移至不支持媒體略過的端點
- RFC RFC 5589 會話初始通訊協定 (SIP) 通話控制 – 傳輸。
- SIP) (會話初始通訊協定中的 RFC 3960 早期媒體和 鈴聲產生音效，請參閱 3.1、Forking 和 3.2 節的鈴聲產生
- RFC 5389 SESSION Traversal Utilities for NAT (STUN)
- RFC 5766 在 NAT 周圍使用轉送 (轉) ：將擴充功能轉送到 NAT (STUN)
適用於支援向 E911 提供者傳達位置資訊的標準
RFC 的偏差
下表列出MICROSOFT實作 SIP 或媒體堆疊時，與標準相差的 RFC 區段：
| RFC 和節 | 描述 | 偏差 |
|---|---|---|
| RFC 6337，區段 5.3 保留和繼續媒體 | RFC 允許使用 “a=inactive”， “a=sendonly”， a=recvonly“ 來保留通話。 | SIP Proxy 僅支援 “a=inactive”，且不瞭解 SBC 是否傳送 “a=sendonly” 或 “a=recvonly”。 |
| RFC 6337，使用 c=0.0.0.0 接收 SDP 的 5.4 行為區段 | RFC3264 要求代理程式能夠接收連線位址為 0.0.0.0.0.0 的 SDP，在這種情況下，這表示不應將 RTP 或 RTCP 傳送給對等。 | SIP Proxy 不支援此選項。 |
| RFC 3261 區段 25 SIP 通訊協定的 BNF 擴充 | '#' 字元應該傳送為 '%23' | SIP Proxy 會在未封裝 Request-URI 中傳送 「#」字元。 |
| RFC 3264，區段 8.3.1 SDP 的優惠/答案模型 | 3264 詳述 5 月 (選用) 媒體重新目標機制，允許在會話建立後變更媒體埠、IP 位址或傳輸。 | 不支持選用媒體複位目標。 在通話期間，SIP 不支援更新媒體埠、IP 位址或傳輸的要求。 媒體不會傳送至更新的會話目標;來自直接路由的媒體會繼續流向原始的目標。 |
來自 RFC 支援選擇的附註;優惠傳送后，優惠者必須準備好接收舊埠和新埠的媒體。 在收到解答並送達新埠的媒體之前，優惠者應該不會停止聆聽舊埠上的媒體。|
TCP/TLS 傳輸考慮
傳送 SIP 要求 (新的或對話內) 時，Microsoft SIP Proxy 可能會開啟新的 TCP/TLS 連線，如果有的話，則重複使用現有的連線。
每個 SIP Proxy 虛擬機每個遠端 FQDN/IP 最多有兩個 TCP/TLS 連線。 傳送 SIP 要求之前，SIP Proxy 會檢查作用中 TCP 連線是否與目標 SBC/主幹 FQDN 的已解決 IP 位址。 如果兩個連線存在，它們就會重複使用。 如果兩個連線不存在，則會開啟新的連線。
這個邏輯是每個 SIP Proxy 虛擬機。
每個地區有多個虛擬機提供SIP Proxy IP 服務。
從 SBC 的觀點來看，可能來自所有 SIP Proxy 區域的多個輸入 Proxy 連線。
只要通話進行，SIP Proxy 開啟的 TCP/TLS 連線不一定會保持開啟。 不過，連線不會在SIP要求回應后立即關閉。 如果連線沒有逾時，可能會重複用於其他 SIP 要求。
SIP Proxy 不支援連線別名，如 RFC 5923 中所述：會話初始通訊協定中的連線重複使用 (SIP) 。
輸出 SIP Proxy TCP 連線僅限服務輸出 SIP Proxy 要求 (SBC) 及相關回應。
從 SBC (輸入 SIP Proxy TCP 連線) 服務內送 SIP 要求和相關回應。
逾時原則
SIP Proxy TCP 空閒逾時為 2 分鐘。 當 SIP 交易透過連線發生時，定時器會重設。
SIP Proxy 會根據 RFC 5626 傳送應用程式 CRLF 永生：在會話初始通訊協定 (SIP) 中管理 Client-Initiated Connections。
保持生動不會重設 TCP 閑置定時器。
供應商 SBC 傳送的 CRLF 永生定時器會重設 TCP 閑置定時器。
由於先前提及的別名限制式，供應商 SBC 不得使用對話內 SIP 要求重設 SIP Proxy 輸出至供應商 SBC 之連線上的定時器。
在標識碼 (兩分鐘后，SIP Proxy 會在大約 10 到 20 秒內將 ACK) 傳輸至供貨商 SBC。
注釋
建議 SBC 主動重複使用連線，例如 SIP Proxy。 這個方法可節省 TCP 和 TLS 連線所需的時間。
SBC 應該每小時至少續約一次連線。
上傳新的 SBC 憑證時，SBC 必須更新所有連線。
當網域設定更新時，建議更新 SBC 的連線。 否則，系統會在內部 SIP Proxy 快取續約之後套用新的設定，最多可達四小時。
操作模式
直接路由有兩種操作模式：
不使用在 Teams 用戶端、媒體處理器和 SBC 之間流經所有 RTP 流量的媒體略過。
在媒體略過 時，所有 RTP 媒體會在 Teams 端點和 SBC 之間延伸。
SIP 流量一律會流經 SIP Proxy。
DTMF
媒體堆疊不支持頻內 DTMF。