从SDP说起

        SDP的介绍可以直接看相关的文档rfc8866，里面对SDP进行了定义，并且网上也有很多优秀的文章，本文仅对一个示例进行分析，标识出个人觉得需要注意的地方。

1 会话级

1 v=0
2 o=- 1820167056246239539 2 IN IP4 127.0.0.1
3 s=-
4 t=0 0
5 a=group:BUNDLE 0 1
6 a=msid-semantic: WMS stream_id

上面是session级定义，先看一下第2行

2 o=- 1820167056246239539 2 IN IP4 127.0.0.1

根据rfc可知o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
username："-"
sess-id：1820167056246239539，注意这个值是一个64位整数，在webrtc中的生成位置为PeerConnection::Initialize中

session_id_ = rtc::ToString(rtc::CreateRandomId64() & LLONG_MAX);

sess-version：webrtc中默认值为 2 ，也是一个无符号64位整数，需要注意的是，当前会话需要重新生成offer/answer时，该值是累加（sess-id不变），其初始值

static const uint64_t kInitSessionVersion = 2;

WebRtcSessionDescriptionFactory::InternalCreateOffer（）
{
  RTC_DCHECK(session_version_ + 1 > session_version_);
  auto offer = absl::make_unique<JsepSessionDescription>(SdpType::kOffer);
  if (!offer->Initialize(desc, session_id_, rtc::ToString(session_version_++)))
 {
 }
}

第6行

6 a=msid-semantic: WMS stream_id

声明当前会话的media stream id为stream_id
rfc8830中对msid-semantic有定义和说明 https://datatracker.ietf.org/doc/html/rfc8830

2 音频（媒体级）

1 m=audio 9 UDP/TLS/RTP/SAVPF 111 110
2 c=IN IP4 0.0.0.0
3 a=rtcp:9 IN IP4 0.0.0.0
4 a=ice-ufrag:54bK
5 a=ice-pwd:lSJTP4SLRyBu02olr/WnPq8E
6 a=ice-options:trickle
7 a=fingerprint:sha-256 42:86:3D:3A:16:2D:89:50:7E:78:D0:BD:84:CA:AE:A9:34:DB:50:CE:83:A4:4E:3E:5F:52:CB:F7:B7:75:66:8C
8 a=setup:actpass
9 a=mid:0
10 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
11 a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
12 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
13 a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
14 a=sendrecv
15 a=msid:stream_id audio_label
16 a=rtcp-mux
17 a=rtpmap:111 opus/48000/2
18 a=rtcp-fb:111 transport-cc
19 a=fmtp:111 minptime=10;useinbandfec=1
20 a=rtpmap:110 telephone-event/48000
21 a=ssrc:2974587789 cname:6y/syU5zmmJ2RG79
22 a=ssrc:2974587789 msid:stream_id audio_label
23 a=ssrc:2974587789 mslabel:stream_id
24 a=ssrc:2974587789 label:audio_label

第1行
m=<mediatype> <port> <protocol> <support encoder list>
port : webrtc中没有用到这个值，默认为9，但这个值如果为0说明本端不支持这个流

第2、3行 无用

第6行

a=ice-options:trickle

代表本端的地址信息（candidate）不放到sdp里面，而是随后单独发送

第7行

7 a=fingerprint:sha-256 42:86:3D:3A:16:2D:89:50:7E:78:D0:BD:84:CA:AE:A9:34:DB:50:CE:83:A4:4E:3E:5F:52:CB:F7:B7:75:66:8C

DTLS协商时用到的指纹信息，以验证证书有没有篡改

第8行

a=setup:actpass

a=setup 主要是表示dtls的协商过程中角色的问题，谁是客户端，谁是服务器
a=setup:actpass 既可以是客户端，也可以是服务器
a=setup:active 客户端
a=setup:passive 服务器
offer中值为actpass，answer中为actlive，则带包answer端为dtls客户端，offer为服务器端
详见https://tools.ietf.org/html/rfc4145#section-4
举个例子：
网友A（男）向网友B（女）发起视频聊天，B只开启了音频
A发送offer，a=setup:actpass即我是什么角色都可以
B收到offer，生成answer，a=setup:active，即B决定自己为dtls客户端，A为服务端passive
聊天聊的很投机，A就想看看B长什么样，B感觉A还不错于是B就准备打开摄像头，添加一个videotrack，添加媒体源需要重新协商，注意，于是B又产生一个offer，a=setup:actpass（我是什么端都可以），此时A已经是passive了，所以在A这次回复中a=setup:passive

第15行

15 a=msid:stream_id audio_label

stream_id同会话级参数 

6 a=msid-semantic: WMS stream_id 

中的stream_id，
audio_label代表当前mline代表的track的id

那么第15行就代表可以用stream_id + audio_label来作为本sdp中一个track的唯一标识，即当前媒体属于stream_id这个流。

第16行 代表rtp和rtcp共用一个socket

第19行中的minptime=10，代表音频每够10ms数据打一次包

第21-24行说明了当前媒体源的ssrc及相关属性信息
第21行ssrc = 2974587789 cname为6y/syU5zmmJ2RG79
第22行，改媒体源在当前sdp的一个标识，即其属于stream_id这个流，自己的trackid为audio_label
第23行，标识当前媒体源属于哪个stream
第24行，当前媒体源的trackid是什么

3 视频（媒体级）

1 m=video 9 UDP/TLS/RTP/SAVPF 96 97 104 105 108 109 127
2 c=IN IP4 0.0.0.0
3 a=rtcp:9 IN IP4 0.0.0.0
4 a=ice-ufrag:54bK
5 a=ice-pwd:lSJTP4SLRyBu02olr/WnPq8E
6 a=ice-options:trickle
7 a=fingerprint:sha-256 42:86:3D:3A:16:2D:89:50:7E:78:D0:BD:84:CA:AE:A9:34:DB:50:CE:83:A4:4E:3E:5F:52:CB:F7:B7:75:66:8C
8 a=setup:actpass
9 a=mid:1
10 a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
11 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
12 a=extmap:4 urn:3gpp:video-orientation
13 a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
14 a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
15 a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
16 a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
17 a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
18 a=sendrecv
19 a=msid:stream_id video_label
20 a=rtcp-mux
21 a=rtcp-rsize
22 a=rtpmap:96 H264/90000
23 a=rtcp-fb:96 goog-remb
24 a=rtcp-fb:96 transport-cc
25 a=rtcp-fb:96 ccm fir
26 a=rtcp-fb:96 nack
27 a=rtcp-fb:96 nack pli
28 a=rtcp-fb:96 ulpfec
29 a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
30 a=rtpmap:97 rtx/90000
31 a=fmtp:97 apt=96

32 a=rtpmap:104 VP8/90000
33 a=rtcp-fb:104 goog-remb
34 a=rtcp-fb:104 transport-cc
35 a=rtcp-fb:104 ccm fir
36 a=rtcp-fb:104 nack
37 a=rtcp-fb:104 nack pli
38 a=rtcp-fb:104 ulpfec
39 a=rtpmap:105 rtx/90000
40 a=fmtp:105 apt=104

41 a=rtpmap:108 red/90000
42 a=rtpmap:109 rtx/90000
43 a=fmtp:109 apt=108

44 a=rtpmap:127 ulpfec/90000

45 a=ssrc-group:FID 871210930 2263451351
46 a=ssrc:871210930 cname:6y/syU5zmmJ2RG79
47 a=ssrc:871210930 msid:stream_id video_label
48 a=ssrc:871210930 mslabel:stream_id
49 a=ssrc:871210930 label:video_label
50 a=ssrc:2263451351 cname:6y/syU5zmmJ2RG79
51 a=ssrc:2263451351 msid:stream_id video_label
52 a=ssrc:2263451351 mslabel:stream_id
53 a=ssrc:2263451351 label:video_label

我们看一下45行

45 a=ssrc-group:FID 871210930 2263451351

a=ssrc-group在webrtc中用来关联一个正常rtp包和重传包，即871210930为正常rtp包2263451351为871210930的重传包。

        本文通过对一个示例进行分析，大体标识出了一些个人觉得重要和容易忽视的地方。当对sdp有了一定的认知后，再看到sdp时内心就不会有懵逼的感觉了，希望对大家有用。