完整SIP/SDP媒体协商概论-ICE选项和keepalives讨论

　　笔者在前面的完整介绍了关于后续offer/answer交互过程中offer接收和answer生成的细节。这里，笔者将介绍后续offer/answer交互中的最后一个部分-ICE选项支持，状态更新以及存活时间的讨论。在更新状态中又涉及了全场景部署的处理流程和轻量级场景的部署流程。现在，我们逐一介绍这些细节。

　　1、全场景部署处理流程

　　在全场景部署的更新处理流程中涉及了四个方面的内容需要讨论。首先，我们介绍一下关于ICE重新启动的内容。

　　在ICE重新启动之前，针对媒体流的每个构件，agent必须记住在有效列表中的最高优先级标识的配对（称之为历史已选配对）。Agent将会继续使用这些配对发送媒体流。发送媒体流的流程在后面的文章中会加以讨论。一旦目的地地址收到提示信息，agent必须刷新有效列表和检查列表中的数据。然后agent重新计算检查列表和其状态。具体处理流程参考历史文章中关于构建检查列表的流程。

　　如果在offer/answer交互中已添加了一个新的媒体流，agent必须为此新媒体流创建一个新的检查列表，还创建一个新的初始为空的有效列表。具体处理流程参考历史文章中关于构建检查列表的流程。

　　如果在offer/answer交互要移除一个媒体流或answer拒绝了offer中提供的媒体流的话，agent必须为此媒体流刷新有效列表，必须结束在任何处理过程的STUN事务。agent必须为此媒体流移除检查列表，并且取消任何待处理的ordinary checks。

　　针对全场景部署中的更新有效列表和检查列表，ICE的处理根据agent的状态和检查列表状态的不同存在很多不同流程。首先说明，除非正在ICE重新启动，否则有效列表是不会受更新offer/answer交互影响。

　　针对一个媒体流来说，如果agent的状态是正在运行状态，检查列表是已更新状态（如果状态是完成状态，检查列表已无相关性）。为了实现这个要求，agent必须使用计算流程重新计算检查列表。具体处理流程参考历史文章中关于构建检查列表的流程。在计算结果中，如果发现在检查列表中有一对配对已经是全面检查列表中出现的配对的话，其配对状态是Waiting，In-Progress，Succeeded或Failed状态的话，其状态将被拷贝到检查列表中；否则其状态将设置为封冻状态（Frozen）。

　　如果检查列表中无任何活动配对（意味着每个检查列表中的配对是封冻状态），full-mode（双方agent都使用了ICE）的 agent为第一个媒体流在有效列表中设置第一个配对，设置的第一个配对的状态为等待状态，然后把在检查列表中具有同样component ID和具有同样foundation所有其他配对设置为等待状态。

　　接下来，agent会逐一执行某个检查列表，最高优先级的配对首先开始执行。如果列表中有一个配对状态是成功状态，其component ID设置为1，然后继续执行以下处理。在同样检查列表中，如果所有其他封冻状态的配对具有同样foundation，并且在这些具有同样foundation配对中，如果它们的component ID不是1的话，agent将把这些封冻的配对的状态设置为等待状态。针对一个具体的检查列表，如果媒体流的每个构件的配对有一对在成功状态，为其他所有媒体流的第一个构件（可能在不同的检查列表中），agent将会把所有具有同样foundation，其配对状态处于封冻状态的配对的状态进行状态迁移，这些配对的状态从封冻状态设置为等待状态。

　　2、轻量级场景部署场景

　　轻量级的部署场景中关于更新列表检查的处理比较简单。如果为一个媒体流重新启动ICE，agent也必须为此媒体流重新启动一个有效列表。Agent也必须记得此媒体流的每个构件的上次有效列表中的配对（称之为历史已选配对）。然后根据流程继续发送媒体流。流程的规则定义在将来的文章中介绍。接下来，针对每个媒体流的ICE处理状态必须修改为正在运行状态。

　　3、ICE option标识

　　在实际应用场景中，我们经常遇到一些用户的反馈WebRTC的兼容性问题，自己也经常面临WebRTC的兼容性问题。我们不得不经常更新一些功能支持，同时也不得不不断学习新的知识。其实，我们从RFC5245以及其最新规范8445中就可以看出，这些处理流程在最近几年内进行了很多次修改。现在，我们介绍一个特殊的ICE选项。除了在RFC5245中规定的ICE启动流程以外，在最新的RFC8445中增加了一个ICE选项-ice2 选项。当ICE agent在候选交互中包含了ice2选项以后，表示需要遵从RFC8445规范。在一些特定的交互中使用ice2让对端peer获悉agent也不再使用此交互流程。例如，在RFC8445中已经移除了主动推荐标识的流程（aggressive nomination procedure），如果agent需要通知对端不再使用此交互流程时，可以增加一个ice2选项来表示。

　　一个agent如果遵从RFC8445的话，在候选地址交互开始时必须通过ice2通知对端peer其交互模式启用了ice2选项。否则，对端可能收到一个未知的ice选项。

　　关于对ice2的编码和对对端peer的消息传输，读者可以参与RFC4566中的参考规范。在其参考规范中详细说明了ICE-SIP-SDP的细节。最新的草案参考链接如下：

　　ice-sip-sdp：

　　https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-39

　　另外，再次提醒读者，如果要开发最新的SIP和WebRTC的业务应用的话，因为ICE处理流程中SDP的频繁更迭，读者一定要关注最新的RFC8445规范以及关于SDP构建的草案。

　　4、Keepalives

　　无论是否使用ICE或者媒体流的状态如何，keepalives是终端保持存活的重要手段。大家知道，为了终端保持状态的活动状态，所有的终端都必须不断向服务器端发送存活消息。针对媒体会话来说，存活消息的目的就是为了保持NAT绑定存活状态。无论媒体流状态是inactive，sendonly，recvonly还是sendrecv状态，并且也不管在线状态，带宽属性设置状态，终端必须发送keepalives。即使周期会话中完全没有使用ICE，终端也必须发送keepalives。终端应该使用对端peer能够支持的格式来发送keepalives。ICE终端允许基于STUN的keepalives支持UDP的流。具体来说，当agent是一个全场景部署的agent，并且和对端peer（轻量级部署场景或全场景部署agent）通信时，它们之间必须使用STUN keepalives。agent能够通过每个媒体会话中属性a=candidate状态决定对端peer支持ICE。如果对端peer不支持ICE的话，keepalives数据包格式的选择是本地部署的事情。根据RFC5245的推荐，keepalives的格式最好是这样的格式-在实际媒体内容缺失的情况在，其格式支持数据可以非常容易发送出去。比较典型的两个例子是RTP No-Op和RTP的舒适噪音处理。如果对端peer不支持任何目前比较采用的keepalives格式的话，agent应该使用一个不正确的版本发送RTP数据包或者其他格式发送（当然，peer可能会丢弃这些错误数据）。

　　在Tr秒时间内，为了一个媒体构件的处理流程，ICE使用一个候选配对发送数据，如果此候选配对中没有数据发送，agent必须为此配对生成一个keepalives。Tr值应该是可配置的值，默认设置为15秒。Tr值一定不能低于15秒设置。另外一种处理方式是，如果agent通过动态方式可以发现intervening NAT的绑定生命周期的话，agent可以使用这个绑定生命周期来设置Tr值。系统管理人员是在自己可控的网络环境中部署ICE，在网络环境允许的情况下，Tr值应该尽可能的长一点。

　　如果keepalives使用了STUN，STUN绑定指示需要根据RFC5389规范来执行。此绑定指示不能使用任何认证机制。绑定指示中一个包含FINGERPRINT属性实现多路分用，但是不能包含任何其他的属性。此绑定指示仅用来维持NAT绑定存活处理。绑定指示通过同样的发送媒体的本地和远端候选地址来发送。虽然绑定指示是用来处理keepalives，但是agent仍然也需要准备好接收连接检查。如果agent收到了一个连接检查的话，agent应该根据RFC5389生成一个响应消息，但是，这个处理不会影响ICE的处理。

　　一旦ICE选择了候选配对准备发送媒体流，或媒体开始传输，无论以上两种方式哪种方式首先发生，agent必须开始keepalives的流程处理。一旦会话结束或媒体流被移除，keepalives也需要马上结束。

　　这里需要补充一点关于keepalives和Voice Activity Detection （VAD）一些讨论。实际环境中，keepalives 在实际数据缺失的情况下发送，所以实际环境中如果没有使用VAD的话，从来不会产生keepavlives消息发送的情况，因此也不会存在带宽增加的可能性。当启用VAD时，keepalives消息是在静音期发送，会在每15秒-20秒之间发送一个单数据包，此数据所占用的网络资源远小于语音数据发送状态下的（每20-30毫秒之间发送）所需要的网络资源。因此，keepalives的影响不会对环境部署中网络带宽有很大的影响。

　　读者注意，因为keepalives涉及了多种网络环境的连接，网络设备的部署也非常复杂，简单的一种规范很难完整说明全部的具体场景。笔者可以根据不同的场景做进一步的研究：

　　关于keepalives的优化，读者可以查阅草案的3.4章节：

　　https://tools.ietf.org/id/draft-ietf-pcp-optimize-keepalives-00.txt

　　关于keepalives的讨论，一些规范和浏览器支持做了一些调整，读者可以查阅笔者参考资料链接获得详情。RFC5245仅提供了ICE的keepalives的讨论，读者也可以结合RFC6263关注RTP中NAT绑定中的keepavlives的讨论。

　　参考资料：

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

　　https://tools.ietf.org/id/draft-ietf-pcp-optimize-keepalives-00.txt

　　https://www.cisco.com/c/en/us/support/docs/ip/serial-tunnel-stun/16398-50.html

　　https://tools.ietf.org/html/draft-muthu-behave-consent-freshness-04

　　https://tools.ietf.org/html/rfc6263

　　https://www.semanticscholar.org/paper/NAT-Traversal-Techniques-and-UDP-Keep-Alive-Widmer/9f730e024dd212186c7b2ced75c877edad6951f0

　　https://www.rfc-editor.org/rfc/rfc8445#section-10