SDP是基于文本，其本身并不属于传输协议，仅仅是对会话进行文本描述，SDP的协商和交换通常需要依赖其它的传输协议（比如 SIP 和 HTTP），我们先看一个典型的webrtc SDP：

SDP 会话描述包含若干行以下形式的文本：<type>=<value>；<type>是大小写敏感的单个字符，<value>一个结构化的文本字符串，其格式依赖于<type>，通常 <value> 或者是若干以单个空格分界的字段，或者是一个自由格式的字符串。

通常一个SDP主要包括以下内容：

• 会话描述；由会话级部分组成，以“v=”行开头，并继续到第一个媒体级;

• 媒体描述；媒体描述以“m=”行开始，直到下一个媒体描述或整个会话描述的结束。 

在这个webrtc SDP中，我们可以看到关于会话描写信息的细节，有会话的版本（v=），发起人和会话标识符（o=）, 会话名称(s=)，会话处于活动状态的时间说明（t=）等。值得特别指出的是会话属性行a=msid-semantic:WMS 32776，这个是webrtc提出的一个关于跨会话流标识标准草案，主要用途是用于关联不同媒体描述行中的多个rtp ssrc，在audio媒体描述的ssrc属性，可以看到a=ssrc:2878130877 msid:32776 audio-default, 使用了会话属性定义的msid 32776。

这里媒体描述仅有一条audio m Line, 通过SDP可以了解到关于audio的具体细节，如传输协议(RTP/AVPF)，媒体格式(opus/48000/2)，多播或远端（单播地址和端口（192.168.3.69:60016）, 可信赖的接洽信息（a=candidate）, ice协商过程中的安全验证信息，以及发送RTP流的SSRC等信息。

其中媒体描述中涉及到ICE 连接描述规范可以参考RFC5245;Rtcp-mux在单个端口复用RTP和RTCP可以参考RFC5761；而关于rtp扩展头extmap 标准定义，又需要参考其他相关RFC标准或者草案。

由此，我们发现SDP协议格式本身其实比较简单，由于基于文本，可读性比较强，但是由于不同的应用场景（比如传统 SIP 视频会议或者 RTC 场景）下扩展出的众多纷繁复杂的属性及其含义，这些属性散落在众多的 RFC 以及草案之中，需要很好的理解一个SDP就需要花大量时间来对标准进行研究。

• Mid ，Plan B 仅仅有一条m line,且“a=mid:audio”；Unified Plan 有两条m Line, 第一个“a=mid:0”，第二条“a=mid:1”；
• Msid，Plan B 每个不同的ssrc 都对应一个随机的 msid，例如 a=ssrc:10 msid:stream-id-1 track-id-1; Unified Plan不需要通过msid来区分流, msid 用“-”来表示；
• 媒体属性，Plan B由于在同一个m line中描述不同的流，这些流都具有相同的属性; Unified Plan 不同的流放在不同的m line 中，他们的属性可以相同也可以不同，比如 rtp 扩展头信息等；
  
• 连接端口，Plan B 的多个流都共用相同的连接信息，因此不需要为每条流都单独分配独立连接端口；Unified Plan, 虽然不同的m Line可以有不同的candidate信息，但是在实际使用场景下，大部分时候可以通过BUNDLE 来把不同的流对应到相同的连接端口上，“a=group:BUNDLE 0 1”

拍乐云打造的基于PaaS平台的音视频云服务，除了提供桌面端、移动端原生SDK和多种跨平台SDK外，也提供Web端的支持。关注我们，我们会在后续的文章中持续分享音视频、实时通信的技术知识，陪你一起成长为技术专家。