WebRTC: Session Description Protocol SDP

What is SDP

SDP (Session Description Protocol) is a common session description protocol, mainly used to describe multimedia sessions, include a session uses statements, session invitation, and other session initialization.

WebRTC used mainly in the SDP connection establishment phase, both connected through a signaling information exchange session services, including audio and video codec (CODEC), the host candidate address, network transmission protocol.

The following briefly describes the SDP format, common attributes, and further explain the process of establishing SDP instance generated by WebRTC connection.

Protocol Format Description

SDP format is very simple, consisting of a plurality of rows, each row is the following format.

<type>=<value>

among them:

<type>: A case-sensitive character, on behalf of specific properties, such as vrepresentatives of version;
<value>: Structured text, the type of format attributes, the UTF8 encoding;
=Space does not permit the presence of both sides;
=*Representation is optional;

Common attributes

SDP in the following example:

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

Protocol version:`v=`

Format is as follows, note that there is no sub-version number.

v=0

Session Started by:`o`

Format, wherein, username, session-id, nettype, addrtype, unicast-address together uniquely identifies a session.

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

The fields have the following meanings:

username: username initiator, there is a space does not permit, if the application does not support user name, it was -.
sess-id: session id, self-defined by the application, specification advice is NTP (Network Time Protocol) timestamp.
sess-version: session version, the use of self-defined by an application, when (such as coding) as long as the session data changes, sess-version with increasing line. Similarly, the standard advice is to NTP timestamp.
nettype: network type, such as INrepresentation Internet.
addrtype: address type, for example IP4,IV6
unicast-address: domain name, or IP address.

Session name `s=`

Required, there is one and only one s=field, and can not be empty. If there is no meaningful session name, can be assigned a space, that is s=.

s=<session name>

Connection data: c =

Format is as follows:

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

Each SDP needs to include at least a session-level c=fields, each comprising one or in each media described later c=field. (After the media description c=would cover the session level c=)

nettype: network type, for example IN, represents the Internet.
addrtype: address type, for example IP4, IP6.
connection-address: if the broadcast is, for the broadcast address group; if unicast, compared with unicast address;

01 For example:

c=IN IP4 224.2.36.42/127

02 For example:

c=IN IP4 host.anywhere.com

Media Description:`m=`

SDP media description may also contain more. Format is as follows:

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

among them:

media: media type. Including video, audio, text, application, message and so on.
port: the port of the media stream transport, network type (in particular depending on the meaning of c=the statement) and protocol (proto, used in m=the declaration).
proto: transmission protocol, depending on the specific meaning of c=the address type defined in such c=a IP4, then the transport protocol running on top of this IP4. such as:
- UDP: transport layer protocol is UDP.
- RTP / AVP: for video, audio RTP protocol running over UDP.
- RTP / SAVP: for video, audio, SRTP protocol running over UDP.
fmt: description of media format, there may be multiple. Depending on the proto, fmt meaning is different. Proto such as RTP / SAVP time, fmt represents RTP payload type. If there are several, he said in the session, a variety of payload types may be used, and the first one is the default payload type.

For example, the following indicates the media type is video, the streaming media data transmission using SRTP and RTP packet type may be 122, 102 ... 119, 122 default.

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

For RTP / SAVP, it should be noted that, payload type is divided into two types:

Static Type: Reference the RTP / AVP Audio and Video payload types .
Dynamic type: in a=fmtp:defined in. ( a=As attached properties, see later section)

For example, the SDP following:

For audio, 111 is a dynamic type, he expressed opus/48000/2.
For video, 122 is a dynamic type, he expressed 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

Additional attributes:`a=`

Role: to extend the SDP.

There are two kinds of scope: session level (session-level), the level of media (media-level).

Level media: media description (m =) may be followed by any number of a = field, to extend the media description.
Session level: before the first field of media (media field), a = added field is the session level.

There are two formats:

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

Format Example 1:

a=recvonly

Format Example 2:

a=rtpmap:0 PCMU/8000

time:`t=`

Role: Start declare the session end time.

Format is as follows:

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

If <stop-time>zero, indicates that the session is not over the border, but in need <start-time>after the session is active (active) it is. If <start-time>is 0, indicating that the session is permanent.

For example:

t=0 0

WebRTC examples

The following example from the remote services offer WebRTC Tencent cloud.

// 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

Written on the back

SDP protocol format itself is simple, in that the application layer is generally difficult extend out properties under different scenarios, and extended attribute corresponding to different meanings. For example, the example cited above, extended attributes, indicating property values dispersed in dozens of RFC, the find, understand all spent a lot of effort.

Any errors, please point out.