直接路由 - 定义和 RFC 标准
本文介绍 Teams 电话直接路由如何实现 RFC 标准协议。 本文适用于负责配置本地会话边界控制器 (SBC) 与会话初始协议 (SIP) 代理服务之间的连接的语音管理员。
客户 SBC 与 Microsoft Teams 后端中的以下组件交互：
用于信号的 SIP 代理。 此组件是直接路由的面向 Internet 的组件，用于处理 SBC 与直接路由之间的 SIP (TLS) 连接。
媒体的媒体处理器 。 此组件是处理媒体流量的面向 Internet 的直接路由组件。 此组件使用 SRTP 和 SRTCP 协议。
有关直接路由的详细信息，请参阅 Teams 电话直接路由。
有关直接路由如何实现 SIP 协议的详细信息，请参阅 直接路由 - SIP 协议。
RFC 标准
直接路由符合 RFC 标准。 连接到直接路由的 SBC 还必须符合以下 RFC (或其后续) 。
适用于支持非媒体旁路模式的设备的标准
以下标准适用于仅支持非媒体旁路模式的设备：
- RFC 3261 SIP：会话初始协议
- RFC 3325。 受信任网络中断言标识的会话初始协议的专用扩展--有关处理 P-Asserted-Identity 标头的部分。 直接路由使用隐私 ID 标头发送 P-Asserted-Identity。
- RFC 4244 会话初始协议的扩展 (SIP) ，以获取所需的历史记录信息。 另请参阅：路由 SIP 协议说明，了解详细信息。
- RFC 3892 会话初始协议 Referred-By 机制
- RFC 3891 会话初始协议 (SIP) “替换”标头
- RFC 6337 会话初始协议 (SIP) 套餐/应答模型的使用情况。 请参阅“与 RFC 的偏差”部分。
- RFC 3711 和 RFC 4771。 使用 SRTP 保护 RTP 流量。 SBC 必须能够使用 SDES 建立密钥。
- RFC 8035 会话描述协议 (SDP) RTP/RTCP 多路复用的套餐/应答说明
适用于支持媒体旁路模式的设备的标准
除了列出的适用于非bypass 模式的标准外，还使用以下标准用于媒体旁路模式：
-
RFC 5245 交互式连接建立 (ICE) 媒体旁路。 SBC 必须支持以下各项：
- ICE Lite - Teams 客户端是完整的 ICE 客户端
- ICE 重启。 在 ICE 重启：将媒体旁路调用转移到不支持媒体旁路的终结点中详细了解 ICE 重启用例和示例
- RFC RFC 5589 会话初始协议 (SIP) 呼叫控制 - 转移。
- 会话初始协议 (SIP) 中的 RFC 3960 早期媒体和响铃音生成 ，请参阅第 3.1 节、分叉和 3.2 部分（铃声生成）
- 适用于 NAT (STUN) 的 RFC 5389 会话遍历实用工具
- RFC 5766 围绕 NAT 使用中继 (TURN) ：NAT (STUN) 的会话遍历实用工具的中继扩展
适用于支持向 E911 提供商传送位置信息的标准
与 RFC 的偏差
下表列出了 RFC () Microsoft SIP 或媒体堆栈的实现偏离标准的部分：
| RFC 和节 | 说明 | 偏差 |
|---|---|---|
| RFC 6337，第 5.3 节保留和恢复媒体 | RFC 允许使用“a=inactive”、“a=sendonly”、a=recvonly“将呼叫置于保留状态。 | SIP 代理仅支持“a=inactive”，并且不了解 SBC 发送“a=sendonly”还是“a=recvonly”。 |
| RFC 6337，第 5.4 节：接收 SDP 时的行为，c=0.0.0.0 | RFC3264 要求代理能够接收连接地址为 0.0.0.0 的 SDP，在这种情况下，这意味着不应将 RTP 和 RTCP 发送到对等方。 | SIP 代理不支持此选项。 |
| RFC 3261，SIP 协议的第 25 节扩充的 BNF | “#”字符应作为“%23”发送 | SIP 代理以未转义的方式发送请求 URI 中的“#”字符。 |
| RFC 3264，第 8.3.1 节：使用 SDP 的套餐/答案模型 | 3264 详细介绍了 MAY (可选的) 媒体重新定位机制，允许在建立会话后更改媒体端口、IP 地址或传输。 | 不支持可选的媒体重新定位。 在通话期间，不支持用于更新媒体端口、IP 地址或传输的 SIP 请求。 不会将媒体发送到更新的会话目标;来自直接路由的媒体将继续流向原始目标。 |
RFC 支持选项的说明;产品/服务发送后，必须准备好在旧端口和新端口上接收媒体。 在收到答案并且媒体到达新端口之前，提供方不应停止侦听旧端口上的媒体。|
TCP/TLS 传输注意事项
(新的或对话中) 发送 SIP 请求时，Microsoft SIP 代理可能会打开新的 TCP/TLS 连接，或者重用现有连接（如果存在）。
每个 SIP 代理虚拟机每个远程 FQDN/IP 最多有两个 TCP/TLS 连接。 发送 SIP 请求之前，SIP 代理会检查与目标 SBC/中继 FQDN 解析的 IP 地址的活动 TCP 连接。 如果存在两个连接，则重复使用它们。 如果两个连接不存在，则会打开一个新连接。
此逻辑按 SIP 代理虚拟机执行。
SIP 代理 IP 由每个区域多个虚拟机提供服务。
从 SBC 的角度来看，可能有多个来自所有 SIP 代理区域的入站代理连接。
SIP 代理打开的 TCP/TLS 连接不一定只要调用就保持打开状态。 但是，在响应 SIP 请求后，连接不会立即关闭。 如果连接未超时，则可能会将其重新用于其他 SIP 请求。
SIP 代理不支持连接别名，如 RFC 5923：会话初始协议中的连接重用 (SIP) 中所述。
出站 SIP 代理 TCP 连接仅服务出站 SIP 代理请求 (SBC) 和相关响应。
来自 SBC 的入站 SIP 代理 TCP 连接 (，仅) 服务传入 SIP 请求和相关响应。
超时策略
SIP 代理 TCP 空闲超时为两分钟。 当通过连接发生 SIP 事务时，计时器会重置。
SIP 代理根据 RFC 5626 发送应用程序 CRLF 保持活动状态：在会话初始协议 (SIP) 中管理 Client-Initiated 连接 。
保持连接不会重置 TCP 空闲计时器。
供应商 SBC 发送的 CRLF 保持活动会重置 TCP 空闲计时器。
由于前面提到的别名约束，供应商 SBC 不得使用对话内 SIP 请求重置 SIP 代理出站到供应商 SBC 创建的连接上的计时器。
经过两分钟的闲转， (FIN，ACK) 将在大约 10 到 20 秒内通过 SIP 代理传输到供应商 SBC。
注释
建议 SBC 主动重用连接，例如 SIP 代理。 此方法可节省时间，这是 TCP 和 TLS 连接所需的时间。
SBC 应每小时至少续订一次连接。
上传新的 SBC 证书时，SBC 必须续订所有连接。
更新域配置时，建议续订 SBC 的连接。 否则，在续订内部 SIP 代理缓存后，将应用新的配置 -- 最多 4 小时。
操作模式
直接路由有两种操作模式：
在没有媒体旁路 的情况下，所有 RTP 流量都在 Teams 客户端、媒体处理器和 SBC 之间流动。
使用媒体旁路 ，其中所有 RTP 媒体在 Teams 终结点和 SBC 之间流动。
SIP 流量始终流经 SIP 代理。
DTMF
媒体堆栈不支持带内 DTMF。