SDP协议理解

目录

• SDP协议
• 协议格式说明
• 协议格式
• 常见属性
• 协议版本号 v= -- Protocol Version
• 会话发起者: o= -- Origin
• 会话名 s=
• 连接数据：c=
• 媒体描述：m=
• 附加属性：a=
• 时间：t=
• WebRTC实例
  • 后记
• 附件 常见负载类型

SDP协议

SDP（Session Description Protocol）是一种通用的会话描述协议，主要用来描述多媒体会话，用途包括会话声明、会话邀请、会话初始化等。

WebRTC主要在连接建立阶段用到SDP，连接双方通过信令服务交换会话信息，包括音视频编解码器(codec)、主机候选地址、网络传输协议等。

下面先简单介绍下SDP的格式、常用属性，然后通过WebRTC连接建立过程生成的SDP实例进行进一步讲解。

|Field| Type | Opt/Mind| Description|

Session description

v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions

Time description

t= (time the session is active)
r=* (zero or more repeat times)

Media description, if present

m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)

协议格式说明

协议格式

<type>=<value>

• <type>：大小写敏感的一个字符，代表特定的属性，比如v代表版本；
• <value>：结构化文本，格式与属性类型有关，UTF8编码；
• =两边不允许存在空格；
• *表示是可选的；

常见属性

以下面的SDP为例子:

v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

协议版本号 v= -- Protocol Version

格式如下，没有子版本号

v=0

会话发起者: o= -- Origin

格式如下，其中，username、session-id、nettype、addrtype、unicast-address 一起，唯一标识一个会话。

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

各字段含义如下：

username：发起者的用户名，不允许存在空格，如果应用不支持用户名，则为-。

sess-id：会话id，由应用自行定义，规范的建议是NTP(Network Time Protocol)时间戳。

sess-version：会话版本，用途由应用自行定义，只要会话数据发生变化时（比如编码），sess-version随着递增就行。同样的，规范的建议是NTP时间戳。

nettype：网络类型，比如IN表示Internet。

addrtype：地址类型，比如IP4、IV6

unicast-address：域名，或者IP地址。

会话名 s=

必选，有且仅有一个s=字段，且不能为空。如果实在没有有意义的会话名，可以赋一个空格，即s=。

s=<session name>

连接数据：c=

格式如下：

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

每个SDP至少需要包含一个会话级别的c=字段，或者在每个媒体描述后面各包含一个c=字段。（媒体描述后的c=会覆盖会话级别的c=）

• nettype：网络类型，比如IN，表示 Internet。
• addrtype：地址类型，比如IP4、IP6。
• connection-address：如果是广播，则为广播地址组；如果是单播，则为单播地址；

举例01：

c=IN IP4 224.2.36.42/127

举例02：

c=IN IP4 host.anywhere.com

媒体描述：m=

SDP可能同时包含多个媒体描述。格式如下：

m=<media> <port> <proto> <fmt> ...

其中：

media：媒体类型。包括 video、audio、text、application、message等。

port：传输媒体流的端口，具体含义取决于使用的网络类型（在c=中声明）和使用的协议(proto，在m=中声明)。

proto：传输协议，具体含义取决于c=中定义的地址类型，比如c=是IP4，那么这里的传输协议运行在IP4之上。比如：

UDP：传输层协议是UDP。

RTP/AVP：针对视频、音频的RTP协议，跑在UDP之上。

RTP/SAVP：针对视频、音频的SRTP协议，跑在UDP之上。

fmt：媒体格式的描述，可能有多个。根据 proto 的不同，fmt 的含义也不同。比如 proto 为 RTP/SAVP 时，fmt 表示 RTP payload 的类型。如果有多个，表示在这次会话中，多种payload类型可能会用到，且第一个为默认的payload类型。

举例，下面表示媒体类型是视频，采用SRTP传输流媒体数据，且RTP包的类型可能是122、102...119，默认是122。

m=video 9 UDP/TLS/RTP/SAVPF 122 102 100 101 124 120 123 119

对于RTP/SAVP，需要注意的是，payload type 又分两种类型：

静态类型：参考 RTP/AVP audio and video payload types。

动态类型：在a=fmtp:里进行定义。(a=为附加属性，见后面小节)

举例，下面的SDP中：

对于audio，111 是动态类型，表示opus/48000/2。

对于video，122 是动态类型，表示H264/90000。

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 126
a=rtpmap:111 opus/48000/2
m=video 9 UDP/TLS/RTP/SAVPF 122 102 100 101 124 120 123 119
a=rtpmap:122 H264/90000

附加属性：a=

作用：用于扩展SDP。

有两种作用范围：会话级别(session-level)、媒体级别（media-level）。

媒体级别：媒体描述（m=）后面可以跟任意数量的 a= 字段，对媒体描述进行扩展。

会话级别：在第一个媒体字段(media field)前，添加的a=字段是会话级别的。

有如下两种格式：

a=<attribute>
a=<attribute>:<value>

格式1举例：

a=recvonly

格式2举例：

a=rtpmap:0 PCMU/8000

时间：t=

作用：声明会话的开始、结束时间。

格式如下：

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

如果<stop-time>是0，表示会话没有结束的边界，但是需要在<start-time>之后会话才是活跃(active)的。如果<start-time>是0，表示会话是永久的。

举例：

t=0 0

WebRTC实例

下面例子来自腾讯云WebRTC服务的远端offer。

// sdp版本号为0
v=0
// o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
// 用户名为空，会话id是8100750360520823155，会话版本是2（后面如果有类似改变编码的操作，sess-version加1），地址类型为IP4，地址为127.0.0.1（这里可以忽略）
o=- 7595655801978680453 2 IN IP4 112.90.139.105
// 会话名为空
s=-
// 会话的起始时间，都为0表示没有限制
t=0 0
a=ice-lite
// 音频、视频的传输的传输采取多路复用，通过同一个RTP通道传输音频、视频，可以参考 https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-54
a=group:BUNDLE 0 1
// WMS是WebRTC Media Stram的缩写，这里给Media Stream定义了一个唯一的标识符。一个Media Stream可以有多个track（video track、audio track），这些track就是通过这个唯一标识符关联起来的，具体见下面的媒体行(m=)以及它对应的附加属性(a=ssrc:)
// 可以参考这里 http://tools.ietf.org/html/draft-ietf-mmusic-msid
a=msid-semantic: WMS 5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV
// m=<media> <port> <proto> <fmt> ...
// 本次会话有音频，端口为9（可忽略，端口9为Discard Protocol专用），采用UDP传输加密的RTP包，并使用基于SRTCP的音视频反馈机制来提升传输质量，111、103、104等是audio可能采用的编码（参见前面m=的说明）
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 126
// 音频发送者的IP4地址，WebRTC采用ICE，这里的 0.0.0.0 可直接忽略
c=IN IP4 0.0.0.0
// RTCP采用的端口、IP地址（可忽略）
a=rtcp:9 IN IP4 0.0.0.0
// ice-ufrag、ice-pwd 分别为ICE协商用到的认证信息
a=ice-ufrag:58142170598604946
a=ice-pwd:71696ad0528c4adb02bb40e1
// DTLS协商过程的指纹信息
a=fingerprint:sha-256 7F:98:08:AC:17:6A:34:DB:CF:3B:EC:93:ED:57:3F:5A:9E:1F:4A:F3:DB:D5:BF:66:EE:17:58:E0:57:EC:1B:19
// 当前客户端在DTLS协商过程中，既可以作为客户端，也可以作为服务端，具体可参考 RFC4572
a=setup:actpass
// 当前媒体行的标识符（在a=group:BUNDLE 0 1 这行里面用到，这里0表示audio）
a=mid:0
// RTP允许扩展首部，这里表示采用了RFC6464定义的针对audio的扩展首部，用来调节音量，比如在大型会议中，有多个音频流，就可以用这个来调整音频混流的策略
// 这里没有vad=1，表示不启用这个音量控制
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
// 表示既可以发送音频，也可以接收音频
a=sendrecv
// 表示启用多路复用，RTP、RTCP共用同个通道
a=rtcp-mux
// 下面几行都是对audio媒体行的补充说明（针对111），包括rtpmap、rtcp-fb、fmtp
// rtpmap：编解码器为opus，采样率是48000，2声道
a=rtpmap:111 opus/48000/2
// rtcp-fb：基于RTCP的反馈控制机制，可以参考 https://tools.ietf.org/html/rfc5124、https://webrtc.org/experiments/rtp-hdrext/transport-wide-cc-02/
a=rtcp-fb:111 transport-cc
a=rtcp-fb:111 nack
// 最小的音频打包时间
a=fmtp:111 minptime=20
// 跟前面的rtpmap类似
a=rtpmap:126 telephone-event/8000
// ssrc用来对媒体进行描述，格式为a=ssrc:<ssrc-id> <attribute>:<value>，具体可参考 RFC5576
// cname用来唯一标识媒体的数据源
a=ssrc:16864608 cname:YZcxBwerFFm6GH69
// msid后面带两个id，第一个是MediaStream的id，第二个是audio track的id（跟后面的mslabel、label对应）
a=ssrc:16864608 msid:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV 128f4fa0-81dd-4c3a-bbcd-22e71e29d178
a=ssrc:16864608 mslabel:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV
a=ssrc:16864608 label:128f4fa0-81dd-4c3a-bbcd-22e71e29d178
// 跟audio类似，不赘述
m=video 9 UDP/TLS/RTP/SAVPF 122 102 125 107 124 120 123 119
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:58142170598604946
a=ice-pwd:71696ad0528c4adb02bb40e1
a=fingerprint:sha-256 7F:98:08:AC:17:6A:34:DB:CF:3B:EC:93:ED:57:3F:5A:9E:1F:4A:F3:DB:D5:BF:66:EE:17:58:E0:57:EC:1B:19
a=setup:actpass
a=mid:1
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:122 H264/90000
a=rtcp-fb:122 ccm fir
a=rtcp-fb:122 nack
a=rtcp-fb:122 nack pli
a=rtcp-fb:122 goog-remb
a=rtcp-fb:122 transport-cc
a=fmtp:122 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:102 rtx/90000
a=fmtp:102 apt=122
a=rtpmap:125 H264/90000
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:124 H264/90000
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:123 H264/90000
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=ssrc-group:FID 33718809 50483271
a=ssrc:33718809 cname:ovaCctnHP9Asci9c
a=ssrc:33718809 msid:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV 1d7fc300-9889-4f94-9f35-c0bcc77a260d
a=ssrc:33718809 mslabel:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV
a=ssrc:33718809 label:1d7fc300-9889-4f94-9f35-c0bcc77a260d
a=ssrc:50483271 cname:ovaCctnHP9Asci9c
a=ssrc:50483271 msid:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV 1d7fc300-9889-4f94-9f35-c0bcc77a260d
a=ssrc:50483271 mslabel:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV
a=ssrc:50483271 label:1d7fc300-9889-4f94-9f35-c0bcc77a260d

后记

SDP协议格式本身很简单，难点一般在于应用层在不同场景下扩展出来的属性，以及不同扩展属性对应的含义。比如上面举的例子，扩展属性、属性值的说明分散在数十个RFC里。

• m line 里会指明传输协议，例如 UDP/TLS/RTP/SAVPF，最后的 SAVPF 还有其他几种值：AVP, SAVP, AVPF, SAVPF
  
  AVP 意为 AV profile
  • S 意为 secure
  • F 意为 feedback
• rtpmap 是描述 codec 的，但有特殊的 rtx codec，其实不是 codec，例如 rtx；
• fmtp 补充描述 codec 的参数，format parameters
  • max-fr: maximum framerate
  • profile-level-id: H.264 的 profile level id
• rtx 描述重传策略，由 rtpmap 指明，它的参数由 fmtp 描述
  • apt: associated payload type，指明所描述的 stream；
  • rtx-time: rtp 包在缓冲区保留时间；
• rtcp-fb: RTCP 反馈机制
  • offer 里面列出一些反馈机制，answer 里应移除不理解、不支持的机制，但不能修改；
  • ack rpsi/app
  • nack pli/sli/rpsi/app
  • rpsi: reference picture selection indication
  • app: app 层反馈机制
  • pli: picture loss indication，表明收流端丢失了一幅图像的一些数据，发送端可能会发送一个 I 帧（类似于 FIR），但要考虑拥塞控制
  • sli: slice loss indication
  • ccm fir: codec control message, full intra refresh
• fec 类似于 rtx，也由 rtpmap 指明，它的参数由 fmtp 指明;

附件 常见负载类型

    PT   encoding    media type  clock rate   channels
            name                    (Hz)
    ___________________________________________________
    0    PCMU        A            8,000       1
    1    reserved    A
    2    reserved    A
    3    GSM         A            8,000       1
    4    G723        A            8,000       1
    5    DVI4        A            8,000       1
    6    DVI4        A           16,000       1
    7    LPC         A            8,000       1
    8    PCMA        A            8,000       1
    9    G722        A            8,000       1
    10   L16         A           44,100       2
    11   L16         A           44,100       1
    12   QCELP       A            8,000       1
    13   CN          A            8,000       1
    14   MPA         A           90,000       (see text)
    15   G728        A            8,000       1
    16   DVI4        A           11,025       1
    17   DVI4        A           22,050       1
    18   G729        A            8,000       1
    19   reserved    A
    20   unassigned  A
    21   unassigned  A
    22   unassigned  A
    23   unassigned  A
    dyn  G726-40     A            8,000       1
    dyn  G726-32     A            8,000       1
    dyn  G726-24     A            8,000       1
    dyn  G726-16     A            8,000       1
    dyn  G729D       A            8,000       1
    dyn  G729E       A            8,000       1
    dyn  GSM-EFR     A            8,000       1
    dyn  L8          A            var.        var.
    dyn  RED         A                        (see text)
    dyn  VDVI        A            var.        1

    Table 4: Payload types (PT) for audio encodings

Schulzrinne & Casner Standards Track [Page 33]

RFC 3551 RTP A/V Profile July 2003

    PT      encoding    media type  clock rate
            name                    (Hz)
    _____________________________________________
    24      unassigned  V
    25      CelB        V           90,000
    26      JPEG        V           90,000
    27      unassigned  V
    28      nv          V           90,000
    29      unassigned  V
    30      unassigned  V
    31      H261        V           90,000
    32      MPV         V           90,000
    33      MP2T        AV          90,000
    34      H263        V           90,000
    35-71   unassigned  ?
    72-76   reserved    N/A         N/A
    77-95   unassigned  ?
    96-127  dynamic     ?
    dyn     H263-1998   V           90,000

    Table 5: Payload types (PT) for video and combined
            encodings