每一个SDP都是以嵌套的方式定义的, 最外层是会话层其次是媒体层, 媒体层有分为音频和视频, 音频视频里有分别有各自的属性的定义.
SDP规范
-
Key = Value
-
Key :
-
m(media A/V)
-
a(属性)
-
c(connection)
-
v(version)
-
s(session会话)
-
o(owner, 谁拥有这个session)
-
Value: 值比较多, 可以从rfc4566文档查看
其中:
-
V : 每次协商版本号都不一样, 累加(1、2、3)
-
O : owner, 如果 key为“-”表示不关系此属性, 后面的数字不使用,不必关心
-
m : media, 某一种类型的媒体数据;
-
audio : 音频媒体数据
-
9 : 端口号,但是webrtc不用此端口号,而是使用ICE进行网络传输, 但是如果这个数字为“0”,表示媒体协商没有成功.
-
UDP/TLS/RTP/SAVPF : 底层使用的UDP协议/使用TLS加密/ UDP之上使用RTP协议/支持RTCP协议 audio video protocal feedback
-
111 103 104 : payload type
-
a : 对上面m行的属性说明
-
mid : media ID = 0
-
rtpmap : 对rtp进行扩展, payload type 111 使用的opus编解码器/采样率48000/双通道
-
m : video, 参考上面audio信息即可理解
标准SDP信息中不包含的信息: ICE-FULL 和 ICE-LITE
webrtc实现了一套自己的传输控制 即ICE, 每个终端都会收集candidate, candidate又有不同的类型, 不同的类型有不同的优先级, 其中ice会对candidata的有效性进行验证, 验证过程分为ice-lite 和ice-full两种, 一端向另一端发送stun request, 另一端返回stun response, 以表明candidate是可用的.
-
a=ice-lite : 只是客户端发送request, 服务端返回response
-
a=ice-full : 双方都向对方发送request, 并且都回复对方response
-
如果每个客户端都验证的话对于服务器来说负载太重了, 所以简化了逻辑, 只是客户端发送request,服务端返回response即可.
-
如果没有a=ice-lite 属性, 即默认使用ice- full 双向验证
-
webrtc默认使用a=ice-full
plane B
在webrtc中已被UnifiedPlan替代. 每一个m行表示一个类型的多媒体信息, 例如多个音频源, 都会在一个m行下面, 会以ssrc进行区分.
UnifiedPlan
多个媒体源流分布在不同的m行下面, 更加灵活
关于以上内容的其他参考连接: blog.csdn.net/u012538729/…
