其他分享
首页 > 其他分享> > WebRTC SDP详解

WebRTC SDP详解

作者：互联网

TL;NR 更详细的 WebRTC SDP 解析请参考 https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-12

0x00 前言

SDP (Session Description Protocol) 格式是一种很有历史的格式，在 20 世纪的会议系统中通常都是使用 SDP 格式的文本来交互多媒体通信双方的连接属性信息和媒体属性信息，在今天 JSON 这种对象化和可拓展的格式面前确实显得不够通用，尤其是在进行 RPC 通信时通常要将 SDP 信息解析成模块化的格式，ORTC 就是基于这个出发点创建的，但是 SDP 在传统流媒体通信设备上的通用度还是比较高，熟练的理解并分析 SDP 信息对于系统功能开发和调试都是大有裨益的。本文主要通过参考 RFC 4566 文档和 ORTC 思维模式来阐述一套系统化的分析 WebRTC 中 SDP 信息的方法。

0x01 SDP 格式规则

SDP 会话描述由一个会话级别的部分后跟零个或多个媒体级别的部分组成。会话级部分从 “v=” 行开始，持续到第一个媒体级部分。每个媒体级部分以 “m=” 行开始，并继续到下一个媒体级部分或整个会话描述的末尾。通常，会话级值是所有媒体的默认值，除非被等效的媒体级值覆盖。

一个 SDP 会话描述由若干行文本组成形式:

<type>=<value>

其中 <type> 必须是一个区分大小写的字符，<value> 是结构化文本，其格式取决于<type>。通常，<value> 是由单个空格字符或自由格式字符串分隔的多个字段，并且是区分大小写的，除非特定字段另有定义。"=" 符号的两边不能有空格。

对于比较复杂的行还会在空格等级的基础上继续拓展使用分号 ; 作为各个参数之间的分隔符，例如:

a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f

按照分级的思路可以记忆为 行等冒空分

0x02 WebRTC SDP 内容解析

WebRTC 的 SDP 内容要求相对宽松一些，只要满足 v o s t m c b a 行即可，即 Version/Owner/Session/Timing/Media/Connection/Bandwidth/Attributes，示例如下：

v=0
o=mozilla...THIS_IS_SDPARTA-82.0.3 485627351772987711 0 IN IP4 0.0.0.0
s=-
t=0 0
m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
b=AS:1000
a=sendrecv

// o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
// m=<media> <port> <proto> <fmt> ...

RTP/AVP：应用场景为视频/音频的 RTP 协议。参考 RFC 3551
RTP/SAVP：应用场景为视频/音频的 SRTP 协议。参考 RFC 3711
RTP/AVPF: 应用场景为视频/音频的 RTP 协议，支持 RTCP-based Feedback。参考 RFC 4585
RTP/SAVPF: 应用场景为视频/音频的 SRTP 协议，支持 RTCP-based Feedback。参考 RFC 5124

随着 WebRTC 的发展 SDP 衍生出两种风格: Plan B 和 Unified Plan 。这两种风格的主要区别在于一个 media 单元中是否携带多个 track 信息。早期的 WebRTC 中一次回话描述通常只包含一个 Audio 和 一个 Video，基于这种需求衍生出来的 SDP 比较简单，即一个 Session 和两个 m-line 。但随着业务复杂度的发展可能一次回话会包含多个 Audio 和 Video，早期的解决方案是在 m-line 中增加媒体信息，也就是 Plan B 的风格，但这样使 SDP 的解析增加了难度，尤其是当多个 Audio 或 Video 在 同一个 m-line 中存在属性冲突的场景下 Plan B 风格的缺点也就彰显了出来，于是又衍生出了 Unified Plan 风格的 SDP 会话描述，将每个 media 记录到独立的 m-line 当中。
上文描述了随着 WebRTC 的发展同一个回话中出现了更多的 media，下面我们要说的是随着 Simulcast 的引入，WebRTC 中每个 media 的内容也进行了拓展。传统的基于 RTP 的会议系统中一个 media 通常只包含一对 RTP stream (即媒体 RTP stream 和 重传 RTP Stream）但是当引入 Simulcast 概念后，一个 media 中便包含了多对 RTP stream，这种拓展也同时要求我们在解析 SDP 信息时要更新观念，由传统的 Session Level 和 Media Level 模式拓展为三段式，即：

- Session Level
	- Media Level
		- Track Level

WebRTC 中 answer SDP 中 m-line 不能随意增加和删除，顺序不能随意变更，需要和 Offer SDP 中保持一致，Offer SDP 的 m-line 顺序应遵循先 audio 后 video 的原则。

WebRTC 的 SDP 信息中的 a-line 承载了大多数的信息，主要包括 媒体信息 和 连接信息 :

可以方便记忆为 CHECIID

下文将基于上面的分类方式详细的描述 WebRTC 中 SDP 常见 a-line 的属性信息。

a-line 有两种组成形式:

① Codec Parameters

AttributeIllustrate
a=rtpmapa=rtpmap:108 H264/90000
a=fmtpa=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtcp-fba=rtcp-fb:108 goog-remb

② Header Extension Parameters

AttributeIllustrate
a=extmapa=extmap:14 urn:ietf:params:rtp-hdrext:toffset

③ Encoding Parameters

AttributeIllustrate
a=ssrca=ssrc:2430709021 cname:nYAodpnTebS8lziR
a=ssrc-groupa=ssrc-group:FID 2430709021 3715850271

④ RTCP Parameters

AttributeIllustrate
a=rtcpa=rtcp:51472 IN IP4 127.0.0.1
a=rtcp-muxa=rtcp-mux
a=rtcp-rsizea=rtcp-rsize

⑤ ICE Candidate

AttributeIllustrate
a=candidatea=candidate:0 1 UDP 2122252543 192.168.0.111 56774 typ host
a=end-of-candidatesa=end-of-candidates

⑥ ICE Parameters

AttributeIllustrate
a=ice-optionsa=ice-options:trickle
a=ice-litea=ice-lite
a=ice-ufraga=ice-ufrag:3e1029a1
a=ice-pwda=ice-pwd:143a54b37278247c66e93088f767c62d

⑦ DTLS Parameters

AttributeIllustrate
a=setupa=setup:actpass
a=fingerprinta=fingerprint:sha-256 9D:58:00:00:00:00:FF:FF:00:00:00:FF:FF:FF:FF:FF:FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00

⑧ Miscellaneous

AttributeIllustrate
a=sendrecv/sendonly/recvonly/inactivea=sendrecv
a=groupa=group:BUNDLE 0 1
a=mida=mid:0
a=rida=rid:1 send pt=98;max-width=1280;max-height=720
a=simulcasta=simulcast:send hi;mid;lo
a=bundle-onlya=bundle-only
a=msid-semantica=msid-semantic:WMS *

标签：00,SDP,ietf,ICE,详解,RTP,WebRTC
来源： https://blog.csdn.net/ydjjcdd/article/details/112377297