WEBRTC浅析（二） ICE 机制简介及STUN通信流程

WEBRTC ICE 简介

在这里，我会介绍一下WEBRTC 中， ICE 的机制。主要分为三个部分。

第一部分，为ICE的协议部分介绍。
第二部分，为STUN 的信令连接图。
第二部分，为WEBRTC中代码的实现流程。

一：ICE协议简析

ICE协议 RFC

1.1 Overview of ICE

                          +-------+
                          | SIP   |
       +-------+          | Srvr  |          +-------+
       | STUN  |          |       |          | STUN  |
       | Srvr  |          +-------+          | Srvr  |
       |       |         /         \         |       |
       +-------+        /           \        +-------+
                       /             \
                      /               \
                     /                 \
                    /                   \
                   /  <-  Signaling  ->  \
                  /                       \
                 /                         \
           +--------+                   +--------+
           |  NAT   |                   |  NAT   |
           +--------+                   +--------+
             /                                \
            /                                  \
           /                                    \
       +-------+                             +-------+
       | Agent |                             | Agent |
       |   L   |                             |   R   |
       |       |                             |       |
       +-------+                             +-------+
       Figure 1: ICE Deployment Scenario

ICE背后的基本思想如下：每个代理都有各种各样的candidate Transport 地址（IP地址和端口的组合,特定的传输协议(在此中始终为UDP规范)）。它可以用来与其他代理进行通信。

这些地址包括：

• 直接连接的网络接口上的传输地址
• NAT公共端的转换传输地址（a”server reflexive” address)）
• 从TURN服务器分配的传输地址（a “relayed address”）。

1.2 收集候选地址

为了执行ICE，代理必须识别所有候选地址

1.3 连通性检查(Connectivity Checks)

连接检查的基本原理很简单：

1. 按优先顺序对候选地址对进行排序。

2. 按优先顺序发起每个候选地址对的检查。

   检查表中的每个候选对都有foundation和state。foundation是 Local的和Remote的的结合。一旦开始检查，就分配已计算每个媒体流的列表。

   一共有五个STATE：

   等待：尚未对此对进行检查，可以一旦它是最高优先级的等待对，就会执行检查清单。

   * 进行中：*已经为此对发送了一个检查，但是交易正在进行中。

   成功：检查这一对已经完成并生成了一个成功的结果。

   失败：对该对的检查已经完成并且也失败了从不产生任何反应或产生不可恢复的失败响应。

   冻结：尚未执行此对的检查，但它不能然后执行直到其他检查成功，允许这样做配对解冻并进入等待状态。

     +-----------+
     |           |
     |           |
     |  Frozen   |
     |           |
     |           |
     +-----------+
           |
           |unfreeze
           |
           V
     +-----------+         +-----------+
     |           |         |           |
     |           | perform |           |
     |  Waiting  |-------->|In-Progress|
     |           |         |           |
     |           |         |           |
     +-----------+         +-----------+
                                 / |
                               //  |
                             //    |
                           //      |
                          /        |
                        //         |
              failure //           |success
                    //             |
                   /               |
                 //                |
               //                  |
             //                    |
            V                      V
     +-----------+         +-----------+
     |           |         |           |
     |           |         |           |
     |   Failed  |         | Succeeded |
     |           |         |           |
     |           |         |           |
     +-----------+         +-----------+
   

3. 确认从其他代理收到的响应。
   两个代理都对候选地址对执行检查，结果是4次握手：

   L                        R
   -                        -
   STUN request ->             \  L's
            <- STUN response  /  check
   
             <- STUN request  \  R's
   STUN response ->            /  check
   

1.4 候选地址排序（Sorting Candidates）

• 每个代理为其候选地址提供数字优先级，并将其发送以及同伴的候选人。
• 将本地和远程优先级组合在一起，以便每个代理
  对候选对具有相同的排序。

1.5 冷冻候选地址（Frozen Candidates）

1.6 安全性检查(Security for Checks)

1.7 结束ICE（Concluding ICE）

       L                        R
       -                        -
       STUN request ->             \  L's
                 <- STUN response  /  check

                  <- STUN request  \  R's
       STUN response ->            /  check

       STUN request + flag ->      \  L's
                 <- STUN response  /  check

二：STUN协议解析

具体流程如下：

1. 获取本机外网IP
2. 在STUN Server 上Allocate IP和端口
3. 收到远端发来的PING的请求后，像STUN Server 发送Permission 请求。
4. 开始向对端发送数据，做连通性检查。
5. 收到对方响应后，发起BindChannel请求，之后的RTP/RTCP数据都通过新建的Channel来发送。

三：WEBRTC 中的ICE处理流程分析

看过了ICE 的标准协议和STUN的抓包数据之后，我们现在来看一下在WEBRTC中，它的ICE是如何建立的。

1. 在P2PTransportChannel 中调用 StartGettingPorts，去STUN Server处创建 port。
2. SendRequest::allocate创建成功后，通过OnPortReady返回，通知P2PTransportChannel端口已创建好。
3. 收到对方UNKNOWN Address发来的数据包，调用CreateConnection去创建链路。
4. 发送SendRequest::permission命令，收到OnCreatePermissionSuccess，链路创建成功。
5. Send:Ping往对方端口发型数据，开始做联通性检测。
6. 通过CheckResponse，收到对方发送的响应，连通性检测完成。
7. 发送SendRequest：BindChannel来绑定channel发送数据。
8. 收到OnChannelBindSuccess，数据链路建立完成。
9. 可以开始发送RTP和RTCP数据。

喜欢的同学可以扫码加我，进WEBRTC群讨论：