第三章 连接建立与信令协商

第三章 · 连接建立与信令协商

本章要回答的三个问题：一条连接从创建到可用，引擎内部的状态机器是怎么一步步推进的，每一步的触发条件是什么？双方交换的那段会话描述文本里到底写了什么，引擎如何据此达成媒体能力的共识？两个躲在 NAT 后面的终端，怎么把彼此可达的线路一条条试出来并选出最优？

为什么会有这一章

对电话总局来说，最难的不是通话中的维护，而是接线的那几十秒：登记、核对、测线、选中、接通，每一步都要留下可追查的记录。WebRTC 的连接建立是同一种工程：时间短、步骤密、跨两端协同，还是全书唯一一个"协议规定必须这样走"的强时序区域。前面两章的架构与线程知识在这里密集兑现——协商状态机活在信令线程上，候选检查跑在网络线程上，状态推进的每个环节都有日志可查。

这一章也是线上问题的高发区：产品侧反馈的"连不上""时好时坏""有人能连有人不能"，绝大多数最终落在这一章的三个环节上。状态机没推进到位、会话描述协商不出交集、候选线路全部不通，三类问题各有各的表象与查法。把本章读懂，你就拥有了处理这类工单的系统方法，而不是在信令代码里碰运气。

本章还有一层架构史的意义：连接建立区域是新旧模型交替最剧烈的地方。旧的以媒体流为中心的协商方式与新的以收发器为中心的方式并存了多年，今天读到的代码里两套痕迹都有。理解本章的时序，也顺便理解了这套代码库的演进逻辑——为什么有些函数签名看起来"多此一举"，那是历史协议兼容的代价。

图：建连时序总览与责任分界

读完能解决什么

对照三个问题给结果。其一，你能背出连接建立的阶段序列与每阶段的线程归属，看到"卡在某个状态不动"时能立刻列出该状态的进入条件并逐项排查。其二，你能独立读懂一份会话描述文本：媒体段落的构成、编解码列表的含义、传输参数与安全指纹的位置，并能对两份不同引擎产出的文本做逐行比对，解释差异从哪来、哪些差异会致命。其三，你掌握穿越问题的完整分析框架：三类候选的来路与适用场景、检查的成对逻辑与选线依据，抓包文件里的穿越报文你能逐字节解释。配合第八章的部署知识，你还能判断"哪些用户连不上"是服务端配置问题还是网络环境问题。

各节怎么分工

三节按时序串联：状态机是骨架，协商填充骨架的语义，穿越检查让骨架动起来。3.2 与 3.3 在真实建连里是并行的，阅读时先学 3.2 是因为它定义了 3.3 要用的字段——候选信息就写在会话描述里。

先决条件

需要第二章的线程模型（信令线程与网络线程的分工），以及第一章 1.1 的协议族表。如果你对 NAT 的基本行为（内网地址对外不可直达、出口处有地址映射）还不熟，建议先补这一课，3.3 的全部设计都建立在这个前提上。

实验准备也给一条：本章的三个环节都能在演示程序上复现与观察。3.1 的状态跃迁可以在应用层注册状态回调打印时间线；3.2 的会话描述文本可以在协商完成后导出比对；3.3 的候选与检查过程在信息级日志与抓包里都有完整痕迹。带着实验读时序类的知识，比纯阅读的记忆留存率高得多——时序知识的本质是"先后关系"，而先后关系最好用眼睛确认。

往下走到哪

本章的出口通向第六章：连通性检查选出的线路与协商达成的参数，最终要靠 RTP 打包与加密握手才能承载真正的媒体。第四章与第五章虽在章节顺序上先于第六章，但它们讲的是媒体内容的加工，不依赖本章；如果你想沿着"建连"这条线一口气走完，也可以读完本章直接跳到第六章，把第四、五章当作插进来的深度专题。