目录
一、SDP标准规范
1. SDP结构
2. SDP内容及type类型
二、WebRTC中的SDP结构
1. 媒体信息描述
（1）SDP中媒体信息格式
i. “a=rtpmap”属性
ii. “a=fmtp”属性
（2）SSRC与CNAME
（3）举个例子
（4）PlanB与UnifiedPlan
2. 网络描述
3. 安全描述
（1）应用级防护
（2）信令级防护
（3）数据级防护
（4）举个例子
a=ice-ufrag和a=ice-pwd
a=fingerprint
a=setup
4. 服务质量描述
三、SDP完整例子
四、ORTC
SDP是一个比较老的协议，发布于2006年，以<type>=<value>的格式描述会话内容。WebRTC引入SDP来描述媒体信息，用于媒体协商时决定双方是否可以进行通信。
一、SDP标准规范
1. SDP结构
SDP由两部分构成，即会话描述和媒体描述。
在整个SDP中，只能有一个会话描述，而媒体描述可以有多个。通常SDP中包含两个媒体描述：一个音频媒体描述，一个视频媒体描述。除会话描述是对整个SDP起约束作用外，各媒体描述之间的约束互不影响。
2. 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，属性）等。
//会话描述
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的媒体描述内容可划分成四大类：媒体信息、网络描述、安全描述以及服务质量描述。
1. 媒体信息描述
（1）SDP中媒体信息格式
SDP中媒体信息的具体格式：
m=<media> <port>/<numbers> <transport> <fmt> …- <media>表示媒体类型，可以是audio、video等，与音频媒体信息相比，视频媒体信息要复杂一些。
- <port>/<numbers>表示该媒体使用的端口号。对于WebRTC而言，由于它不使用SDP中描述的网络信息，所以该端口号对它没任何意义。
- <transport>表示使用的传输协议，可以是UDP、TCP等。
- <fmt>表示媒体数据类型，一般为PayloadType列表，其具体含义需要使用“a=rtpmap：”属性做进一步阐述。
在WebRTC的SDP中，“a=rtpmap”“a=fmtp”属性随处可见。无论是音频媒体中，还是视频媒体中，都使用它们对媒体做进一步的解释。
i. “a=rtpmap”属性
rtpmap（rtp map），用于解释PayloadType使用的编解码器及其参数。其格式定义在RFC4566中：
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encodingparameters>]ii. “a=fmtp”属性
fmtp（format parameters）用于指定媒体数据格式。“a=fmtp”属性的格式与rtpmap一样也是定义在RFC4566的第6节中：
a=fmtp:<format> <format specific parameters>（2）SSRC与CNAME
除了音频媒体信息和视频媒体信息外，媒体描述中还包括一项重要内容，就是SSRC（Synchronization Source）。SSRC是媒体源的唯一标识，每一路媒体流都有一个唯一的SSRC来标识它。
cname（canonical name）通常称为别名，可以用在域名解析中。当想为某个域名起一个别名的时候，就可以使用它。如在直播推/拉流中，想将某个云厂商的推流地址push.xxx.yun.xxx.com换成你自己的地址push.advancedu.com，就可以使用cname。cname在SDP中的作用与域名解析中的作用是一致的，就是为媒体流起了一个别名。在同一个视频媒体描述中的两个SSRC后面都跟着同样的cname，说明这两个SSRC属于同一个媒体流。
（3）举个例子
...
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
...
a=ssrc -group:FID 1531262201 2412323032
// 视频流的SSRC
a=ssrc :1531262201 cname:Hmks0 +2 NwywExB+s
…
// 丢包重传流的SSRC
a=ssrc :2412323032 cname:Hmks0 +2 NwywExB+s1. transport为UDP/TLS/RTP/SAVFP，表示底层使用了哪些传输协议：
传输时底层使用UDP；在UDP之上使用了DTLS协议来交换证书；证书交换好后，媒体数据由RTP进行传输（RTP运行在UDP之上），保证传输的可靠性；媒体数据（音视频数据）的安全性是由SRTP负责的，即对RTP包中的Body部分进行加密。此外，传输时还使用RTCP的feekback机制对传输信息进行实时反馈（SAVPF），以便进行拥塞控制。
2. fmtlist的值为一串从111到126的数字，每个数字代表一个PayloadType，不同的PayloadType表示媒体数据使用了不同的编解码器或编解码器参数。媒体描述还有很多细节是无法通过一条“m=”行就能够描述清楚的，必须通过“a=rtpmap”对其做进一步解释才行。
3. Payload Type值为111的编码器是Opus，其时钟频率（采样率）为48000，音频通道数为2。同理，PayloadType值为103的编码器是ISAC，采样率为16000；PayloadType值为104的编码器也是ISAC，只不过其采样率变成了32000；PayloadType值为9的编码器是G722，采样率是8000……
4. a=fmtp :111 minptime =10; useinbandfec =1：PayloadType值为111的数据（Opus数据）：以10ms长的音频数据为一帧，并且数据是经FEC（Forward Error Correction，前向纠错）编码的。其中，“usein bandfec=1”是WebRTC针对Opus增加的fmtp值。
5. ssrc-group指明两个SSRC是有关联关系的，后一个SSRC（2412323032）是前一个SSRC（1531262201）的重传流。也就是说，1531262201是真正代表视频流的SSRC，而2412323032是视频流（1531262201）丢包时使用的SSRC，这就是为什么在同一个媒体描述中会有两个SSRC。所以，虽然在同一个视频描述中有两个SSRC，但对于该视频来说，仍然只有唯一的SSRC用来标识它。
6. SSRC为1531262201的cname名字与SSRC为2412323032的cname名字是一模一样的，说明这两个SSRC属于同一个媒体流。
（4）PlanB与UnifiedPlan
目前WebRTC中的SDP包括两种规格，即PlanB和UnifiedPlan。PlanB由标准SDP演化而来，而UnifiedPlan则是代替PlanB的SDP新规格。
- 在PlanB规格中，只有两个媒体描述，即音频媒体描述（m=audio……）和视频媒体描述（m=video……）。如果要传输多路视频，则它们在视频媒体描述中需要通过SSRC来区分。
- 在UnifiedPlan中可以有多个媒体描述，因此，对于上面多路视频的情况，将其拆成多个视频媒体描述（多行“m=video……”）即可。
2. 网络描述
WebRTC通常使用UDP（用户数据报协议）来传输数据。在UDP之上，WebRTC使用RTP（实时传输协议）来传输音频和视频数据。RTP报文由头部（Header）和有效载荷（Payload）两部分组成。头部包含了一些元数据信息，如序列号、时间戳和负载类型等。有效载荷则是音频或视频的实际数据。
这种基于UDP的传输方式可以提供较低的延迟和更好的实时性能，适用于实时通信应用如音视频通话和实时流媒体等。
RTP报文的头部（Header）又包括常规Header和扩展Header，扩展Header保存在SDP中。如：“a=extmap”，extmap是extension map的缩写，即RTP Header扩展映射表。
3. 安全描述
使用WebRTC实现对音视频通信产品进行防护有三个级别，分别是应用级防护、信令级防护以及数据级防护。
（1）应用级防护
用户在使用音视频通信产品时，一般都要先进行注册，然后通过用户名/密码的方式登录到应用系统上。这一级防护称为应用级防护，但这一级防护并不属于WebRTC的范畴。
（2）信令级防护
当用户通过第一级防护后，就可以获得WebRTC信令服务器的地址，并通过信令服务器进行媒体协商。媒体协商成功后，通信双方便可以从彼此的SDP中获取对方的用户名/密码，即ice-ufrag和ice-pwd信息。这两个信息的作用是验证用户的合法性，其完整过程如下：通信的双方彼此发送STUN Binding请求（带着ice-ufrag和ice-pwd）给对方，当对方收到请求后，会验证请求中的ice-ufrag和ice-pwd是否与自己SDP中的一致，如果一致，则说明该用户是合法的用户，否则说明它是非法用户。
（3）数据级防护
当第二级防护通过之后，通信的双方还会使用DTLS协议彼此交换证书，证书中保存的最重要的信息就是公钥。例如ClientA向ClientB发送媒体数据，ClientA需要用ClientB的公钥对数据加密，加密后的数据再打包成SRTP[插图]发送给ClientB，接收端（ClientB）需要使用自己的私钥才能将加密的数据解密。
（4）举个例子
…
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
…-
a=ice-ufrag和a=ice-pwd
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协议时通信双方哪个是客户端，哪个是服务端。
4. 服务质量描述
媒体描述中的服务质量描述是由“a=rtcp-fb”属性描述的。在WebRTC中，rtcp-fb（rtcp feedback）有两层含义：一是指RTCP消息中专门反馈信息的一类消息；二是指SDP中使用的“a=rtcp-fb”属性，该属性可以用来设置WebRTC终端支持哪些rtcp feedback消息。
三、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对象中，通过对象完成之前的工作。
