1. 项目概述为什么SDP是流媒体的“节目单”如果你接触过WebRTC、RTSP或者任何需要实时传输音视频的场景那么SDPSession Description Protocol会话描述协议这个名字你一定不陌生。它就像一个“节目单”或者“菜单”本身不负责端到端的音视频数据运输但它精确地描述了这场“媒体盛宴”里有什么菜媒体类型、用什么盘子装编码格式、送到哪张桌子网络地址以及怎么吃传输协议。没有这份清晰、标准的“菜单”发送端和接收端就无法就“吃什么”和“怎么吃”达成一致流媒体会话也就无从建立。在流媒体技术栈里SDP扮演着信令层的关键角色。它通常通过SIP、RTSP、HTTP或WebRTC的信令通道如SDP Offer/Answer模型在会话参与者之间交换。这份纯文本的协议描述包含了媒体流的全部元数据比如一个视频会议中A端告诉B端“我这边有一个H.264编码的视频流分辨率是1280x720帧率30通过UDP端口5000发送还有一个Opus编码的音频流采样率48kHz通过同一个端口的另一个通道发送。” B端收到后可以回复“好的视频流我可以用H.264解码但我希望用VP8音频Opus没问题我将在UDP端口6000接收。” 这个过程就是SDP协商的核心。理解SDP是理解现代实时通信和流媒体系统如何“握手”和“协商”的基础。无论是搭建一个简单的点对点视频通话还是调试复杂的多路流媒体服务器比如网络热词中提到的zlmediakit的丢包问题亦或是实现一个自定义的流媒体协议栈SDP都是你必须跨越的一道坎。它看似简单只是一堆文本行但其字段的含义、协商的规则却直接决定了媒体会话的成败和质量。2. SDP协议核心结构与字段全解析一份标准的SDP描述由一系列“类型值”的文本行组成每行以回车换行结束。这些行可以分为两个主要部分会话级描述和媒体级描述。2.1 会话级描述全局设定会话级描述定义了整个会话的全局属性对所有媒体流都有效。它必须从v版本行开始。v(版本)永远是v0表示SDP的版本号为0。这个字段自协议诞生以来从未改变。o(所有者/创建者和会话标识)这是SDP的“身份证”格式为ousername sess-id sess-version nettype addrtype unicast-address。例如oalice 2890844526 2890842807 IN IP4 192.168.1.100。其中sess-id和sess-version通常是NTP时间戳用于唯一标识会话及其版本。在网络地址转换NAT环境下这里的IP地址可能是一个内网地址这就引出了后续的“c”行问题。s(会话名称)一个简短的文本描述如sMy Video Call。不能为空如果没有实际名称可以设为s-。c(连接信息)提供默认的网络连接信息格式为cnettype addrtype connection-address。例如cIN IP4 0.0.0.0。这是一个极易出错的字段。在Offer/Answer模型中c行通常包含一个候选的IP地址。很多实现中如果后续每个媒体描述m都包含了自己的c行会话级的c可以被忽略或设为0.0.0.0。但在一些严格的解析器中缺失或无效的会话级c行可能导致SDP解析失败。t(时间描述)定义会话活动的时间格式为tstart-time stop-time。对于持久或即时的会话如电话通常设为t0 0。a(属性行)这是SDP最灵活和强大的部分用于扩展会话级属性。例如agroup:BUNDLE 0 1 表示将多个媒体流捆绑Bundle在一起使用同一个传输通道如同一个UDP端口这是WebRTC中用于减少端口使用和简化NAT穿透的关键属性。aice-ufrag:8hhy ICE交互式连接建立过程的用户名片段用于STUN绑定请求的认证。aice-pwd:asd88fgpdd777uzjYhagZg ICE密码。afingerprint:sha-256 ... DTLS-SRTP的证书指纹用于媒体加密的信令。2.2 媒体级描述每个流的细节一个m行标志着一个媒体级描述的开始后面跟着的若干行主要是a行都属于这个媒体流直到下一个m行或SDP结束。m(媒体名称和传输地址)格式为mmedia port proto fmt ...。media 媒体类型如audio,video,application用于数据通道。port 传输端口。这里有个重要细节端口号后面有时会跟一个“/”和一个数字如mvideo 9/2 UDP/TLS/RTP/SAVPF 96 97 98。这里的/2表示该端口上期望接收的组件Component数量在RTP/RTCP中通常是2一个RTP一个RTCP。但在WebRTC的Bundle模式下通常只使用一个组件。proto 传输协议。早期是RTP/AVP现在常见的有UDP/TLS/RTP/SAVPF用于SRTP over DTLS且支持反馈机制。fmt 媒体格式列表。对于音频视频这通常是RTP负载类型Payload Type的数字如96。这个数字具体代表什么编码需要在后面的artpmap属性中定义。媒体级c(连接信息)格式与会话级相同。如果媒体流使用不同于会话级的网络地址或地址类型必须在此指定。如果省略则继承会话级的c。媒体级a(属性行)定义了该媒体流的具体参数。artpmap:payload type encoding name/clock rate [/encoding parameters] 将负载类型映射到具体的编解码器。例如artpmap:96 VP8/90000表示负载类型96是VP8编码的视频时钟频率为90000Hz。对于音频artpmap:111 opus/48000/2表示Opus编码48kHz采样双声道。afmtp:payload type format specific parameters 提供编解码器的具体参数。例如afmtp:96 profile-level-id42e01f;packetization-mode1用于H.264。asendrecv / asendonly / arecvonly / ainactive 媒体方向属性。这是协商的关键决定了本端是发送、接收、双向还是 inactive。assrc:SSRC cname:value 同步源SSRC及其CNAME标识符用于在RTP流中识别同步源。amid:identifier 媒体流标识符与agroup属性配合使用用于标识捆绑或同步的媒体流。acandidate: ICE候选地址这是实现NAT穿透的核心。它包含了本端收集到的所有可能用于通信的地址主机候选、服务器反射候选、中继候选。注意SDP中的端口和地址尤其是在c和m行中在信令交换时往往不是最终通信的地址。它们只是“意向地址”。真正的连接建立依赖于ICE框架通过交换acandidate行在多个候选地址对中进行连通性检查最终选择最优路径。这也是为什么在调试流媒体问题时不能只看SDP里的IP和端口就断定连接有问题。3. SDP Offer/Answer模型会话如何协商建立SDP本身是静态的描述而Offer/Answer模型赋予了它动态协商的能力。这是WebRTC、SIP等协议中建立会话的标准方式。整个过程就像一个“讨价还价”的过程。3.1 协商流程详解生成Offer发起方Offerer根据自身的能力支持的编解码器、本地网络接口等生成一个SDP描述称为Offer。这个Offer描述了它希望建立的会话包括它能够发送和愿意接收的所有媒体流和格式。此时媒体方向属性如asendrecv是从Offerer视角出发的。发送Offer通过信令通道如WebSocket、SIP消息将Offer SDP发送给接收方Answerer。生成AnswerAnswerer收到Offer后需要根据自身的能力和配置生成一个Answer SDP。这个过程不是简单的回复“收到”而是一个匹配和选择的过程Answerer会遍历Offer中的每一个媒体描述m行。对于每个媒体流Answerer从Offer支持的格式列表m行中的fmt列表中按顺序选择第一个自己同样支持的格式。这就是编解码器协商的“优先级”逻辑——Offer中格式的顺序代表了Offerer的偏好。Answerer根据自身的意愿设置媒体方向。例如如果Offer是asendrecv但Answerer只想接收它会在Answer中将该媒体方向改为arecvonly。Answerer生成自己的ICE候选acandidate并放入Answer。最终Answer SDP描述了双方交集后的会话状态双方都支持的编解码器、协商后的媒体方向、以及Answerer的网络信息。交换Answer及后续ICE交互Answerer将Answer发送回Offerer。至此双方交换了基本的会话描述和网络候选地址。随后双方启动ICE过程进行STUN绑定请求/响应以检查候选地址对的连通性最终建立媒体传输通道。3.2 关键协商规则与实战陷阱格式fmt顺序即优先级在m行中fmt列表的顺序至关重要。例如mvideo 9 UDP/TLS/RTP/SAVPF 100 101 102其中artpmap:100 VP8/90000,artpmap:101 H264/90000,artpmap:102 VP9/90000。这表示Offerer最偏好VP8其次是H.264最后是VP9。Answerer如果支持VP8和H.264它必须在Answer中保留100 101的顺序即使它内部更偏好H.264。乱序可能导致协商失败。方向协商媒体方向是独立协商的。一个sendrecv的Offer可以被一个recvonly的Answer回应结果就是Offerer只发送Answerer只接收。如果Answerer回复inactive则该媒体流被暂停。ICE与c/m行地址在Offer/Answer中m行的端口和c行的IP地址通常只是“占位符”。在WebRTC中它们可能被设置为某个默认值如端口9。真正的连接地址完全由acandidate行决定。很多新手在抓包看到SDP里是内网IP或端口9就认为配置错误其实不然。Bundle策略现代WebRTC强烈推荐使用BUNDLE。它通过agroup:BUNDLE属性将多个媒体流音频、视频、数据绑定到同一个传输5元组协议/本地IP/本地端口/远程IP/远程端口上。这极大地减少了端口使用提高了NAT穿透成功率并简化了防火墙配置。在Answer中必须对BUNDLE组进行确认。4. 从理论到实践解析一个真实的WebRTC SDP案例让我们拆解一个简化但真实的WebRTC Offer SDP将上述理论对应到实际文本中。v0 o- 7017624586836067756 2 IN IP4 127.0.0.1 s- t0 0 agroup:BUNDLE 0 1 amsid-semantic: WMS maudio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 105 13 110 113 126 cIN IP4 0.0.0.0 artcp:9 IN IP4 0.0.0.0 aice-ufrag:7sF7 aice-pwd:y4ts7rQlqgEIGQlK81xAJm4o aice-options:trickle afingerprint:sha-256 A1:B2:C3:... asetup:actpass amid:0 aextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level asendrecv artpmap:111 opus/48000/2 afmtp:111 minptime10;useinbandfec1 artpmap:103 ISAC/16000 artpmap:9 G722/8000 ... (其他rtpmap) assrc:1234567890 cname:abc123 assrc:1234567890 msid:user123 audio-track amsid:user123 audio-track acandidate:foundation 1 udp 2130706431 192.168.1.100 50005 typ host acandidate:foundation 2 udp 2130706431 192.168.1.100 50005 typ host acandidate:foundation 1 udp 1694498815 公网IP 55000 typ srflx raddr 192.168.1.100 rport 50005 mvideo 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 cIN IP4 0.0.0.0 artcp:9 IN IP4 0.0.0.0 aice-ufrag:7sF7 aice-pwd:y4ts7rQlqgEIGQlK81xAJm4o aice-options:trickle afingerprint:sha-256 A1:B2:C3:... asetup:actpass amid:1 aextmap:14 urn:ietf:params:rtp-hdrext:toffset asendrecv artpmap:96 VP8/90000 artpmap:97 rtx/90000 afmtp:97 apt96 artpmap:98 VP9/90000 ... assrc-group:FID 2222222222 3333333333 assrc:2222222222 cname:abc123 assrc:2222222222 msid:user123 video-track amsid:user123 video-track acandidate:... (与音频流共享的候选因为BUNDLE)逐段解析会话级o行包含了会话ID和版本。agroup:BUNDLE 0 1是关键它声明将mid为0和1的媒体流捆绑。音频流 (mid:0):m行显示它是音频使用端口9占位符协议是UDP/TLS/RTP/SAVPF支持反馈的加密RTP。它支持一堆编码111 Opus, 103 ISAC...。aice-ufrag/pwd和afingerprint用于ICE和DTLS安全连接。asetup:actpass表示本端可以主动发起或被动接受DTLS握手。asendrecv表示本端希望双向通信。最后列出了多个acandidate包括主机候选typ host内网地址和服务器反射候选typ srflx通过STUN服务器获取的公网地址。视频流 (mid:1):结构与音频流类似。注意artpmap:97 rtx/90000和afmtp:97 apt96这表示负载类型97是重传包RTX它关联到主视频流96VP8。assrc-group:FID表示两个SSRC2222222222和3333333333是主流和重传流的关系。关键点音频和视频的ice-ufrag,ice-pwd,fingerprint以及大部分candidate是相同的。这正是BUNDLE在起作用的表现——它们共享同一个ICE上下文和传输通道。这意味着音频和视频的RTP/RTCP包将通过同一个UDP端口如第一个主机候选的50005端口收发由不同的SSRC来区分是音频还是视频。这个SDP Offer被发送给对端后对端会生成一个Answer。Answer中对端会从每个m行的格式列表中选择它支持的第一个编码例如如果对端支持Opus(111)和G722(9)它会选择111因为111在列表中排在9前面并携带自己的ICE候选。双方交换完毕后ICE开始工作尝试用这些候选地址建立连接。5. 流媒体服务器中的SDP实战与问题排查理解了SDP的基础我们就能更好地应对流媒体开发运维中的实际问题。以网络热词中提到的zlmediakit为例它是一个高性能的C流媒体服务器支持RTSP、RTMP、HLS等多种协议。SDP在其中的RTSP协议中扮演核心角色。5.1 RTSP中的SDP交互RTSP使用SDP来描述媒体会话。一个典型的DESCRIBE响应中包含了SDP。RTSP/1.0 200 OK CSeq: 2 Content-Type: application/sdp Content-Length: ... v0 o- 0 0 IN IP4 192.168.1.200 sNo Title cIN IP4 0.0.0.0 t0 0 acontrol:* mvideo 0 RTP/AVP 96 artpmap:96 H264/90000 afmtp:96 packetization-mode1; sprop-parameter-setsZ0LAH52oFAFum4CAVGQo,aM4xig acontrol:track0 maudio 0 RTP/AVP 97 artpmap:97 MPEG4-GENERIC/48000/2 afmtp:97 profile-level-id1; modeAAC-hbr; sizelength13; indexlength3; indexdeltalength3; config1190 acontrol:track1与WebRTC SDP的差异协议使用RTP/AVP不加密的RTP而非UDP/TLS/RTP/SAVPF。端口m行中端口为0表示在后续的SETUP阶段由服务器动态分配。c行IP也可能是0.0.0.0。控制URLacontrol:track0属性非常重要它给出了控制该媒体流如播放、暂停的RTSP URL子路径。客户端在SETUP请求中会使用它例如SETUP rtsp://server/media.mp4/track0 RTSP/1.0。参数集对于H.264sprop-parameter-sets包含了SPS和PPS对于解码器初始化至关重要。5.2 常见问题排查思路结合热词“流媒体服务器zlmediakit丢包怎么解决”SDP虽然不直接导致丢包但它是排查链路问题的起点。SDP协商不匹配导致无流现象客户端播放失败服务器日志显示SETUP或PLAY后无数据发送。排查检查客户端DESCRIBE获取的SDP中的编码格式如H.264是否与客户端自身支持的解码器匹配。检查acontrolURL是否正确拼接到了后续的SETUP请求中。使用Wireshark抓取RTSP信令交互包对比SDP内容。网络地址问题导致连接失败现象在复杂网络如Docker容器、跨网段中客户端无法收到流。排查SDP中的c行或m行地址可能是0.0.0.0或服务器的内网IP。在SETUP交互中客户端会告知服务器它希望数据发往的地址和端口通过Transport:头。确保服务器能正确地将RTP包发送到客户端指定的地址/端口。在Docker部署时如热词“使用docker部署zlmediakit”需要特别注意端口映射和网络模式host/bridge。如果服务器SDP中包含了错误的IP可能需要配置服务器的网卡绑定IP或使用-s参数指定对外IP。丢包、卡顿问题排查现象视频花屏、卡顿、音频断续。SDP相关点SDP本身不解决丢包但描述了传输协议。如果是RTP/AVP那就是不加密的UDP传输易丢包。可以尝试启用重传/抗丢包编码查看SDP是否支持重传格式如前面例子中的rtx或抗丢包音频编码如Opus的useinbandfec1。zlmediakit可能需要对特定编码进行配置才能生成包含这些属性的SDP。切换TCP传输在RTSP中可以在SETUP时请求TCP传输Transport: RTP/AVP/TCP;interleaved0-1。这会将RTP/RTCP数据通过RTSP TCP连接传输避免UDP丢包但会增加延迟。这需要服务器SDP和实现支持。根本排查丢包更多是网络问题。使用工具如tcpdump在服务器端抓包或通过客户端、中间网络设备抓包分析RTP序列号是否连续计算丢包率。检查服务器性能CPU、内存、网络带宽是否充足。对于公网传输考虑使用CDN技术网络热词之一或专用传输线路来保障质量。部署与配置问题Docker部署关闭Swagger热词提到“使用docker部署zlmediakit流媒体的时候关闭swagger”。zlmediakit的Web API包括Swagger UI默认可能开启。在生产环境为了安全和减少资源占用可能需要关闭。这通常通过环境变量如Dockerfile中ENV或运行参数实现。虽然这与SDP无直接关系但属于服务器配置的一部分。关闭后确保必要的API端口如RTSP的554HTTP API的端口仍可访问。协议栈实现热词“c/c流媒体协议栈实现”提示了底层实现的重要性。一个健壮的SDP解析器/生成器是协议栈的基础。需要严格遵循RFC规范正确处理各种边界情况如属性行续行、字符编码等否则可能与某些“不标准”的客户端互操作失败。理解SDP就像拿到了流媒体系统的蓝图。它能帮助你在设计、开发、调试和运维中精准定位问题是出在“菜单”信令/SDP不对还是“送餐”网络传输的路上出了问题。当你再看到一堆看似晦涩的文本行时你就能清晰地解读出其中蕴含的媒体会话的全部秘密。