WebRTC 中的 SDP

关注

原创最新推荐文章于 2026-03-12 00:00:40 发布 2k 阅读 AI 写同款· GEO 优化 ›

WebRTC中的SDP ssrc不同的媒体流可以有相同的cname，表示他们属于同一个媒体流（比如，重传流的cname就和原始流的相同）。其中，Plan B是由标准SDP演化而来的，而Unified Plan是用来代替Plan B的新规格。★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。//在webrtc中，重传包和正常包ssrc是不一样的，上一行中前一个是正常rtp包的ssrc,后一个是重传包的ssrc。阅读详情

WebRTC 中的 SDP

SDP（Session Description Protocol，会话描述协议）是一个比较老的协议，发布于2006年，以<type>=<value>的格式描述会话内容。两个浏览器端的WebRTC应用在开始传输音视频数据之前，需要借助RTCPeerConnection对象建立会话。WebRTC引入SDP来描述媒体信息，用于媒体协商时决定双方是否可以进行通信。

媒体协商的主要目的如下：

描述会话名称、会话时长。
协商音视频编解码标准（如：Opus、G722、VP8）、音频采样率和通道数、音频帧时长等。
协商网络通信质量反馈和改善策略，如：采用什么拥塞控制算法、是否开启NACK、FEC等。
协商网络安全机制和相关参数，如：ICE用户名和密码，DTLS证书指纹，DTLS用户角色等。
收集网络传输Candidate，构建CandidatePair列表。
根据CandidatePair列表和用户配置的优先级规则，逐个尝试建立连接，直到首个连接建立成功。

在会话相关参数尚未协商确定之前，WebRTC是不知道如何传输音视频数据的。

SDP作为信令系统的一部分，可以说是WebRTC的灵魂。

SDP 标准规范

SDP 的组织结构

SDP由两部分构成，即会话描述和媒体描述。

在整个SDP中，只能有一个会话描述，而媒体描述可以有多个。通常SDP中包含两个媒体描述：一个音频媒体描述，一个视频媒体描述。除会话描述是对整个SDP起约束作用外，各媒体描述之间的约束互不影响。

在这里插入图片描述

SDP 内容及 type 类型

在SDP规范中，除定义了SDP的结构外，还对SDP的内容做了规定。规范中要求所有的描述都以行为单位，描述格式如下：

<type> = <value>

其中，<type>表示描述的目标，它由单个字符构成；<value>是对<type>的解释或约束。会话描述与媒体描述都有各自的<type>。

会话包含的<type>有v（protocol version，协议版本）、o（owner/creator and session identifier，会话的创建者）、s（session name，会话名）、t（time the session is active，会话时长）。
媒体包含的<type>主要是m（media，媒体）。
除了上面介绍的<type>外，还有一些<type>是公共的，这些类型既可以出现在会话中，也可以出现在媒体中，如c（connection information，网络信息）、a（attribute，属性）等。

SDP 实例

// 会话描述
v=0
o=- 3409821183230872764 2 IN IP4 127.0.0.1
...
// 媒体描述
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 …
…
a=rtpmap :111 opus /48000/2
a=rtpmap :103 ISAC /16000
a=rtpmap :104 ISAC /32000
...

WebRTC 中的 SDP 整体结构

WebRTC为了实现音视频实时通信，对标准SDP做了很大调整：WebRTC中的SDP并没有打破标准SDP的结构，它同样包括会话描述和媒体描述两大部分。所不同的是，它对媒体描述中的内容做了大幅增加以满足自身的需求。

按功能，WebRTC中SDP的媒体描述内容可划分成四大类：媒体信息、网络描述、安全描述以及服务质量。

在这里插入图片描述

会话描述

v=0

SDP的版本（Protocol version number）。当前规范版本为0。

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

会话所有者有关的参数（Owner/creator and session identifier）。

<username>：会话发起者的名称。如果不提供则用”-“表示，用户名不能包含空格；
<sess-id>：主叫方的会话标识符；
<sess-version>：会话版本号。用0标识的居多；
<nettype>：网络类型。IN表示Internet网络类型，目前仅定义该网络类型；
<addrtype>：地址类型。目前支持IPV4和IPV6两种地址类型；
<unicast-address>：会话发起者的IP地址。

s=<session name>

本次会话的标题或会话的名称（Session name）。

t=<start-time> <stop-time>

会话的起始时间和结束时间（Time session starts and stops）。

媒体信息

属于标准SDP中媒体描述的内容，也是SDP中最核心的内容。

“m=” 行中描述了媒体类型、传输类型、负载类型等。

对于每种媒体数据（video、audio），可以选择多种编解码器，其参数可以通过 “a=rtpmap” 属性做进一步解释。

网络描述

属于标准SDP中媒体描述的内容，记录传输媒体数据时使用的网络信息。

c=<nettype> <addrtype> <connection-address>

<nettype>：网络类型。IN表示Internet网络类型，目前仅定义该网络类型；
<addrtype>：地址类型。目前支持IPV4和IPV6两种地址类型；
<unicast-address>：会话发起者的IP地址。

对于 WebRTC 而言，其网络传输由另一套复杂的机制实现，所以 “c=” 属性会被忽略。

其他属性：

“a=group:BUNDLE”：指明哪些媒体数据可以复用同一个传输通道。
“a=candidate”：表示候选人的传输地址，已被废弃，但是仍然兼容。
“a=rtcp-mux”：表示RTP和RTCP是否使用同一个端口来传输。
“a=ice-options”：指明收集 ICE Candidate 的策略。默认使用 Trikle-ICE 模式（只要有可用的 Candidate 就交换，不需要等所有 Candidate 收集好了再交换）。
“a=extmap”：指明 RTP 使用的拓展头。
“a=rtcp-resize”：指明缩减 RTCP 包的大小，视用户带宽调整。

安全描述

WebRTC 自定义了一套安全机制，安全描述的内容仅用于通信双方交换一些必要的信息。

服务质量

媒体描述中的服务质量描述是由“a=rtcp-fb”属性描述的。

在媒体协商时，发起协商一方的Offer中指明WebRTC开启哪些RTCP反馈，应答一方在Answer中确认是否真正地开启对应的RTCP反馈。

媒体信息

SDP中媒体信息的具体格式：

m=<media> <port>/<number of ports> <transport> <fmt> ...

<media>：表示媒体类型，可以是audio、video等；
<port>/<number of ports>：表示该媒体使用的端口号。对于WebRTC而言，由于它不使用SDP中描述的网络信息，所以该端口号对它没任何意义。
<transport>：表示使用的传输协议，可以是UDP、TCP等。
<fmt>：表示媒体数据类型，一般为PayloadType列表，其具体含义需要使用“a=rtpmap：”属性做进一步阐述。

rtpmap 和 fmtp

在WebRTC的SDP中，“a=rtpmap”和“a=fmtp”属性随处可见。无论是音频媒体中，还是视频媒体中，都使用它们对媒体做进一步的解释。

rtpmap（rtp map），用于解释PayloadType使用的编解码器及其参数：

a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encodingparameters>]

fmtp（format parameters）用于指定媒体数据格式：

a=fmtp:<format> <format specific parameters>

实例：音频媒体信息

...
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport -cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
...

第一行是对音频媒体的描述。transport为UDP/TLS/RTP/SAVFP。
传输时底层使用UDP；在UDP之上使用了TLS协议来交换证书；证书交换好后，媒体数据由RTP进行传输（RTP运行在UDP之上），保证传输的可靠性；媒体数据（音视频数据）的安全性是由SRTP负责的，即对RTP包中的Body部分进行加密。此外，传输时还使用RTCP的feekback机制对传输信息进行实时反馈（SAVPF），以便进行拥塞控制。

a=rtpmap:111 opus /48000/2：PayloadType 值为 111 的编码器是 opus，时钟频率（采样率）为 48000，音频通道数为 2。

a=fmtp:111 minptime=10;useinbandfec=1：PayloadType 值为 111 的编码器（opus）的音频帧最小10ms一帧，使用带内FEC进行前向纠错。

实例：视频媒体信息

...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 102 121 124 119
...
a=mid:1
...
a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
...
a=rtpmap:102 H264/90000
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=102
...
a=rtpmap:124 red/90000
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=124
...

第一行是对视频媒体的描述。

a=mid:1：视频媒体的ID编号为1。

a=rtpmap:97 rtx/90000：rtx 不是编码器，而是丢包重传。

a=fmtp:97 apt=96：当使用的媒体数据类型（Payload Type）为 96 时，如果出现丢包需要重传，重传数据包的 Payload Type 为 97。

a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f：H264Level可以不一致，H264编码数据的打包模式为1（非交错包），profile-level-id由profile_idc、profile_iop、level_idc组成，每个部分占8位，具体意义可以去H264规范手册查看。

a=rtpmap:124 red/90000：red（REDundant coding，冗余编码）是一种FEC算法，用于防止丢包。

SSRC 与 CNAME

除了音频媒体信息和视频媒体信息外，媒体描述中还包括一项重要内容，就是SSRC（Synchronization Source）。SSRC是媒体源的唯一标识，每一路媒体流都有一个唯一的SSRC来标识它。

cname（canonical name）通常称为别名，可以用在域名解析中。当想为某个域名起一个别名的时候，就可以使用它。如在直播推/拉流中，想将某个云厂商的推流地址push.xxx.yun.xxx.com换成你自己的地址push.advancedu.com，就可以使用cname。cname在SDP中的作用与域名解析中的作用是一致的，就是为媒体流起了一个别名。在同一个视频媒体描述中的两个SSRC后面都跟着同样的cname，说明这两个SSRC属于同一个媒体流。

实例：

...
a=ssrc-group:FID 1531262201 2412323032
// 视频流的SSRC
a=ssrc:1531262201 cname:Hmks0+2NwywExB+s
...
// 丢包重传流的SSRC
a=ssrc:2412323032 cname:Hmks0+2NwywExB+s

PlanB 与 UnifiedPlan

目前WebRTC中的SDP包括两种规格，即PlanB和UnifiedPlan。PlanB由标准SDP演化而来，而UnifiedPlan则是代替PlanB的SDP新规格。

它们的关系：

标准SDP -> PlanB -> UnifiedPlan

在PlanB规格中，只有两个媒体描述，即音频媒体描述（m=audio……）和视频媒体描述（m=video……）。如果要传输多路视频，则它们在视频媒体描述中需要通过SSRC来区分。

在UnifiedPlan中可以有多个媒体描述，因此，对于上面多路视频的情况，将其拆成多个视频媒体描述（多行“m=video……”）即可。

安全描述：WebRTC 如何保证数据安全？

请添加图片描述

使用WebRTC实现对音视频通信产品进行防护有三个级别，分别是应用级防护、信令级防护以及数据级防护。

应用级防护：用户在使用音视频通信产品时，一般都要先进行注册，然后通过用户名/密码的方式登录到应用系统上。这一级防护称为应用级防护，但这一级防护并不属于WebRTC的范畴。
信令级防护：当用户通过第一级防护后，就可以获得WebRTC信令服务器的地址，并通过信令服务器进行媒体协商。媒体协商成功后，通信双方便可以从彼此的SDP中获取对方的用户名/密码，即ice-ufrag和ice-pwd信息。这两个信息的作用是验证用户的合法性，其完整过程如下：通信的双方彼此发送STUN Binding请求（带着ice-ufrag和ice-pwd）给对方，当对方收到请求后，会验证请求中的ice-ufrag和ice-pwd是否与自己SDP中的一致，如果一致，则说明该用户是合法的用户，否则说明它是非法用户。
数据级防护：当第二级防护通过之后，通信的双方还会使用DTLS协议彼此交换证书，证书中保存的最重要的信息就是公钥。例如ClientA向ClientB发送媒体数据，ClientA需要用ClientB的公钥对数据加密，加密后的数据再打包成SRTP发送给ClientB，接收端（ClientB）需要使用自己的私钥才能将加密的数据解密。

实例：

...
m=...
...
a=ice-ufrag:kSq+
a=ice-pwd:MRW8liIi4S8OCRlM+SftfJWF
...
a=fingerprint:sha-256 DB:43:34:45:52:D3:78:A3:92:6E:BB:FB:83:2E:7F:22:49:5B:A7:73:D4:E1:52:1C:67:7F:7F:EA:95:F1:05:50
a=setup:actpass
...

ice-ufrag表示username（用户名），ice-pwd表示password（密码），ice-ufrag和ice-pwd用于验证WebRTC客户端是否有效。

a=fingerprint用于验证加密证书的有效性。当通信双方通过DTLS协议交换证书之前，各端会先给各自的证书生成一个指纹（fingerprint），然后将指纹放到SDP中通过信令交换给对方。通过DTLS协议交换证书后，双方会对拿到的证书重新生成指纹。然后将生成的指纹与SDP中的指纹进行比较，如果两者一致，则说明证书在传输中没有被篡改，可以放心使用，否则说明证书被篡改，此时连接创建失败。

a=setup用于指明WebRTC终端使用DTLS协议交换证书时的角色。分别为active、passive以及actpass：

active表示终端的角色为客户端；
passive表示终端的角色为服务端；
actpass（active与passive组合而成）表示终端既可以是客户端又可以是服务端，最终的角色由另一端的角色确定。

一般情况下，第一个加入房间的终端默认为actpass，后来加入的终端为active。因此，通过“a=setup”的属性值，可以知道使用DTLS协议时通信双方哪个是客户端，哪个是服务端。

网络描述：RTP 拓展头

WebRTC通常使用UDP（用户数据报协议）来传输数据。在UDP之上，WebRTC使用RTP（实时传输协议）来传输音频和视频数据。RTP报文由头部（Header）和有效载荷（Payload）两部分组成。头部包含了一些元数据信息，如序列号、时间戳和负载类型等。有效载荷则是音频或视频的实际数据。

这种基于UDP的传输方式可以提供较低的延迟和更好的实时性能，适用于实时通信应用如音视频通话和实时流媒体等。

RTP报文的头部（Header）又包括常规Header和扩展Header，扩展Header保存在SDP中。如：“a=extmap”，extmap是extension map的缩写，即RTP Header扩展映射表。

"a=extmap"属性的具体格式如下：

a=extmap:<value>["/"<direction>]<URI><extensionattributes>

URI是RTP拓展头对应值的规范说明。

实例：

a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id

a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01：transport-cc拓展头的值为3，其格式和含义都记录在http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01中。

对于RTP而言，它的拓展头是以32位的整数倍增加的，即每个拓展头最小是4字节。

服务质量

媒体描述中的服务质量描述是由“a=rtcp-fb”属性描述的。在WebRTC中，rtcp-fb（rtcp feedback）有两层含义：一是指RTCP消息中专门反馈信息的一类消息；二是指SDP中使用的“a=rtcp-fb”属性，该属性可以用来设置WebRTC终端支持哪些rtcp feedback 消息，也就是本节要介绍的内容。

实例：

a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli

WebRTC有2种拥塞控制算法：Transport-CC 和 Goog-REMB，其中 Transport-CC 是 Goog-REMB 的代替。实例中可以看出：在使用 Payload Type 为 96（VP8）时，支持 Transport-CC 和 Goog-REMB 类型的 rtcp feedback 报文，说明使用 VP8 编解码器时开启了这两种拥塞控制算法。

a=rtcp-fb:96 ccm fir：ccm（code control message）和fir（full intra refersh）指明使用VP8编解码器时，支持RTCP的FIR指令（申请关键帧指令）。

a=rtcp-fb:96 nack pli：使用VP8编解码器时，支持 NACK 报文和 PLI 报文。

WebRTC 的 SDP 实例

网站 WebRTC example of Peer Connection 提供了一个一对一通信的实例，并且打印了通信双方在媒体协商时的 SDP 消息（Offer 和 Answer）。

下面是一个 SDP 实例，并对每一行给出了相应的解释：

1 // ===============================================
2 // SDP 会话描述
3 // ===============================================
4 // 版本信息
5 v=0
6 // 会话的创建者
7 o=- 8567802084787497323 2 IN IP4 127.0.0.1
8 // 会话名
9 s=-
10 // 会话时长
11 t=0 0
12 // 音视频传输采用多路复用方式， 通过同一个通道传输
13 // 这样可以减少对ICE 资源的消耗
14 a=group:BUNDLE 0 1
15 //WMS(WebRTC Media Stream)
16 // 因为上面的BUNDLE 使得音视频可以复用传输通道
17 // 所以WebRTC 定义一个媒体流来对音视频进行统一描述
18 // 媒体流中可以包含多路轨（ 音频轨、视频轨… … )
19 // 每个轨对应一个SSRC
20 a=msid -semantic: WM S 3eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt
21 // ===============================================
22 // 音视频媒体描述
23 // ===============================================
24 // 音频媒体描述
25 // 端口9 忽略， 端口设置为0 表示不传输音频
26 m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
27 // 网络描述, 忽略!WebRTC 不使用该属性
28 c=IN IP4 0.0.0.0
29 // 忽略!WebRTC 不使用该属性
30 a=rtcp:9 IN IP4 0.0.0.0
31 // 用于ICE 有效用户的验证
32 // ufrag 表示用户名( 随机值)
33 a=ice -ufrag:r8+X
34 // 密码
35 a=ice -pwd:MdLpm2pegfysJ/VMCCGtZRpF
36 // 收信candidate 方式
37 a=ice -options:trickle
38 // 证书指纹， 用于验证DTLS 证书有效性
39 a=fingerprint:sha -256 53:08:1A:66:24: C7 :45:31:0A:EA:9E:59:97: A9 :15:3A:EC :60:1F:85:85:5B:B8:EC:D4 :77:78:9A:46:09:03:2A
40 // 用于指定DTLS 用户角色
41 a=setup:actpass
42 // BUNDLE 使用， 0 表示音频
43 a=mid:0
44 // 音频传输时RTP 支持的扩展头
45 // 发送端是否音频level 扩展， 可参考RFC6464
46 a=extmap :1 urn:ietf:params:rtp -hdrext:ssrc -audio -level
47 //NTP 时间扩展头
48 a=extmap :2 http://www.webrtc.org/experiments/rtp -hdrext/abs -send -time
49 //transport -CC 的扩展头
50 a=extmap :3 http://www.ietf.org/id/draft -holmer -rmcat -transport -wide -cc -extensions -01
51 // 与RTCP 中的SDES(Source Description) 相关的扩展头
52 // 通过RTCP 的SDES 传输mid
53 a=extmap :4 urn:ietf:params:rtp -hdrext:sdes:mid
54 // 通过RTCP 的SDES 传输rtp -stream -id
55 a=extmap :5 urn:ietf:params:rtp -hdrext:sdes:rtp -stream -id
56 // 通过RTCP 的SDES 传输重传时的rtp -stream -id
57 a=extmap :6 urn:ietf:params:rtp -hdrext:sdes:repaired -rtp -stream -id
58 // 音频数据传输方向
59 // sendrecv 既可以接收音频， 又可以发送音频
60 a=sendrecv
61 // 记录音频与媒体流的关系
62 a=msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt 67eb8a85 -f7c0 -4cad -bd62 -41 cae9517041
63 //RTCP 与RTP 复用传输通道
64 a=rtcp -mux
65 //PT=111 代表音频编码器opus/ 采样率48000/ 双通道
66 a=rtpmap :111 opus /48000/2
67 // 使用Opus 时， 支持RTCP 中的Transport -CC 反馈报文
68 a=rtcp -fb:111 Transport -cc
69 // 使用Opus 时， 每个视频帧的最小间隔为10ms , 使用带内频率
70 a=fmtp :111 minptime =10; useinbandfec =1
71 //PT=103 代表音频编码器ISAC/ 采样率16000
72 a=rtpmap :103 ISAC /16000
73 //PT=104 代表音频编码器ISAC/ 采样率32000
74 a=rtpmap :104 ISAC /32000
75 //PT=9 代表音频编码器G722/ 采样率8000
76 a=rtpmap :9 G722 /8000
77 //PT=0 未压缩音频数据PCMU/ 采样率8000
78 a=rtpmap :0 P C M U/8000
79 //PT=8 未压缩音频数据PCMA/ 采样率8000
80 a=rtpmap :8 P C M A/8000
81 //PT=106 舒适噪声(Comfort Noise , CN)/ 采样率32000
82 a=rtpmap :106 CN /32000
83 //PT=106 舒适噪声/ 采样率16000
84 a=rtpmap :105 CN /16000
85 //PT=106 舒适噪声/ 采样率8000
86 a=rtpmap :13 CN /8000
87 //PT=110 SIP DTMF 电话按键/ 采样率48000
88 a=rtpmap :110 telephone -event /48000
89 //PT=112 SIP DTMF 电话按键/ 采样率32000
90 a=rtpmap :112 telephone -event /32000
91 //PT=113 SIP DTMF 电话按键/ 采样率16000
92 a=rtpmap :113 telephone -event /16000
93 //PT=116 SIP DTMF 电话按键/ 采样率8000
94 a=rtpmap :126 telephone -event /8000
95 // 源933825788 的别名
96 a=ssrc :933825788 cname:Tf3LnJwwJc0lgnxC
97 // 记录源SSRC 与音频轨和媒体流的关系
98 a=ssrc :933825788 msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt 67eb8a85 -f7c0 -4cad -bd62 -41 cae9517041
99 // 记录源SSRC :933825788 属于哪个媒体流
100 a=ssrc :933825788 mslabel :3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt
101 // 记录源SSRC :933825788 属于哪个音频轨
102 a=ssrc :933825788 label :67 eb8a85 -f7c0 -4cad -bd62 -41 cae9517041
103 // ===============================================
104 // 视频媒体描述
105 // ===============================================
106 // 视频媒体描述
107 m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107
108 109 124 119 123 108 // 网络描述, 忽略!WebRTC 不使用该属性
109 c=IN IP4 0.0.0.0
110 忽略!WebRTC 不使用该属性
111 a=rtcp:9 IN IP4 0.0.0.0
112 // 与音频一样， 用于验证用户的有效性
113 // 如果音视频复用传输通道， 只用其中一个即可
114 a=ice -ufrag:r8+X
115 a=ice -pwd:MdLpm2pegfysJ/VMCCGtZRpF
116 // 与音频一样， 设置收集Candidate 的方式
117 a=ice -options:trickle
118 // 证书指纹， 用于验证DTLS 证书有效性
119 a=fingerprint:sha -256 53:08:1A:66:24: C7 :45:31:0A:EA:9E:59:97: A9 :15:3A:EC :60:1F:85:85:5B:B8:EC:D4 :77:78:9A:46:09:03:2A
120 // 用于指定DTLS 用户角色
121 a=setup:actpass
122 // media id 1
123 a=mid:1
124 // 视频传输时RTP 支持的扩展头
125 // toffset(TransportTime Offset)
126 //RTP 包中的timestamp 与实际发送时的偏差
127 a=extmap :14 urn:ietf:params:rtp -hdrext:toffset
128 a=extmap :2 http://www.webrtc.org/experiments/rtp -hdrext/abs -send -time
129 // 视频旋转角度的扩展头
130 a=extmap :13 urn:3gpp:video -orientation
131 //Transport -CC 扩展头
132 a=extmap :3 http://www.ietf.org/id/draft -holmer -rmcat -transport -wide -cc -extensions -01
133 // 发送端控制接收端渲染视频的延时时间
134 a=extmap :12 http://www.webrtc.org/experiments/rtp -hdrext/playout -delay
135 // 指定视频的内容， 它有两种值： 未指定和屏幕共享
136 a=extmap :11 http://www.webrtc.org/experiments/rtp -hdrext/video -content -type
137 // 该扩展仅在每个视频帧最后一个包中出现
138 // 其存放6 个时间戳， 分别为：
139 //1. 编码开始时间
140 //2. 编码完成时间
141 //3. 打包完成时间
142 //4. 离开pacer 的最后一个包的时间
143 //5. 预留时间1
144 //6. 预留时间2
145 a=extmap :7 http://www.webrtc.org/experiments/rtp -hdrext/video -timing
146 a=extmap :8 http://www.webrtc.org/experiments/rtp -hdrext/color -space
147 // 携带mid 的扩展头
148 a=extmap :4 urn:ietf:params:rtp -hdrext:sdes:mid
149 // 携带rtp -stream -id 的扩展头
150 a=extmap :5 urn:ietf:params:rtp -hdrext:sdes:rtp -stream -id
151 // 重传时携带的rtp -stream -id 的扩展头
152 a=extmap :6 urn:ietf:params:rtp -hdrext:sdes:repaired -rtp -stream -id
153 // 视频数据传输方向
154 // sendrecv ， 既可以发送， 又可以接收视频数据
155 a=sendrecv
156 // media stream id
157 a=msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003
158 //RTCP 与RTP 复用端口
159 a=rtcp -mux
160 // 减少RTCP 尺寸
161 a=rtcp -rsize
162 //PT=96 代表音频编码器VP8/ 采样率为90000
163 a=rtpmap :96 VP8 /90000
164 //PT=96 支持RTCP 协议中的Goog -REMB 反馈
165 a=rtcp -fb:96 goog -remb
166 //PT=96 支持RTCP 协议中的Transport -CC 反馈
167 a=rtcp -fb:96 transport -cc
168 //PT=96 支持RTCP 协议中的fir 反馈
169 a=rtcp -fb:96 ccm fir
170 //PT=96 支持RTCP 中的nack 反馈
171 a=rtcp -fb:96 nack
172 //PT=96 支持RTCP 中的pli 反馈
173 a=rtcp -fb:96 nack pli
174 //PT=97 代表重传数据/ 采样率为90000
175 a=rtpmap :97 rtx /90000
176 //PT=97 与96 是绑定关系， 说明97 是96 的重传数据
177 a=fmtp :97 apt =96
178 //PT=98 代表音频编码器VP9/ 采样率为90000
179 a=rtpmap :98 VP9 /90000
180 //PT=98 支持RTCP 中的Goog -REMB 反馈
181 a=rtcp -fb:98 goog -remb
182 //PT=98 支持RTCP 中的Transport -CC 反馈
183 a=rtcp -fb:98 transport -cc
184 //PT=98 支持RTCP 中的fir 反馈
185 a=rtcp -fb:98 ccm fir
186 //PT=98 支持RTCP 中的nack 反馈
187 a=rtcp -fb:98 nack
188 //PT=98 支持RTCP 中的pli 反馈
189 a=rtcp -fb:98 nack pli
190 // 使用VP9 时， 视频帧的profile id 为0
191 //VP9 一共有4 种profile 1,2,3,4
192 //0 表示支持8bit 位深
193 // 和YUV4 :2:0 格式
194 a=fmtp :98 profile -id=0
195 //PT=99 代表重传数据/ 采样率90000
196 a=rtpmap :99 rtx /90000
197 //PT=99 与98 是绑定关系， 因此99 是98 的重传数据
198 a=fmtp :99 apt =98
199 //PT=100 代表音频编码器VP9/ 采样率90000
200 a=rtpmap :100 VP9 /90000
201 //PT=100 支持RTCP 中的Goog -REMB 反馈
202 a=rtcp -fb:100 goog -remb
203 //PT=100 支持RTCP 中的Transport -CC 反馈
204 a=rtcp -fb:100 transport -cc
205 //PT=100 支持RTCP 中的fir 反馈
206 a=rtcp -fb:100 ccm fir
207 //PT=100 支持RTCP 中的nack 反馈
208 a=rtcp -fb:100 nack
209 //PT=100 支持RTCP 中的pli 反馈
210 a=rtcp -fb:100 nack pli
211 // 使用VP9 时， 视频帧的profile id 为2
212 //VP9 一共有4 种profile 1,2,3,4
213 //2 表示支持10bit 、12bit 位深
214 // 和YUV4 :2:0 格式
215 a=fmtp :100 profile -id=2
216 //PT=101 代表重传数据/ 采样率为90000
217 a=rtpmap :101 rtx /90000
218 //PT=101 与100 是绑定关系， 因此101 是100 的重传数据
219 a=fmtp :101 apt =100
220 //PT=102 代表音频编码器H264/ 采样率为90000
221 a=rtpmap :102 H264 /90000
222 //PT=102 支持RTCP 中的Goog -REMB 反馈
223 a=rtcp -fb:102 goog -remb
224 //PT=102 支持RTCP 中的Transport -CC 反馈
225 a=rtcp -fb:102 transport -cc
226 //PT=102 支持RTCP 中的fir 反馈
227 a=rtcp -fb:102 ccm fir
228 //PT=102 支持RTCP 中的nack 反馈
229 a=rtcp -fb:102 nack
230 //PT=102 支持RTCP 中的pli 反馈
231 a=rtcp -fb:102 nack pli
232 a=fmtp :102 level -asymmetry -allowed =1; packetization -mode =1; profile -level -id =42001f
233 //PT=121 代表重传数据/ 采样率为90000
234 a=rtpmap :121 rtx /90000
235 //PT=121 与102 是绑定关系， 因此121 是102 的重传数据
236 a=fmtp :121 apt =102
237 //PT=127 代表音频编码器H264/ 采样率为90000
238 a=rtpmap :127 H264 /90000
239 //PT=127 支持RTCP 中的Goog -REMB 反馈
240 a=rtcp -fb:127 goog -remb
241 //PT=127 支持RTCP 中的Transport -CC 反馈
242 a=rtcp -fb:127 transport -cc
243 //PT=127 支持RTCP 中的fir 反馈
244 a=rtcp -fb:127 ccm fir
245 //PT=127 支持RTCP 中的nack 反馈
246 a=rtcp -fb:127 nack
247 //PT=127 支持RTCP 中的pli 反馈
248 a=rtcp -fb:127 nack pli
249 a=fmtp :127 level -asymmetry -allowed =1; packetization -mode =0; profile -level -id =42001f
250 //PT=120 代表重传数据/ 采样率为90000
251 a=rtpmap :120 rtx /90000
252 //PT=127 与120 是绑定关系， 因此127 是120 的重传数据
253 a=fmtp :120 apt =127
254 //PT=125 代表音频编码器H264/ 采样率为90000
255 a=rtpmap :125 H264 /90000
256 //PT=125 支持RTCP 中的Goog -REMB 反馈
257 a=rtcp -fb:125 goog -remb
258 //PT=125 支持RTCP 中的Transport -CC 反馈
259 a=rtcp -fb:125 transport -cc
260 //PT=127 支持RTCP 中的fir 反馈
261 a=rtcp -fb:125 ccm fir
262 //PT=127 支持RTCP 中的nack 反馈
263 a=rtcp -fb:125 nack
264 //PT=127 支持RTCP 中的pli 反馈
265 a=rtcp -fb:125 nack pli
266 a=fmtp :125 level -asymmetry -allowed =1; packetization -mode =1; profile -level -id=42 e01f
267 //PT=107 代表重传数据/ 采样率为90000
268 a=rtpmap :107 rtx /90000
269 //PT=107 与125 是绑定关系， 因此177 是125 的重传数据
270 a=fmtp :107 apt =125
271 //PT=108 代表音频编码器H264/ 采样率为90000
272 a=rtpmap :108 H264 /90000
273 //PT=108 支持RTCP 中的Goog -REMB 反馈
274 a=rtcp -fb:108 goog -remb
275 //PT=108 支持RTCP 中的Transport -CC 反馈
276 a=rtcp -fb:108 transport -cc
277 //PT=108 支持RTCP 中的fir 反馈
278 a=rtcp -fb:108 ccm fir
279 //PT=108 支持RTCP 中的nack 反馈
280 a=rtcp -fb:108 nack
281 //PT=108 支持RTCP 中的pli 反馈
282 a=rtcp -fb:108 nack pli
283 a=fmtp :108 level -asymmetry -allowed =1; packetization -mode =0; profile -level -id=42 e01f
284 //PT=109 代表重传数据/ 采样率为90000
285 a=rtpmap :109 rtx /90000
286 //PT=109 与108 是绑定关系， 因此109 是108 的重传数据
287 a=fmtp :109 apt =108
288 //PT=124 代表视频使用red fec 技术/ 采样率为90000
289 a=rtpmap :124 red /90000
290 //PT=119 代表重传数据/ 采样率为90000
291 a=rtpmap :119 rtx /90000
292 //PT =1119 与124 是绑定关系， 因此119 是124 的重传数据
293 a=fmtp :119 apt =124
294 //PT=123 代表视频使用ulp fec 技术/ 采样率为90000
295 a=rtpmap :123 ulpfec /90000
296 //ssrc -group 表示几个源之间的关系
297 // 其格式为a=ssrc -group:<semantics > <ssrc -id > … 参考RFC5576
298 //FID(Flow ID), 表示这几个源都是数据流
299 // 其中， 1101026881 是正常的视频流
300 // 而后面的ssrc =35931176 是前面的ssrc 的重传流
301 a=ssrc -group:FID 1101026881 35931176
302 // 源1101026881 的别名为Tf3LnJwwJc0lgnxC
303 a=ssrc :1101026881 cname:Tf3LnJwwJc0lgnxC
304 // 下面的描述行指明了源1101026881 与媒体流ID(Media Stream ID) 和轨的关系
305 // 在一个媒体流中可以有多路轨(track), 每个轨对应一个ssrc
306 a=ssrc :1101026881 msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003
307 // 下面描述行指明了源1101026881 所属的媒体流的label(Media Stream lable)
308 a=ssrc :1101026881 mslabel :3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt
309 // 下面描述行指明了源1101026881 对应的媒体轨， 同时它也是视频设备的label
310 a=ssrc :1101026881 label:f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003
311 // 源35931176 的别名为Tf3LnJwwJc0lgnxC
312 a=ssrc :35931176 cname:Tf3LnJwwJc0lgnxC
313 // 下面的信息与源1101026881 的信息相同， 不做解释
314 a=ssrc :35931176 msid:3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003
315 a=ssrc :35931176 mslabel :3 eofXQZ24BqbQPRkcL49QddC5s84gauyOuUt
316 a=ssrc :35931176 label:f5d231d9 -f0f7 -4cd2 -b2bc -424 f37dfd003

ORTC

SDP太“古老”了。本不应该在WebRTC这样“新”的项目中引入该协议，很多人对此也提出了同样的质疑，因此以微软为首的ORTC组织提出了替换SDP的解决方案。

ORTC（Object Real-Time Communication）为开发基于WebRTC的应用程序提供了非常强大的API，其底层不再使用SDP，同时也不再需要Offer/Answer机制，而是将原来SDP中的内容分别放到Sender、Receiver、Transport对象中，通过对象完成之前的工作。