第 3 章 信令与SDP


文档摘要

第 3 章 · 信令与 SDP 章节摘要:这是接通的第二道关。两个浏览器见面之前,必须先谈拢三件事:用什么格式收发媒体(SDP 描述)、地址怎么递给对方(候选交换)、消息按什么次序走(信令状态机)。本章从 offer-answer 模型的时机与陷阱讲起,带你逐行读懂 SDP 报文,最后动手搭一个带房间概念的 WebSocket 信令服务。协商环节的失败占线上连接故障的相当比例,本章的目标是让每一类失败在你眼前都有具体的面孔。 学习目标 读完本章,你应当能够: 画出 offer-answer 协商的完整消息流,说清 createOffer、setLocalDescription、setRemoteDescription 各自做了什么;

第 3 章 · 信令与 SDP

章节摘要:这是接通的第二道关。两个浏览器见面之前,必须先谈拢三件事:用什么格式收发媒体(SDP 描述)、地址怎么递给对方(候选交换)、消息按什么次序走(信令状态机)。本章从 offer-answer 模型的时机与陷阱讲起,带你逐行读懂 SDP 报文,最后动手搭一个带房间概念的 WebSocket 信令服务。协商环节的失败占线上连接故障的相当比例,本章的目标是让每一类失败在你眼前都有具体的面孔。

学习目标

读完本章,你应当能够:

  1. 画出 offer-answer 协商的完整消息流,说清 createOffer、setLocalDescription、setRemoteDescription 各自做了什么;
  2. 解释协商冲突(glare)是怎么产生的,并用礼貌协商模式化解它;
  3. 逐段读懂一份真实 SDP:会话描述块、媒体行、方向属性、编解码与候选行各是什么意思;
  4. 判断一份 SDP 是否支持音频双向、视频仅收、以及 simulcast 等具体能力;
  5. 设计信令消息协议,用类型字段区分 offer、answer、candidate 与控制消息;
  6. 实现一个支持房间、心跳与异常清理的 WebSocket 信令服务,并写出与之配套的客户端封装;
  7. 根据 SDP 协商报错(如 FailedToSetRemoteAnswer)快速定位是哪一侧的描述出了问题。

核心概念速览

协商的本质是一份双向确认的合同:发起方 offer 提出全部能力清单,应答方 answer 逐项勾选确认,两份文本都经由你们自建的信令通道送达对方。信令通道只搬文本不碰媒体,媒体数据随后在独立的通道里直连流动。理解「两条通道、两种数据」的分离,是本章一切内容的纲。

一句金句:SDP 是两端之间的合同文本,信令是传递合同的快递员——快递员可以换,合同格式不能乱。

子章节导航

3.1 信令职责与 offer-answer 模型——协商的骨架。信令要传哪几类消息、offer 与 answer 各自回答什么问题、设置描述的次序为什么不能乱,以及两端同时发起时协商冲突的产生与化解。读完这一节,协商的主流程代码你能从零写出。

3.2 读懂 SDP 报文——协商的血肉。SDP 看似天书,实则结构规整:会话层定全局,每个媒体行管一路流,属性行承载方向、编解码、加密与扩展。本节用一份带注解的真实报文教你按图索骥,把「看不懂协商日志」变成「一眼定位问题行」。

3.3 动手搭建信令服务——协商的快车道。从零实现一个 WebSocket 信令服务:房间与加入、四类消息的转发规则、断线清理与心跳保活,以及客户端侧的信令封装。这一节交付的是可以直接用于内网环境的完整代码。

子章节之间的逻辑关系

本章三节是「模型、语言、实现」的三级台阶:先建立协商的抽象模型,再学会读合同原文,最后把模型与合同装进一个真实可跑的服务里。

3.1 协商模型 3.2 SDP 语义 3.3 信令服务实现 ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ offer 与 answer │ │ 会话层与媒体层 │ │ 房间与消息类型 │ │ 描述设置次序 │───▶│ 方向 编解码 属性│───▶│ 转发与广播规则 │ │ 冲突与礼貌协商 │ │ 按行定位问题 │ │ 心跳与断线清理 │ └────────────────┘ └────────────────┘ └────────────────┘ 先懂规则 再懂文本 后落地代码

3.1 的模型决定了 3.2 该关注哪些行——方向属性对应你 addTrack 的决策,编解码行对应浏览器的支持清单。3.3 则把 3.1 的消息流变成服务器代码:offer、answer、candidate 三类消息的转发规则就是协商模型的服务端投影。三节合起来,构成第 4 章候选交换的运行底座。

前置知识与后续延伸

前置:需要第 1 章的全景流程(尤其是两条时间线的概念)与第 2 章的轨道概念——协商的内容本质上是「我有哪些轨道、以什么方向和能力收发」。WebSocket 的基本用法(连接、消息、事件)应当熟悉,服务端代码会用到 Node.js 的最简写法,不涉及框架。

后续:本章结束时,两端已经互相知道对方的能力与意图,但还不知道对方的网络地址——把候选地址送进连接、完成打洞,是第 4 章的全部内容。3.3 的信令服务在第 4 章会原样复用,多加一类 candidate 消息即可;第 7 章端到端实战会把本章的服务端与客户端代码合体成完整可跑的通话应用。建议学完本章就把信令服务跑起来,后面两章的实验都依赖它。


作者与出处
原作者: 灏天文库
来源:灏天文库
整理: 灏天文库整理
由灏天文库平台收录,内容或由平台用户上传,仅供学习交流
发布者: 作者: 灏天文库 转发
评论区 (0)
U