作者：Lasse Lumiaho，Marcin Nagy，Callstats.io（原文链接）
翻译：刘通
对于一个WebRTC会议来说，会话建立过程可能是最关键的过程。在这个阶段中，用户需要给它们的设备进行授权，并且终端要协商设置内容以适用于每个会话参与方的建立过程。这个建立过程在用户成功互相连接之后，或者连接失败之后结束。在本篇博文中，我们将会介绍网络会议建立过程中的不同阶段，以及用来判定会议建立质量的相关参数。
会议建立的阶段
WebRTC会议的建立阶段有很多阶段，有些可以平行进行
想要建立一个WebRTC会议，终端需要计算出适用于所有人的一套设置。会话描述协议（SDP）的目的是传输关于多媒体会话中媒体流的信息，以允许会话描述的接收者可以参与到会话中去。信令协议携带例如媒体类型（音频或者视频）、codec、传输协议的视频，以及需要用于接收媒体（尤其是ICE候选）的信息。有了ICE候选（比如用户和服务器的IP地址，端口号），WebRTC用户就能决定如何穿过NAT和防火墙，直接地与其他人相连接。
候选项会被进行优先化处理之后，再根据每个会话参与方的候选项优先级列表发送给其他参与者。在交换的过程中，终端开始进行连接检查，当终端之间发现合适的候选项时连接检查结束。连接检查结束后，会议开始并且开始媒体流传送。
上文描述了一个线性的过程，但是有些步骤可以平行的运行。
会议建立阶段中可能发生的失败
由于握手步骤的复杂特性，在建立过程中有很多容易出错的地方。我们将这些可能出现的失败情况分为大致三类：
媒体流方面的失败情况
#没有工作的设备：媒体设备无法连接（例如被其应用占用等等）
#没有许可：用户拒绝给应用进行授权
#错误的约束条件：应用对媒体设备进行的设置不能满足（例如太高的帧速率）
想要了解更细节的解释，请阅读此篇博文“访问用户媒体过程中可能出现的错误”
协商方面的失败情况
#SDP生成错误：由于发生某些错误导致SDP邀请无法生成
#协商失败：无法寻找到密码机共同的配置，网络和媒体配置失败
NAT/防火墙穿越过程中失败
#ICE连接失败：由于进行限制的NAT或防火墙导致的检查失败
#中途失败：检查还没有完成，或者还没有出现失败状况之前用户就已经断开了通话
我们还会在会议建立完成之后遇到问题，比如抖动，重协商失败，连接中断，丢失等等。
与会议建立相关的参数
我们已经证明了建立过程是重要的环节，为了帮助debug在会议建立过程中出现的问题，我们介绍与下面四个阶段相关的参数
#建立延时
#收集延时
#连接检查延时
#到第一个媒体的时间
建立延时
从加入会议知道连接检查完成，建立延时指的是准备从另一终端发送和接收媒体的准备时间。连接会努力的减少建立延时，例如扭曲实施连接检查的间隔。从2016年秋天以来建立时间减少了30%。根据经验法则，如果建立延时超过了5秒钟，就认为延时时间太长了。
收集延时
ICE收集延时是终端收集所有ICE候选项与终端相关联所花费的时间。这其中包括主机，对等端和服务器反射候选项。有些服务一旦候选项可用之后就开始进行协商。但是某些其他服务会在终端用户想要进行通话之前就开始收集并缓存候选项，并且对其进行更新。
80%的WebRTC会话收集延时小于100ms。另一方面，有大概5%的WebRTC会话ICE收集需要花费多余1秒的时间。降低收集延时的关键之处使将TURN服务器部署在尽量靠近终端用户的地方。
连接检查延时
ICE连接检查延时是从连接检查开始到终端选择了候选项的时间。这项参数包含了终端之间的网络延时，也就是如果一对终端用户在地理上离得很远的话，那么检查时间就会更长。
另一个影响检查的因素是多长时间发送一次，也就是两个连续的检查之间相隔的时间。如果间隔很长的话，检查就会花费更长的时间。在2016年十月份，对于20%的WebRTC会话的检查延时要小于100ms。
到第一个媒体的时间
会议参与方会经历另一种延时，举个例子，从按下拨打键开始到当他第一次看见或听见对方为止。到第一个媒体的时间（Time to First Media，TTFM）描述了这种延时，而且这是用户在实际使用中可能会反应给你的一项数据。理想情况下，TTFM应该只比建立延时稍微长一点点。
