ICE 实现流程(3) answer方的关键行为

......

生成连通性检查列表:

只有在ICE的完整实现中才有的步骤.

在轻量的ICE实现中省略这个步骤.offer/answer的交换导致每一个在使用的媒体流都有一个连通性检查列表.要构成这个表,agent生成候选者对,计算候选者对的优先级,按优先级来排序候选者对,清除他们中存在的冗余,设置他们的状态.

生成候选者对:

首先,agent将一个媒体流的每一个候选者(LOCAL CANDIDATE),将它们和peer端接受的候选者(REMOTE CANDIDATE)配对.为了避免由此引发的攻击,agent是限制在一次请求和应答中接受的 候选者,本地和远程候选者当且仅当有着相同的component ID和相同的IP地址版本的时候才进行配对.有可能存在本地和远程候选者中的一些不能找到相应的配对.这种情况发生在一个agent没有把对应一个媒体流的所有候选者算为候选者,它们的component是相同的.

这时候,对应于那个媒体流的组件数实际上等效于减少了,等于每一个agent提供的这个媒体流的的全部组件中最大的那个组件ID中的那一个中组件ID最小的那一个.

比如说RTP的情况:一个agent支持RTCP的候选地址,另一个不支持.还有多路复用RTP和RTCP在一个 端口.这个时候offer多路复用RTP/RTCP在同一个port,这可以通过在SDP中添加新的属性来实现,然而offer不知道是否answerer有多路复用的能力,所以它RTP和RTCP的候选者在不同的端口上,这时候offer的每个媒体流有两个component.如果answerer可以执行多路复用,一个候选者对于一个组件.

+------------------------------------------+

| |

| +---------------------+ |

| |+----+ +----+ +----+ | +Type |

| || IP | |Port| |Tran| | +Priority |

| ||Addr| | | | | | +Foundation |

| |+----+ +----+ +----+ | +ComponentiD |

| | Transport | +RelatedAddr |

| | Addr | |

| +---------------------+ +Base |

| Candidate |

+------------------------------------------+

* *

* *************************************

* *

+-------------------------------+

.| |

| Local Remote |

| +----+ +----+ +default? |

| |Cand| |Cand| +valid? |

| +----+ +----+ +nominated?|

| +State |

| |

| |

| Candidate Pair |

+-------------------------------+

* *

* ************

* *

+------------------+

| Candidate Pair |

+------------------+

+------------------+

| Candidate Pair |

+------------------+

+------------------+

| Candidate Pair |

+------------------+

Check

List