12. 与 SIP 一起使用 (Usage with SIP)
12.1. 延迟指南
ICE 要求端点之间执行一系列基于 STUN 的 connectivity checks. 这些 checks 在 answerer 生成 answer 时从 answerer 开始, 并在 offerer 收到 answer 时从 offerer 开始. 这些 checks 可能需要一定时间才能完成, 因此选择哪些消息来承载 offers 和 answers 会影响用户感知到的延迟. 有两个延迟指标特别值得关注: post-pickup delay 和 post-dial delay. post-pickup delay 指用户 "接听电话" 与其说出的话能够传递给主叫方之间的时间. post-dial delay 指用户输入被叫用户目的地址与因被叫电话已成功开始振铃而听到回铃音之间的时间.
可以考虑两种情况: offer 位于初始 INVITE 中, 以及 offer 位于响应中.
12.1.1. INVITE 中的 offer
为减少 post-dial delay, 推荐主叫方在实际发送其初始 INVITE 之前开始收集 candidates. 这可以由表示呼叫即将发起的用户界面提示触发, 例如键盘活动或电话摘机.
如果在 INVITE 请求中收到 offer, answerer 应该在收到 offer 时开始收集其 candidates, 并在完成该过程后在 provisional response 中生成 answer. ICE 要求带有 SDP 的 provisional response 可靠传输. 这可以通过现有的 Provisional Response Acknowledgment (PRACK) 机制 [RFC3262] 完成, 也可以通过 ICE 特有的一种优化完成. 通过这种优化, 包含 SDP answer 且为一个或多个媒体流启动 ICE 处理的 provisional responses 可以在不使用 RFC 3262 的情况下可靠发送. 为此, agent 使用 RFC 3262 中描述的 exponential backoff timers 重传 provisional response. 一旦收到针对该 SDP 中信令的某个媒体流的 STUN Binding request (因为收到 Binding request 表明 offerer 已收到 answer), 或在 2xx response 中发送 answer 后, 重传 必须停止. 如果 peer agent 是 lite, 则永远不会有 STUN Binding request. 在这种情况下, agent 必须在发送四次 18x 后停止重传 (即便 peer 从未收到 18x, ICE 实际上仍会工作; 但是经验表明, 发送它对于 middleboxes 和 firewall traversal 很重要). 如果在最后一次重传之前没有收到 Binding request, agent 不认为会话已终止. 尽管 provisional response 会被可靠交付, agent 何时可以发送更新的 offer 或 answer 的规则并不改变, 仍按 RFC 3262 指定. 具体而言, 如果 INVITE 包含 offer, 则相同的 answer 会出现在所有 1xx 以及 INVITE 的 2xx response 中. 只有在该 2xx 已发送之后, 才能发生更新的 offer/answer 交换. 如果两个 agents 都支持 PRACK, 则 不应该使用此优化. 注意, 该优化非常专门针对携带启动 ICE 处理的 answers 的 provisional response; 它不是一种通用的 1xx 可靠性技术.
或者, agent 可以将发送 answer 延迟到 200 OK; 但是, 这会导致较差的用户体验, 因此 NOT 推荐.
一旦 answer 已发送, agent 应该开始其 connectivity checks. 一旦某个媒体流每个 component 的 candidate pairs 进入 valid list, answerer 就可以开始在该媒体流上发送媒体.
但是, 在此之前, 任何需要发往主叫方的媒体 (例如 SIP early media [RFC3960]) 不得被传输. 因此, 实现 应该推迟提醒被叫方, 直到每个媒体流的每个 component 的 candidates 都已进入 valid list. 对于 PSTN gateway, 这意味着进入 PSTN 的 setup message 会被延迟到此时. 这样做会增加 post-dial delay, 但具有消除 "ghost rings" 的效果. ghost rings 指被叫方听到电话铃声, 接起电话, 但听不到声音也无法被听到的情况. 此技术无需支持或使用 preconditions [RFC3312] 即可工作, 因为这是一个本地化决策. 它还带来一个好处: 保证不会剪掉任何一个媒体分组, 因此 post-pickup delay 为零. 如果 agent 选择以这种方式延迟本地 alerting, 则 应该在 alerting 开始后生成 180 response.
12.1.2. 响应中的 offer
除了 offer 在 INVITE 中且 answer 在 provisional 和/或 200 OK response 中的用法之外, ICE 也适用于 offer 出现在响应中的情况. 在这类情况中, 这在 third party call control [RFC3725] 中很常见, ICE agents 应该在可靠 provisional response 中生成其 offers (该响应 必须使用 RFC 3262), 并且在收到 INVITE 时不要提醒用户. answer 会在 PRACK 中到达. 这允许 ICE 处理在 alerting 之前进行, 因此没有 post-pickup delay, 代价是 call setup delay 增加. 一旦 ICE 完成, callee 可以提醒用户, 然后在用户接听时生成 200 OK. 由于 offer/answer 交换已经完成, 该 200 OK 不会包含 SDP.
或者, agents 可以将 offer 放在 2xx 中 (在这种情况下 answer 在 ACK 中). 发生这种情况时, callee 会在收到 INVITE 时提醒用户, ICE 交换只会在用户接听之后进行. 这会减少 call setup delay, 但可能导致显著的 post-pickup delay 和 media clipping.
12.2. SIP Option Tags 和 Media Feature Tags
[RFC5768] 指定了用于 ICE 的 SIP option tag 和 media feature tag. 使用 SIP 的 ICE 实现 应该支持该规范, 该规范在注册中使用 feature tag, 以便通过 signaling intermediaries 提升互操作性.
12.3. 与 Forking 的交互
ICE 与 forking 的交互非常好. 实际上, ICE 修复了与 forking 相关的一些问题. 没有 ICE 时, 当呼叫发生 fork 且 caller 收到多个传入媒体流时, 它无法确定哪个媒体流对应哪个 callee.
使用 ICE 时, 该问题得到解决. 媒体传输之前发生的 connectivity checks 携带 username fragments, 后者又与特定 callee 相关联. 随后在与 connectivity check 相同的 candidate pair 上到达的媒体分组将与同一 callee 关联. 因此, 只要 caller 已收到 answer, 就可以执行这种关联.
12.4. 与 Preconditions 的交互
Quality of Service (QoS) preconditions 定义于 RFC 3312 [RFC3312] 和 RFC 4032 [RFC4032], 仅适用于 offer/answer 中列为媒体 default targets 的 transport addresses.
如果 ICE 改变了接收媒体的 transport address, 该变化会反映在一个更新的 offer 中, 该 offer 将媒体的 default destination 改为匹配 ICE 的选择. 因此, 它看起来与任何其他 re-INVITE 一样, 并完全按 RFC 3312 和 RFC 4032 处理; 这些 RFC 的适用不受媒体 destination 因 ICE negotiations 在 "后台" 发生而变化这一事实影响.
实际上, agent 不应该指示 QoS preconditions 已满足, 直到 checks 已完成并选择了要用于媒体的 candidate pairs.
ICE 还与 connectivity preconditions [SDP-PRECON] 存在有意设计的交互. 这些交互在该文档中描述. 注意, 第 12.1 节中描述的过程描述了它们自己的 "preconditions" 类型, 虽然其功能少于 [SDP-PRECON] 中显式 preconditions 提供的功能.
12.5. 与 Third Party Call Control 的交互
ICE 可与 [RFC3725] 中描述的 Flows I, III 和 IV 一起工作. Flow I 不要求 controller 支持或感知 ICE 即可工作. 只要 controller 不加修改地传递 ICE 属性, Flow IV 就能工作. Flow II 从根本上与 ICE 不兼容; 每个 agent 都会认为自己是 answerer, 因而永远不会生成 re-INVITE.
如 RFC 3725 第 7 节所述, 持续运行的 flows 需要 ICE 实现的额外行为来支持. 特别是, 如果 agent 收到不包含 offer 的 mid-dialog re-INVITE, 它 必须为每个媒体流 restart ICE, 并完成收集新 candidates 的过程. 此外, 该 candidates 列表 应该包括当前正用于媒体的 candidates.