sip协议详解_WebRTC/ICE/SIP呼叫延迟问题

前面的章节中笔者讨论了在ICE中更新状态和ICE选项支持的内容。这里，我们要进一步讨论ICE中媒体处理和配合SIP场景中可能面对的问题。关于在ICE在处理涉及了发送媒体和接收媒体的两个不同的流程。最后，笔者将介绍在ICE环境中，配合SIP使用时可能面对的一些问题。

说明，关于ICE环境中，针对媒体/数据处理两种规范有一定的区别。具体来说，在RFC5245规范中规范的是媒体收发处理，但是在其更新的规范RFC8445中讨论的是数据处理。首先，规范中使用的定义有所区别，另外，具体的处理流程也有所不同。这里，我们主要是根据RFC5245的规范做详解，没有根据RFC8445规范说明。因此，读者如果需要最新的关于数据收发的处理，应该参考RFC8445和RFC576(以及最新的RFC8656)。

ICE环境中发送媒体

针对发送媒体的讨论仍然需要关注三个部分的内容。实现是全部署环境中发送媒体的讨论。在全部署场景中，agent总是使用一对候选配对来发送媒体，我们称之为“selected candidate pair”。Agent将会通过已选候选配对中将媒体发送到远端候选地址，设置数据包的目的地地址和端口等于远端候选地址, 从已选配对的本地候选地址发送媒体。当本地候选地址是server 或者 peer reflexive时，媒体是从基准地址来发起。从转发候选地址发送过来的媒体需要从基准地址通过STUN服务器端发送出去，发送处理流程按照RFC5766(最新规范参考RFC8656)的规范来执行。如果本地候选地址是转发候选地址的话，RFC5245规范推荐，针对远端候选地址，agent在STUN服务器端创建一个通道。关于agent创建通道的流程按照RFC5766-11的规范执行。针对媒体流的构件的已选配对有以下三种状态说明：

• 如果此媒体流的检查列表的状态是运行状态，并且因为重启ICE，没有以前的已选配对，已选配对为空。
• 如果此媒体流的检查列表的状态是运行状态，并且因为重启ICE，存在一对以前的已选配对，已选配对等于以前的已选配对。
• 如果检查列表的状态是完成状态，针对此媒体构件来说，已选配对等于在有效列表中的最高优先级标识配对。

媒体流的构件影响着媒体流的发送方式，并且已选配对数量状态也决定agent是否可以针对具体构件发送媒体。具体来说，针对一个媒体流中的一个构件中(至少一个构件)，如果一个已选配对为空，agent一定不能对其他构件发送媒体。针对媒体流的每个构件，已选配对都有一个值的话，agent可以为此媒体流的所有构件发送媒体。注意，媒体流的一个构件的已选配对可以不等于同样构件中最近offer