完整SIP/SDP媒体协商概论-关于ICE流程结束处理

　　笔者在前面的两篇文章中分别介绍了STUN客户端处理流程和服务器端处理流程。在本文章中，我们将针对ICE的最后一部分的处理进行总结，这个章节包括ICE的流程结束的处理。ICE流程结束需要从两种部署场景的agent来讨论。一种是全场景部署agent的处理流程，另外一种是轻量级的部署场景agent处理流程。另外，ICE结束流程的最后还要进行对封冻候选地址的处理。和前面的文章一样，笔者这里仍然还是重点讨论全场景部署agent的处理流程，然后针对轻量级场景中agent的部署进行讨论，最后对ICE结束对封冻候选地址进行讨论。

　　1、全部署场景处理流程

　　针对全场景部署agent的处理流程中，关于ICE结束的流程涉及了推荐配对和状态机更新两个部分的内容。其中，推荐配对是由被控方agent产生。接下来，笔者会继续讨论推荐配对的处理流程。

　　2、推荐配对

　　刚才笔者已经提到，推荐配对是由被控方产生的。ICE通过Regular Nomination（正常推荐方式）或Aggressive Nomination（主动推荐方式）来选择推荐配对。选择何种方式对推荐配对进行算法处理，取决于对端pper的部署场景。如果对端peer支持的是一个轻量级部署场景，agent必须使用Regular Nomination算法来处理。如果对端peer使用了ice-options属性（ICE options），agent不能理解此选项的话，agent必须使用Regular Nomination算法。如果对端peer支持全场景部署，并且没有使用任何ICE选项或者使用了ICE选项（但是，agent可以理解），agent可以选择使用Regular Nomination或者Aggressive Nomination算法。但是，因为Regular Nomination的稳定性比Aggressive Nomination要好，所以，RFC5245规范推荐使用Regular Nomination算法。下面，笔者分别对这两种算法进行完整介绍。

　　图片来自于互联网

　　当推荐配对使用Regular Nomination时，agent会让一些检查流程完成处理，在检查的每个流程中会忽略掉USE-CANDIDATE属性。针对一个媒体流构件来说，一旦一个或多个检查成功完成，成功检查完成后会生成有效配对，有效配对然后添加到有效列表中。Agent会让检查继续执行，直到检查遇到某些评判标准，然后根据某些评判标准选择有效配对。停止检查的评判标准和评估有效配对标准完全取决于逻辑优化本身自己。

　　当被控方agent选择了一对有效配对时，它会重复这个生成有效配对的检查，并且这次使用USE-CANDIDATE属性。因为前面的检查是成功的，所以，理论上讲，这个检查应该也是一个成功的检查。针对检查的逻辑处理方式会对配对增加一个推荐标识（nominated flag），并且仅支持这个配对。因此，针对每个媒体构件来说，在有效列表中仅有一个单个支持了推荐标识配对，并且，当检查列表的状态切换到完成状态后，ICE会选择正确配对来针对媒体构件发送和接收媒体流。根据以上介绍，读者可以看出，因为agent可以控制检查停止和检查的评判标准，因此，Regular Nomination具有更大的灵活性。这里只有一个要求，agent最后选择一个配对或者只能选择一个候选配对，然后针对此配对（支持USE-CANDIDATE属性）生成一个检查。通过增加拓展支持，Regular Nomination同时提高了ICE的适应能力，可以支持多种部署场景的变化。Regular Nomination具有更高的稳定性，它可以允许双方agent通过单个配对实现媒体支持，无需其他临时选项支持（Aggressive Nomination需要临时选项支持）。但是，Regular Nomination也有其缺点，因为Regular Nomination需要额外检查完成，因此，Regular Nomination肯定会增加处理时延。通过以上内容的介绍，笔者描述了Regular Nomination算法的处理方式，接下来，笔者介绍一下Aggressive Nomination算法的使用方式。

　　当使用Aggressive Nomination算法时，在agent发生的每个检查中，被控方agent会包含一个USE-CANDIDATE属性，针对一个媒体构件的检查中，一旦第一个检查是成功的，这个配对就会被添加到有效列表中，然后设置一个推荐标识。在有效列表中，所有构件的配对都设置了推荐标识后，媒体开始通过最高优先级的推荐标识配对进行传输。但是，因为agent在所有的检查中都包含了USE-CANDIDATE属性，在所有的检查中，有可能部分其他的检查还没有完成，这样就会引起其他有效配对会产生自己的推荐标识设置。因为，ICE总是从有效列表中选择最高优先级推荐标识的候选配对来进行媒体传输。因此，当ICE检查完成时，已选择的配对可能实际上暂时发生了修改，这样就会导致一系列的临时选择作为一个缓冲（三秒延迟规则，后面讲到），直到ICE检查稳定后，这样的状态才能结束。因为这个问题，因此，相对于Regular Nomination算法来说，Aggressive Nomination缺乏一定的稳定性。但是它不会增加检查延时。

　　3、更新ICE处理状态

　　无论是对于主控方agent还是被控方agent来说，ICE的处理状态取决于在有效列表中标识候选配对的当前状态和检查列表的状态。任何时间内，以下五种场景可能发生在这些处理状态中。现在，我们具体介绍一下这五种可能发生的场景。

　　对媒体流来说，如果在有效列表中没有已设推荐标识的配对，并且检查列表状态是正在运行中，ICE处理将会继续执行。

　　对媒体流来说，如果在有效列表中至少有一对已设推荐标识的配对，并且检查列表状态是正在运行中，则继续进行以下处理流程：

Agent必须移除在检查列表中所有等待状态和封冻状态的配对，并且为同样component（构件）启动一个triggered check queue，作为标识配支持此媒体流。
如果在检查列表中的一个In-Progress配对作为标识配对支持同样构件的话，如果配对的优先级低于最低优先级标识配对，针对此构件来说，agent应该清除检查的重传处理流程。
对于至少一个媒体流的每个构件来说，在有效列表中一旦至少有一对标识配对，并且检查列表的状态是正在运行中的状态，需要进一步执行以下流程：
Agent必须为此媒体的检查列表进行状态修改，修改其状态为完成状态。
Agent必须继续对任何检查做出响应，这些检查可能仍然是agent用来接收媒体的响应，并且，如果STUN 服务器端流程要求的话，agent必须执行triggered check。
Agent必须为检查列表继续重传任何In-Progress 检查。
Agent可以开始为媒体流传输媒体，为全场场景部署agent和轻量级场景部署agent发送媒体的处理流程将在后续文章中介绍。

　　一旦每个检查列表的状态是完成状态，要求执行以下流程：

　　Agent设置所有的ICE处理状态是完成状态。

　　如果agent是正在处于被控状态，此agent会为每个媒体流的每个构件检查最高优先级已标识的候选配对。如果它们中的任何候选配对不同于在最近offer/answer交互消息在的默认候选配对，被控方agent必须生成一个更新的offer。具体的生成方式根据后续offer/answer交互模式的处理流程进行。

　　如果被控方agent正在使用Aggressive Nomination，当配对选择时，它可能导致多个更新offers。Agent可以延迟发送此更新的offer，通过一定的时间设置进行控制（RFC5245规范建议设置为一秒钟），这个时间可以保证其已选配对进入稳定状态。

　　如果检查列表的状态是失败状态，ICE将不能为完成针对媒体流的处理。正确的处理方式依赖于对其他媒体流的检查列表状态：

如果所有的检查列表的状态是失败状态，所有ICE处理的状态将认为是失败状态，并且，agent应该认为此会话是一个失败的会话，agent不应该重新启动ICE处理流程，被控方agent应该结束整个会话。
针对其他媒体流来说，如果在检查列表中至少有一个检查的状态是完成状态，被控方agent应该在其更新的offer中从此会话中移除此失败的媒体流。
针对其他媒体流来说，如果在检查列表中没有任何检查是完成状态，但是，至少有一个检查是正在运行状态，agent应该让ICE进行执行。
到此为止，关于ICE结束处理中全场景部署agent的处理流程就已经结束。接下来，笔者将讨论针对轻量级部署场景agent对ICE结束流程的处理。

　　4、轻量级部署场景处理流程

　　针对轻量级部署场景agent来说，ICE结束流程相对比较直接。这里有两个情况需要注意：

部署场景是轻量级的部署场景，对端peer是全场景部署场景
部署场景是轻量级部署场景，对端peer也是轻量级部署场景

　　ICE结束处理会给agent带来一个后续影响，agent能够清除任何已分配的候选地址（ICE没有使用这些候选地址）。关于清除已分配候选地址的处理方式，笔者在本文章的后续部分介绍。

　　如果对端peer是全部署场景的话，这种情况下，agent将会收到peer的连接检查。当agent已经收到来一个连接检查，这个检查中包含了针对一个媒体流的每个构件所支持的USE-CANDIDATE属性，此媒体流的ICE处理状态将要从正在运行状态迁移到完成状态。当针对所有媒体流的ICE处理状态是完成状态的话，所有ICE处理状态都是完成状态。轻量级部署从来不自己决定针对媒体流的ICE流程失败处理，而是宁愿让全场景部署的agent来决定。在后续的offer中，针对失败的媒体流，全场景部署将做出决定，移除或重新启动这些失败的媒体流。

　　如果对端peer是轻量级peer的话，ICE结束处理的流程相对比较复杂一些。一旦offer/answer交互模式完成后，双方agent都会检查它们的候选地址和它的peer的候选地址。针对每个媒体流，每个agent将会使用自己候选地址和对端peer的候选地址进行配对处理。当它们具有同样的component，使用同样的传输协议（RFC5245使用UDP传输协议），并且来自于同一IP地址类型（IPv4或IPV6），那么这两个候选地址就会配对。在生成配对后，针对每个媒体流构件中的配对数量有两种处理方式：

　　如果在每个媒体构件中，有一个单个配对的话，此配对会添加到有效列表中。如果一个媒体的所有构件只有一个配对的话，针对此媒体流的ICE处理状态将会设置为完成状态。如果所有媒体流的ICE处理状态是完成状态的话，所有ICE处理状态将会设置为完成状态。这种部署环境经常会发生在IPv4的网络环境中。

　　如果在每个构件中，有多于一个以上的配对的话，需要执行以下几个步骤：

Agent必须基于本地策略选择一个配对。因为，这种情况仅发生在IPv6的环境中，RFC5245推荐agent需要根据RFC6724的处理流程选择一个单个配对。
Agent会在有效列表中为每个构件添加此已选配对。然后允许开始发送媒体。这里要注意，但是在实际环境中，可能双方agent已选择了不同的配对。

　　为了保持双方agent的配对的一致性，被控方agent必须发送一个更新的offer，在这个更新的offer中包含一个remote-candidates属性设置。关于更新offer的发送处理流程，笔者在将来的讨论中介绍。

　　当offer发送以后，agent一定不能更新ICE处理状态。针对所有媒体流，如果此后续offer完成处理，主控方agent必须修改ICE处理流程状态为完成状态，并且设置所有ICE处理状态为完成状态。主控方agent的状态设置则基于轻量级部署场景的流程来进行处理。

　　5、封冻候选地址

　　在ICE结束处理的流程中，包括两种对后选地址的封冻处理。一种是全场景部署中封冻处理，另外一种是轻量级的部署场景封冻处理。接下来，笔者分别对其流程进行说明。

　　首先介绍全场景中关于封冻处理的流程。ICE结束处理的流程要求agent继续监听STUN请求，一旦对其媒体流的处理完成后，继续对媒体流生成triggered checks。RFC5245介绍了一种规则，规则描述了当agent处于安全状态时，它在一个候选地址（ICE没有选择此候选地址，然后释放候选地址）终止发送或接收检查。

　　当SIP网络中使用了ICE，并且offer被经过分叉处理发送到多个接收方时，ICE将会使用同样的本地候选地址并行和每个自己的answer进行处理。对所有使用那些候选地址来传输媒体流的peers来说，一旦ICE处理流程状态达到完成状态，agent应该等待另外三秒钟，然后agent可以终止对检查的响应，或在那个候选地址生成一个triggered checks。Agent可以在那个等待时间释放候选地址。注意，服务器端反射候选地址的封冻处理从来不会被明确声明，keepalive的缺失会启动封冻处理流程发生。三秒延迟的规则策略可以处理如下场景，具体来说，ICE已经完成后，agent使用了aggressive nomination算法，然后对已选配对进行快速修改。

　　轻量级部署场景中ICE结束处理相对比较简单。对所有使用那些候选地址来传输媒体流的peers来说，一旦ICE处理流程状态达到完成状态，轻量级部署场景可以释放任何没有被ICE选择的候选地址。

　　完成了关于ICE的讨论以后，笔者将进一步讨论关于后续offer/answer交互中的offer生成，answer接收，更新offer等细节。

　　参考资料：

　　https://www.rfc-editor.org/rfc/rfc6724

　　https://www.rfc-editor.org/rfc/rfc3484

　　https://www.rfc-editor.org/rfc/rfc5245.html

　　https://datatracker.ietf.org/meeting/93/materials/slides-93-mmusic-3

　　https://bugzilla.mozilla.org/show_bug.cgi?id=1034964