ICE协议摘录---draft-ietf-mmusic-ice-19

1、简介

  ICE协议是一种NAT穿透技术,用于通过offer/answer模型建立的基于UDP的流媒体传输场景(可以扩展来处理其它协议如TCP)。ICE协议是offer/answer模型的一种扩展,使用在SDP offers和SDP answers中提供的多个ip地址及端口工作,这些IP及端口会被用于连通性检查(connectivity check) 连通性检查通过修正过的STUN协议[Session Travelsal Utilities for NAT]进行。 ICE也使用TURN协议。
ICE协议摘录---draft-ietf-mmusic-ice-19_第1张图片

2、ICE协议预览

  典型的ICE使用场景中会有两个需要进行通信终端(endpoint)叫做agent。这个两个agent能通过使用一些信令如sip来进行间接的SDP信息交换。 ICE启动时,agent并不知道他自身的网络拓扑结构,但是ICE允许agent去发现他自己的拓扑结构和找出两个agent之间可能进行通信的所有网络路径。
ICE协议摘录---draft-ietf-mmusic-ice-19_第2张图片
  下图展示了ICE使用的典型场景。两个**agent分别是 L 和 R,都位于各自的NAT之后,而且NAT的类型及属性未知。这个两个agent能通过offer/answer模式来交换SDP信息。一般的这个SDP信息交换是通过sip服务器来进行的。
ICE协议摘录---draft-ietf-mmusic-ice-19_第3张图片
  每个agent都有自己的STUN或TURN服务器。 ICE协议的本质:每一个agent有一系列的
候选传输地址**(这些候选地址由ip地址、端口及传输协议构成,在这个文档里传输协议只能是UDP)可用于与其它agent通信。这些可用于和其他agent通信的候选地址可能包括以下几种:

《1》、内网地址;
《2》、server reflexive地址:服务器反射地址,一般是agent所在的NAT的公网地址;
《3》、中继地址(relayed addreaa):TURN 服务器分配的传输地址;

ICE协议摘录---draft-ietf-mmusic-ice-19_第4张图片
   理想情况下L的所有候选地址都能与R通信,但是通常情况下L的大多数候选地址是不能和R通信,此时就需要ICE协议去发现L和R的哪些地址对之间是可以通信,这也是ICE存在的原因。ICE通过有组织的尝试所有可能地址对来发现可用的地址对
ICE协议摘录---draft-ietf-mmusic-ice-19_第5张图片

3、收集候选地址

  候选地址一般有三种—本机地址,服务器反射地址及中继地址。agent会使用STUN或TURN协议来发现候选地址。当有使用TURN 服务器时,服务器反射地址及中继地址都通过TURN协议被发现。如果只使用了STURN服务器,则只能发现服务器反射地址。
TURN协议是使用Allocation请求,STUN协议是使用STUN Bing Request
ICE协议摘录---draft-ietf-mmusic-ice-19_第6张图片

4、连通性检查(Connectivity Checks)

  当L将它的候选地址采集完毕之后,它会将他们按照优先级从高到低排序然后通过信令通道(如sip信令)发送给R。当R接收到这个消息后会进行相同的候选地址流程然后将自己的候选地址通过响应信令的方式发送给L。当这个流程结束是L和R都拥有了自己和对端的所有候选地址的列表。 接着L和R都会将这些候选地址配对,产生所有可能的候选地址对列表。为了检测哪对地址可用,每个agent会进行一些列的CHECK操作。每个检测都通过在一个地址对之间发送STUN Binding请求/响应事务来实现,客户端发送STUN Bind请求,对端响应该请求
ICE协议摘录---draft-ietf-mmusic-ice-19_第7张图片
基本的连通性检查流程:
ICE协议摘录---draft-ietf-mmusic-ice-19_第8张图片
  注意:STUN请求的发送和接收使用的IP地址和端口必须和流媒体(如RTP和RTCP)使用的的IP地址及端口一致。因此agent通过数据包的内容来分辨STUN和RTP/RTCP而不是使用端口来进行。
ICE协议摘录---draft-ietf-mmusic-ice-19_第9张图片
   因为STUN Binding被用于连通性检查,所以STUN Binding响应会包含agent的所在的NAT的公网传输地址。如果该公网传输地址不在已经保存的候选地址列表中,这个地址会成为新的候选地址,成为对端反射地址(PEER REFLEXIVE CANDIDATE)。 当R接收到L发送的检测消息时,R马上在相同地址对上发送一个联通检测消息给L。这样做加速了查找有效地址对的流程,称为触发检查(TRIGGERED CHECK)
ICE协议摘录---draft-ietf-mmusic-ice-19_第10张图片
抓包:
ICE协议摘录---draft-ietf-mmusic-ice-19_第11张图片
ICE协议摘录---draft-ietf-mmusic-ice-19_第12张图片

5、候选地址排序

   为了能更快的找到候选地址对,agent会按照特定规则对候选地址进行排序。排序后的候选地址对称为CHECK LIST。该特殊规则简化为一下两点:
《1》、每个agent将候选地址一个数字优先级,然后该优先级随地址一起被发往对端。
《2》、将本地及对端的优先级组合在一起,这样每个agent就拥有了一样的候选地址对排序列表。
ICE协议摘录---draft-ietf-mmusic-ice-19_第13张图片
   如果R和L都位于NAT之后,上面第2个规则对ICE来说就非常重要。NAT一般会将来自外部主机不请自来的数据包丢弃,除非位于NAT内部的agent先发送给外部主机(建立NAT映射表)。因此当位于NAT内部的两个agent都未发送check请求之前,ICE 在两个方向的连通性检查会失败。
ICE协议摘录---draft-ietf-mmusic-ice-19_第14张图片

6、Fronzen候选者COMPONENT

   媒体流中仅含有一个传输地址的部分,如音频,视频都算一个**COMPONENT**;每个媒体流可能包含很多component,每个component都单独的为这个媒体流执行所需功能。对于基于RTP的流媒体,它有两个component,一个是RTP,另一个是RTCP。
ICE协议摘录---draft-ietf-mmusic-ice-19_第15张图片

7、Concluding ICE(ICE推断??)

   ICE将一个agent命名为CONTROLLING AGENT,与之通信的另一个为CONTROLLED AGENT。controlling agent会从所有有效的候选地址对中推荐一个用于媒体传输。这种推荐通过可通过以下两种方法实现:
REGULAR NOMINATION: controlling agent通过该方法进行连通性检测时会一致按列表顺序检测,直到遇到至少一个可用地址对。controlling agent选中该地址对后会在该地址对上发送第二次STUN请求,这个请求需要携带一个flag标志,用以告诉对端这个地址是controlling推荐使用的地址。一旦对端对对这个带flag的地址进行了正确响应,两个agent端的剩余地址对检测就要全部停止,接下来就要用这个推荐的地址来进行媒体传输,这个推荐的地址对被称为SELECTED PAIR。
ICE协议摘录---draft-ietf-mmusic-ice-19_第16张图片
AGGRESSIVE NOMATION: 在使用该种方法是,controlling agent发送的每个STUN 请求都带有flag标志,因此无需发送第二次STUN 请求。这种方法比regular推荐方法快但是没那么灵活。
ICE协议摘录---draft-ietf-mmusic-ice-19_第17张图片

ICE协议摘录---draft-ietf-mmusic-ice-19_第18张图片

8、简化实现(Lite Implementations)

为了使ICE在电话拨打中使用,两边agent都需要支持简化版本的ICE实现。对于只实现简版的agent其需要有一个公网IP简化版本的ICE不会收集候选地址,其候选地址只包含本机IP,也不包含任何状态机(进行连通性检查时候选地址对有状态变化)。 简化版本的ICE不需要进行连通性检查,只需要对发送过来的连通性检查进行响应。 当一个简化版本的agent和全面版本的agent连接时,后者充当controlling角色,前者作为controlled。当两个简版agent进行连接时,两个agent都不会进行连通性检查。

9、原网站

你可能感兴趣的:(流媒体)