WebRTC | SDP详解

在WebRTC的SDP中，“a=rtpmap”“a=fmtp”属性随处可见。

无论是音频媒体中，还是视频媒体中，都使用它们对媒体做进一步的解释。

i. “a=rtpmap”属性 rtpmap（rtp map），用于解释PayloadType使用的编解码器及其参数。

其格式定义在RFC4566中：

ii. “a=fmtp”属性 fmtp（format parameters）用于指定媒体数据格式。

“a=fmtp”属性的格式与rtpmap一样也是定义在RFC4566的第6节中：

（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+s 1. 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完整例子

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: … 参考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对象中，通过对象完成之前的工作。