直接路由 - 媒体协议
本文介绍了直接路由如何支持使用会话边界控制器 (SBC) 启用 ICE Lite 的媒体旁路，如 RFC 5245 中所述。 本文适用于负责配置本地 SBC 与 SIP 代理服务之间的连接的语音管理员。
本文概述了 ICE Lite 方案和互操作性要求。 本文介绍了确保可靠的呼叫和媒体流的消息格式和所需的状态机转换。
术语
First Hello – 调用方和被调用方说出的第一个字词。 请务必尽一切努力确保在大多数用例中可靠地传递来自终结点的第一个数据包。
分叉 – 如果被调用方在多个设备上可用，则调用方的产品/服务可能会传递到多个被调用方终结点 (例如，Teams 用户可能登录到 Teams for Windows 和 Teams for Android 或 iPhone) 。
临时应答 (183) – 用于加快呼叫设置的被调用方终结点发送应答，其中包含建立媒体流所需的候选项和密钥。 此答案是在预期用户可能接听来自该特定被调用方实例的呼叫 (200OK) 时完成的。 使用分叉时，调用方应准备好接收多个临时答案。
Re-Invite - 由 ICE 控制终结点选择最终候选项的产品/服务。 此产品/服务具有 a=remote-candidate 属性，用于解决处理多个分支时出现的任何争用条件。
Teams 终结点 – 此终结点可以是服务器 (媒体处理器、传输中继) 或 Teams 客户端。
邮件格式
Teams 基础结构遵循 RFC 5245 for ICE-Lite。 所有 STUN 消息都符合 RFC 5389。
根据 RFC 5389 的要求，SBC 必须忽略它们无法识别的任何 STUN 属性，并继续处理具有已知属性的消息。
如果收到任何格式不正确的数据包，则必须丢弃数据包，而不会影响媒体会话的建立。
ICE Lite 要求
本部分简要介绍 ICE Lite 的要求。
候选人收集
SBC 必须只提供一个候选人。 目前，仅支持 IPV4 候选项。
连接性检查
ICE Lite 实现必须响应收到的任何连接检查。 ICE Lite 终结点不得发送任何连接检查请求。 (如果发送的连接检查是违反的，则完整的实现会做出响应，这可能会导致发现意外的对等派生候选项，并可能导致调用失败。)
提名
ICE 完整实现终结点是控制终结点，并遵循“常规”提名来选择用于媒体流的最终候选项。 ICE Lite 终结点可以使用提名来结束用于媒体和完成呼叫建立的路径。
使用对等终结点进行分叉发送 183 个临时答案时，SBC 必须准备好响应来自多个终结点的检查，如果提名发生在 200OK 之前，则还必须准备好响应来自多个终结点的提名。 根据 ICE 状态机在用户应答的最终路径和时间上的收敛情况，提名可以在 200OK 之前或之后进行。 SBC 必须能够处理这两种情况。
分叉的聚合
如果从 SBC 分支到多个 Teams 终结点的产品/服务，Teams 终结点可能会使用临时答案进行响应，并开始连接检查。 SBC 必须准备好接收连接检查并响应来自多个对等终结点的连接检查。 例如，Teams 用户可以同时登录到桌面和手机。 这两个设备都会收到入站呼叫的通知，并会尝试与 SBC 进行连接检查。
最终只有一个终结点接听呼叫 (200OK) 。 接收 200OK 时，SBC 可以设置正确的上下文来处理媒体数据包。
方案
来自 SBC 的入站呼叫
对于此方案，SBC 必须处理多个可能的对等终结点：
服务器终结点通常直接响应 200OK。 语音邮件、呼叫队列和自动助理方案中通常涉及这些 ICE Full 终结点。
客户端终结点可以发送多个具有不同“从/到”标记的临时答案， (183) 后跟从应答呼叫的终结点发送 200OK。 这些 ICE Full 终结点通常表示最终用户客户端。
其他 SBC 终结点。 这些 ICE Lite 终结点通常涉及同时拨打客户端终结点和另一个电话号码 () 。
SBC 必须响应从 ICE Full 终结点接收的所有有效连接检查请求。 根据 RFC，ICE Full 终结点将成为控制终结点。 Teams (客户端/服务器) 终结点执行“常规”提名以完成连接检查。 最终的 200Ok 可以是来自发送早期媒体的终结点，也可以来自其他终结点。 接收 200Ok 时，SBC 必须为媒体流设置正确的上下文。
早期媒体
如果存在早期的媒体流，SBC 必须闩锁到启动流式处理媒体的第一个终结点;媒体流可以在候选人被提名之前启动。 SBC 应支持在此阶段发送 DTMF 以启用 IVR/语音邮件方案。 如果提名尚未完成，SBC 应使用接收检查的最高优先级路径。
对 SBC 的出站调用
Teams 终结点是此方案的调用方，是控制终结点。 在收到 (183) 的临时答案或最终答案 (200OK) 时，Teams 终结点将启动连接性检查，并继续进行“常规”提名以完成连接性检查。
注意：如果 SBC (183) 发送临时答复，则 SBC 必须准备好接收连接检查请求，并可能完成提名，然后再发送 200OK。 如果在收到 200OK 之前完成了检查和/或提名，则收到 200OK 后不会再次执行检查和/或提名。 SBC 不得在 183 到 200 之间更改 ICE 候选项、密码和 ufrag (用户名片段) 。
为了支持早期媒体，SBC 可能会开始将媒体流式传输到对等 ICE 候选项，其优先级最高，具体取决于收到的连接检查，甚至在 Teams 终结点完成提名之前也是如此。 SBC 应该期待 Teams 对任何候选人的媒体， 直到提名完成。 提名候选项后，SBC 必须重置为正确的上下文才能发送和接收媒体数据包。
在 SDP 中处理 M 行
在某些通话方案中，可能会在 PSTN 的调用中提供其他媒体形式。 例如，如果将 Teams 视频呼叫转接到 PSTN，则 m=video。 如果客户 SBC 配置了媒体旁路，则服务不会删除这些行，并且需要由 SBC 按照以下RFC3264进行处理：对于产品/服务中的每个非“m=audio”行，SBC 必须在答案中包含相应的“m=”行，并且此行中的端口号应设置为零， 有效拒绝所有非音频流。
SRTP 支持要求
SBC 必须支持 SRTP 加密密码AES_CM_128_HMAC_SHA1_80，以便按以下格式提供和应答：
"inline:" <key||salt> ["|" lifetime]
下面是 SBC 中 SDP 产品/服务中的加密属性示例：
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:V/Lr6Lsvhad/crSB9kCQ28jrYDxR2Yfk5bXryH5V|2^31
不需要 MKI 和 Length 参数。
有关详细信息，请参阅 RFC 4568 第 6.1 节。
SDES 支持要求
设备必须能够提供以下格式的 SDES。 Microsoft 媒体处理器始终首选 SDES。
使用非媒体旁路，即使客户端仅支持 DTLS，媒体处理器也会转换为 SDES。
使用媒体旁路时，如果客户端仅 (未来 Google Chrome 状态) 的 DTLS，则直接路由在路径中插入 MP，将调用从媒体旁路转换为非媒体旁路。 在直接路由的 SBC 和媒体处理器组件之间，始终使用 SDES。
目前，没有仅提供 DTLS 的 Teams 客户端;然而，谷歌宣布，在某个时间点，他们将停止支持SDES。
在旁路模式下从 SBC 提供产品/服务的格式
产品/服务必须包含 SDES，并且可以包含采用以下格式的 DTLS 可选：
m=audio 54056 UDP/TLS/RTP/SAVP 0 8 76 77 18 9 101 13
a=rtcp:54056
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:krXco0QRglwErMqtbMs2zSw29tBdmdgXpEYZhQmp|2^31
a=fingerprint:sha-256 AE:24:07:15:5C:B7:45:1A:E4:45:60:C1:1E:68:0E:CC:8D:A6:78:3B:76:65:BB:B0:77:88:07:F8:98:18:62:34
a=setup:actpass
a=rtcp-mux
包含 SDES 到 SBC 的答案的格式
m=audio 54056 RTP/SAVP 111 103 104 9 0 8 description 106 13 110 112 113 126
a=rtcp:54056
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:fBc61ikv1kMy0sF85DblNqTzVAbFa7hJQ9GKb6Yj|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:O1qT9tWbs/NwJVwhfrgF5tCrbNOxnVDqkIqTx4rz|2^31
a=rtcp-mux
从 Teams 到 SBC 的产品/服务的格式
SDES 仅适用于 SBC 的格式
m=audio 52884 RTP/SAVP 111 103 104 9 0 8 106 13 110 112 113 126
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:Hr4D2cgUu9+Uza5Igz/JkVx59DAxDbaxJg862ibQ|2^31
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JPEaIxHegfuv53ykBPZk8hV0GO8kTiiqRMfHimEE|2^31
a=rtcp:52884
a=rtcp-mux