直接路由 - 定義和 RFC 標準

  • 發行項
  • 適用於:
    Microsoft Teams

本文說明 Teams Phone 直接路由如何實作 RFC 標準通訊協定。 本文適用于負責設定內部部署會話框線控制器 (SBC) 與 SIP) Proxy 服務 (會話初始通訊協定之間的連線的語音系統管理員。

Microsoft Teams 後端中包含下列元件的客戶 SBC 介面：

  • 訊號的SIP Proxy。 此元件是直接路由的網際網路元件，可處理 SIP (TLS，) SBC 與直接路由之間的連線。

  • 媒體的媒體處理器 。 此元件是處理媒體流量之直接路由的網際網路元件。 此元件使用 SRTP 和 SRTCP 通訊協定。

如需直接路由的詳細資訊，請參閱 Teams Phone 直接路由。

如需直接路由如何實作 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 的優惠/解答說明

適用于支援媒體略過模式之裝置的標準

除了列出適用于非密碼模式的標準之外，下列標準也適用于媒體旁路模式：

適用于支援向 E911 提供者傳達位置資訊的標準

RFC 的偏差

下表列出 RFC () 區段，其中 Microsoft 的 SIP 或媒體堆疊實作與標準不同：

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 的 SDP，在這種情況下，這表示不應將 RTP 或 RTCP 傳送給對等。 SIP Proxy 不支援此選項。
RFC 3261 區段 25 SIP 通訊協定的 BNF 擴充 '#' 字元應該傳送為 '%23' SIP Proxy 會在未封裝 Request-URI 中傳送 「#」字元。

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 永生：在會話初始通訊協定中管理 Client-Initiated 連線 (SIP) 。

    • 保持生動不會重設 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。