WebRTC56版本SDP详细解析

http://blog.csdn.net/onlycoder_net/article/details/76702432

v=0
//sdp版本号，一直为0,rfc4566规定
o=- 7017624586836067756 2 IN IP4 127.0.0.1
// RFC 4566 o=
//username如何没有使用-代替，7017624586836067756是整个会话的编号，2代表会话版本，如果在会话
//过程中有改变编码之类的操作，重新生成sdp时,sess-id不变，sess-version加1
s=-
//会话名，没有的话使用-代替
t=0 0
//两个值分别是会话的起始时间和结束时间，这里都是0代表没有限制
a=group:BUNDLE audio video data
//需要共用一个传输通道传输的媒体，如果没有这一行，音视频，数据就会分别单独用一个udp端口来发送
a=msid-semantic: WMS h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
//WMS是WebRTC Media Stream简称，这一行定义了本客户端支持同时传输多个流，一个流可以包括多个track,
//一般定义了这个，后面a=ssrc这一行就会有msid,mslabel等属性
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
//m=audio说明本会话包含音频，9代表音频使用端口9来传输，但是在webrtc中一现在一般不使用，如果设置为0，代表不
//传输音频,UDP/TLS/RTP/SAVPF是表示用户来传输音频支持的协议，udp，tls,rtp代表使用udp来传输rtp包，并使用tls加密
//SAVPF代表使用srtcp的反馈机制来控制通信过程,后台111 103 104 9 0 8 106 105 13 126表示本会话音频支持的编码，后台几行会有详细补充说明
c=IN IP4 0.0.0.0
//这一行表示你要用来接收或者发送音频使用的IP地址，webrtc使用ice传输，不使用这个地址
a=rtcp:9 IN IP4 0.0.0.0
//用来传输rtcp地地址和端口，webrtc中不使用
a=ice-ufrag:khLS
a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
//以上两行是ice协商过程中的安全验证信息
a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17
//以上这行是dtls协商过程中需要的认证信息
a=setup:actpass
//以上这行代表本客户端在dtls协商过程中，可以做客户端也可以做服务端，参考rfc4145 rfc4572
a=mid:audio
//在前面BUNDLE这一行中用到的媒体标识
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
//上一行指出我要在rtp头部中加入音量信息，参考 rfc6464
a=sendrecv
//上一行指出我是双向通信，另外几种类型是recvonly,sendonly,inactive
a=rtcp-mux
//上一行指出rtp,rtcp包使用同一个端口来传输
//下面几行都是对m=audio这一行的媒体编码补充说明，指出了编码采用的编号，采样率，声道等
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
//以上这行说明opus编码支持使用rtcp来控制拥塞，参考https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=fmtp:111 minptime=10;useinbandfec=1
//对opus编码可选的补充说明,minptime代表最小打包时长是10ms，useinbandfec=1代表使用opus编码内置fec特性
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:18509423 cname:sTjtznXLCNH7nbRw
//cname用来标识一个数据源，ssrc当发生冲突时可能会发生变化，但是cname不会发生变化，也会出现在rtcp包中SDEC中，
//用于音视频同步
a=ssrc:18509423 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C 15598a91-caf9-4fff-a28f-3082310b2b7a
//以上这一行定义了ssrc和WebRTC中的MediaStream,AudioTrack之间的关系，msid后面第一个属性是stream-d,第二个是track-id
a=ssrc:18509423 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
a=ssrc:18509423 label:15598a91-caf9-4fff-a28f-3082310b2b7a
m=video 9 UDP/TLS/RTP/SAVPF 100 101 107 116 117 96 97 99 98
//参考上面m=audio,含义类似
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:khLS
a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17
a=setup:actpass
a=mid:video
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-hol … de-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:100 VP8/90000
a=rtcp-fb:100 ccm fir
//ccm是codec control using RTCP feedback message简称，意思是支持使用rtcp反馈机制来实现编码控制，fir是Full Intra Request
//简称，意思是接收方通知发送方发送幅完全帧过来
a=rtcp-fb:100 nack
//支持丢包重传，参考rfc4585
a=rtcp-fb:100 nack pli
//支持关键帧丢包重传,参考rfc4585
a=rtcp-fb:100 goog-remb
//支持使用rtcp包来控制发送方的码流
a=rtcp-fb:100 transport-cc
//参考上面opus
a=rtpmap:101 VP9/90000
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-fb:101 transport-cc
a=rtpmap:107 H264/90000
a=rtcp-fb:107 ccm fir
a=rtcp-fb:107 nack
a=rtcp-fb:107 nack pli
a=rtcp-fb:107 goog-remb
a=rtcp-fb:107 transport-cc
a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
//h264编码可选的附加说明
a=rtpmap:116 red/90000
//fec冗余编码，一般如果sdp中有这一行的话，rtp头部负载类型就是116，否则就是各编码原生负责类型
a=rtpmap:117 ulpfec/90000
//支持ULP FEC，参考rfc5109
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
//以上两行是VP8编码的重传包rtp类型
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=101
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=107
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=116
a=ssrc-group:FID 3463951252 1461041037
//在webrtc中，重传包和正常包ssrc是不同的，上一行中前一个是正常rtp包的ssrc,后一个是重传包的ssrc
a=ssrc:3463951252 cname:sTjtznXLCNH7nbRw
a=ssrc:3463951252 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C ead4b4e9-b650-4ed5-86f8-6f5f5806346d
a=ssrc:3463951252 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
a=ssrc:3463951252 label:ead4b4e9-b650-4ed5-86f8-6f5f5806346d
a=ssrc:1461041037 cname:sTjtznXLCNH7nbRw
a=ssrc:1461041037 msid:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C ead4b4e9-b650-4ed5-86f8-6f5f5806346d
a=ssrc:1461041037 mslabel:h1aZ20mbQB0GSsq0YxLfJmiYWE9CBfGch97C
a=ssrc:1461041037 label:ead4b4e9-b650-4ed5-86f8-6f5f5806346d
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:khLS
a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024

转一篇文章：

SDP 协议简单解析

SDP—Session Description Protocol

The Session Description Protocol, defined by RFC 2327 [1], was developed by the IETF MMUSIC working group. It is more of a description syntax than a protocol in that it does not provide a full-range media negotiation capability. The original purpose of SDP was to describe multicast sessions set up over the Internet’s multicast backbone, the MBONE. The first application of SDP was by the experimental Session Announcement Protocol (SAP) [2] used to post and retrieve announcements of MBONE sessions. SAP messages carry a SDP message body, and was the template for SIP’s use of SDP. Even though it was designed for multicast, SDP has been applied to the more general problem of describing general multimedia sessions established using SIP.

As seen in the examples of Chapter 3, SDP contains the following information about the media session:

IP Address (IPv4 address or host name);

Port number (used by UDP or TCP for transport);

Media type (audio, video, interactive whiteboard, and so forth);

Media encoding scheme (PCM A-Law, MPEG II video, and so forth).

In addition, SDP contains information about the following:

Subject of the session;

Start and stop times;

Contact information about the session.

Like SIP, SDP uses text coding. An SDP message is composed of a series of lines, called fields, whose names are abbreviated by a single lower-case letter, and are in a required order to simplify parsing. The set of mandatory SDP fields is shown in Table 2.1. The complete set is shown in Table 7.1.

Table 7.1: SDP Field List in Their Required Order
Field

Name

Mandatory/Optional

v=

Protocol version number

m

o=

Owner/creator and session identifier

m

s=

Session name

m

i=

Session information

o

u=

Uniform Resource Identifer

o

e=

Email address

o

p=

Phone number

o

c=

Connection information

m

b=

Bandwidth information

o

t=

Time session starts and stops

m

r=

Repeat times

o

z=

Time zone corrections

o

k=

Encryption key

o

a=

Attribute lines

o

m=

Media information

o

a=

Media attributes

o

SDP was not designed to be easily extensible, and parsing rules are strict. The only way to extend or add new capabilities to SDP is to define a new attribute type. However, unknown attribute types can be silently ignored. A SDP parser must not ignore an unknown field, a missing mandatory field, or an out-of-sequence line. An example SDP message containing many of the optional fields is shown here:

 v=0
 o=johnston 2890844526 2890844526 IN IP4 43.32.1.5
 s=SIP Tutorial
 i=This broadcast will cover this new IETF protocol
 u=http://www.digitalari.com/sip
 e=Alan Johnston [email protected]
 p=+1-314-555-3333 (Daytime Only)
 c=IN IP4 225.45.3.56/236
 b=CT:144
 t=2877631875 2879633673
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 m=video 23422 RTP/AVP 31
 a=rtpmap:31 H261/90000

The general form of a SDP message is:

 x=parameter1 parameter2 ... parameterN

The line begins with a single lower-case letter x. There are never any spaces between the letter and the =, and there is exactly one space between each parameter. Each field has a defined number of parameters. Each line ends with a CRLF. The individual fields will now be discussed in detail.

7.1.1 Protocol Version
The v= field contains the SDP version number. Because the current version of SDP is 0, a valid SDP message will always begin with v=0.

7.1.2 Origin
The o= field contains information about the originator of the session and session identifiers. This field is used to uniquely identify the session. The field contains:

 o=username session-id version network-type address-type
 address

The username parameter contains the originator’s login or host or - if none. The session-id parameter is a Network Time Protocol (NTP) [3] timestamp or a random number used to ensure uniqueness. The version is a numeric field that is increased for each change to the session, also recommended to be a NTP timestamp. The network-type is always IN for Internet. The address-type parameter is either IP4 or IP6 for IPv4 or IPv6 address either in dotted decimal form or a fully qualified host name.

7.1.3 Session Name and Information
The s= field contains a name for the session. It can contain any non-zero number of characters. The optional i=field contains information about the session. It can contain any number of characters.

7.1.4 URI
The optional u= field contains a uniform resource indicator (URI) with more information about the session.

7.1.5 E-Mail Address and Phone Number
The optional e= field contains an e-mail address of the host of the session. If a display name is used, the e-mail address is enclosed in <>. The optional p= field contains a phone number. The phone number should be given in globalized format, beginning with a +, then the country code, a space or −, then the local number. Either spaces or − are permitted as spacers in SDP. A comment may be present in ().

7.1.6 Connection Data
The c= field contains information about the media connection. The field contains:

 c=network-type address-type connection-address

The network-type parameter is defined as IN for the Internet. The address type is defined as IP4 for IPv4 addresses, IP6 for IPv6 addresses. The connection-address is the IP address that will be sending the media packets, which could be either multicast or unicast. If multicast, the connection-address field contains:

 connection-address=base-multicast-address/ttl/number-of-
   addresses

where ttl is the time-to-live value, and number-of-addresses indicates how many contiguous multicast addresses are included starting with the base-multicast-address.

7.1.7 Bandwidth
The optional b= field contains information about the bandwidth required. It is of the form:

 b=modifier:bandwidth-value

The modifier is either CT for conference total or AS for application specific. CT is used for multicast session to specify the total bandwidth that can be used by all participants in the session. AS is used to specify the bandwidth of a single site. The bandwidth-value parameter is the specified number of kilobytes per second.

7.1.8 Time, Repeat Times, and Time Zones
The t= field contains the start time and stop time of the session.

 t=start-time stop-time

The times are specified using NTP timestamps. For a scheduled session, a stop-time of zero indicates that the session goes on indefinitely. A start-time and stop-time of zero for a scheduled session indicates that it is permanent. The optional r= field contains information about the repeat times that can be specified in either in NTP or in days (d), hours (h), or minutes (m). The optional z= field contains information about the time zone offsets. This field is used if a reoccurring session spans a change from daylight-savings to standard time, or vice versa.

7.1.9 Encryption Keys
The optional k= field contains the encryption key to be used for the media session. The field contains:

 k=method:encryption-key

The method parameter can be clear, base64, uri, or prompt. If the method is prompt, the key will not be carried in SDP; instead, the user will be prompted as they join the encrypted session. Otherwise, the key is sent in the encryption-key parameter.

7.1.10 Media Announcements
The optional m= field contains information about the type of media session. The field contains:

 m=media port transport format-list

The media parameter is either audio, video, application, data, telephone-event, or control. The port parameter contains the port number. The transport parameter contains the transport protocol, which is either RTP/AVP or udp. (RTP/AVP stands for Real-time Transport Protocol [4] / audio video profiles [5], which is described in Section 7.3.) The format-list contains more information about the media. Usually, it contains media payload types defined in RTP audio video profiles. More than one media payload type can be listed, allowing multiple alternative codecs for the media session. For example, the following media field lists three codecs:

 m=audio 49430 RTP/AVP 0 6 8 99

One of these three codecs can be used for the audio media session. If the intention is to establish three audio channels, three separate media fields would be used. For non-RTP media, Internet media types should be listed in the format-list. For example,

 m=application 52341 udp wb

could be used to specify the application/wb media type.

7.1.11 Attributes
The optional a= field contains attributes of the preceding media session. This field can be used to extend SDP to provide more information about the media. If not fully understood by a SDP user, the attribute field can be ignored. There can be one or more attribute fields for each media payload type listed in the media field. For the RTP/AVP example in Section 7.1.10, the following three attribute fields could follow the media field:

 a=rtpmap:0 PCMU/8000
 a=rtpmap:6 DVI4/16000
 a=rtpmap:8 PCMA/8000
 a=rtpmap:99 iLBC

Other attributes are shown in Table 7.2. Full details of the use of these attributes are in the standard document [1]. The details of the iLBC (Internet Low Bit Rate) Codec are in [6].

Table 7.2: SDP Attribute Values
Attribute

Name

a=rtpmap:

RTP/AVP list

a=cat:

Category of the session

a=keywds:

Keywords of session

a=tool:

Name of tool used to create SDP

a=ptime:

Length of time in milliseconds for each packet

a=recvonly

Receive only mode

a=sendrecv

Send and receive mode

a=sendonly

Send only mode

a=orient:

Orientation for whiteboard sessions

a=type:

Type of conference

a=charset:

Character set used for subject and information fields

a=sdplang:

Language for the session description

a=lang:

Default language for the session

a=framerate:

Maximum video frame rate in frames per second

a=quality:

Suggests quality of encoding

a=fmtp:

Format transport

a=mid:

Media identification grouping

a=direction:

Direction for symmetric media

a=rtcp:

Explicit RTCP port (and address)

a=inactive

Inactive mode

7.1.12 Use of SDP in SIP
The use of SDP with SIP is given in the SDP Offer Answer RFC 3264 [7]. The default message body type in SIP is application/sdp. The calling party lists the media capabilities that they are willing to receive in SDP in either an INVITE or in an ACK. The called party lists their media capabilities in the 200 OK response to the INVITE. More generally, offers or answers may be in INVITEs, PRACKs, or UPDATEs or in reliably sent 18x or 200 responses to these methods.

Because SDP was developed with scheduled multicast sessions in mind, many of the fields have little or no meaning in the context of dynamic sessions established using SIP. In order to maintain compatibility with the SDP protocol, however, all required fields are included. A typical SIP use of SDP includes the version, origin, subject, time, connection, and one or more media and attribute fields as shown in Table 2.1. The origin, subject, and time fields are not used by SIP but are included for compatibility. In the SDP standard, the subject field is a required field and must contain at least one character, suggested to be s=− if there is no subject. The time field is usually set to t=0 0.

SIP uses the connection, media, and attribute fields to set up sessions between user agents. Because the type of media session and codec to be used are part of the connection negotiation, SIP can use SDP to specify multiple alternative media types and to selectively accept or decline those media types. When multiple media codecs are listed, the caller and called party’s media fields must be aligned—that is, there must be the same number, and they must be listed in the same order. The offer answer specification, RFC 3264 [7], recommends that an attribute containing a=rtpmap: be used for each media field [7]. A media stream is declined by setting the port number to zero for the corresponding media field in the SDP response. In the following example, the caller Tesla wants to set up an audio and video call with two possible audio codecs and a video codec in the SDP carried in the initial INVITE:

 v=0
 o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org
 s=-
 c=IN IP4 100.101.102.103
 t=0 0
 m=audio 49170 RTP/AVP 0 8
 a=rtpmap:0 PCMU/8000
 a=rtpmap:8 PCMA/8000
 m=video 49172 RTP/AVP 32
 a=rtpmap:32 MPV/90000

The codecs are referenced by the RTP/AVP profile numbers 0, 8, and 32. The called party Marconi answers the call, chooses the second codec for the first media field and declines the second media field, only wanting a PCM A-Law audio session.

 v=0
 o=Marconi 2890844526 2890844526 IN IP4 tower.radio.org
 s=-
 c=IN IP4 200.201.202.203
 t=0 0
 m=audio 60000 RTP/AVP 8
 a=rtpmap:8 PCMA/8000
 m=video 0 RTP/AVP 32

If this audio-only call is not acceptable, then Tesla would send an ACK then a BYE to cancel the call. Otherwise, the audio session would be established and RTP packets exchanged. As this example illustrates, unless the number and order of media fields is maintained, the calling party would not know for certain which media sessions were being accepted and declined by the called party.

One party in a call can temporarily place the other on hold (i.e., suspending the media packet sending). This is done by sending an INVITE with identical SDP to that of the original INVITE but with a=sendonly attribute present. The call is made active again by sending another INVITE with the a=sendrecv attribute present. (Note that older RFC 2543 compliant UAs may initiate hold using c=0.0.0.0.) For further examples of SDP use with SIP, see the SDP Offer Answer Examples document [8].

from：https://blog.csdn.net/voipmaker/article/details/6111629

1.a字段
1.1 crypto属性
a = crypto： []
1
​ a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32

标签：用于在offer/answer中选择一种crypto属性

加密套件：描述加密的标识符和身份验证算法

关键参数：method：info。目前method只有一种定义“inline”，表明秘钥就是info

会话参数：

参考自：https://tools.ietf.org/html/rfc4568#section-4

1.2 ssrc属性
a = ssrc： ：
1
​ a=ssrc:2 cname:stream_1_cname

​ a=ssrc:2 label:video_track_id_1

attribute包括：cname(唯一标识一个客户端，一个客户端只有一个cname)

​ msid

​ mslabel

​ label

​ fmtp

参考自：https://tools.ietf.org/html/rfc5576#section-4

备注：label属性，可以参考：https://www.packetizer.com/rfc/rfc4574/

1.3 ssrc-group属性
a=ssrc-group: …
1
a=ssrc-group:FEC 2 3

semantics：有FID（流识别），FEC（前向纠错），SIM（用于simulcate）。

FID：表示同一时刻只能只用一种codec，注意一个FID不要使用同一个port/ip。FID的实现场景：可以用于重传机制的实现

ssrc-id：有多个，表示一个组里面的所有ssrc

参考自：https://tools.ietf.org/html/rfc5576#section-4

备注：关于rtx的文档https://tools.ietf.org/html/rfc4588

1.4 rtpmap属性
a=rtpmap: / [/]
1
2
​ a=rtpmap:120 VP8/90000

payload type：有效载荷类型

encoding name：编码器

encoding parameters：如果是音频，可能表示的是通道数

（备注：有ulpfec和flexfec两种payload类型，参考文档为：

ulpfec：https://tools.ietf.org/html/rfc5109

flexfec：https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-05）

参考自：https://tools.ietf.org/html/rfc4566

1.5 MediaContentDirection属性
a=sendrecv
a=recvonly
a=sendonly
a=inactive
1
2
3
4
参考自：https://tools.ietf.org/html/rfc4566

1.6 ice-ufrag 和 ice-pwd属性
a=ice-ufrag:
a=ice-pwd:
1
2
​ a=ice-ufrag:ufrag_video

​ a=ice-pwd:pwd_video

ice打洞的用户名和密码

a=ice-ufrag:ufrag_video

a=ice-pwd:pwd_video

参考自：https://tools.ietf.org/html/rfc5245#section-15.4

1.7 candidate属性
a=candidate typ
1
​ a=candidate:a0+B/4 1 udp 2130706432 74.125.224.39 3457 typ relay generation 2

foundation:用来区别两个candidate是否是一样的类型，一样的base addr， 一样的 stun server

component-id：从1开始递增。RTP的必须是1，RTCP必须是2

priority：优先级，不知道怎么用

cand-type：有四种”host”, “srflx”, “prflx”, “relay”。srflx即server reflexive, prflx即peer reflexive，relay即relayed candidates。应该是四种连接方式。

rel-addr:目前的理解是stun或turn服务器地址

rel-port:

参考自：https://tools.ietf.org/html/rfc5245

1.8 rtcp属性
a=rtcp:
1
​ a=rtcp:2347 IN IP4 74.125.127.126

rtcp的属性信息

参考自：https://tools.ietf.org/id/draft-ietf-mmusic-sdp4nat-00.txt

1.9 msid-semantic属性
a=msid-semantic:
1
​ a=msid-semantic: WMS local_stream_1

WMS表示Webrtc Media Streams

local_stream_1表示msid（msid具体作用应该是和ssrc对应）

参考自：https://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-02#section-3

1.10 msid属性
a=msid:
1
​ a=msid: local_stream_1

The value of the “msid” attribute consists of an identifier and an optional “appdata” field.(msid属性由标识符和appdata组成)

This new attribute allows endpoints to associate RTP streams that are described in different media descriptions with the same MediaStreams（msid属性允许端点和RTP流连接在不同的media descriptions中使用相同的MediaStreams）

and to carry an identifier for each MediaStreamTrack in its “appdata” field（appdata放置MediaStreamTrack）

参考自：https://tools.ietf.org/html/draft-ietf-mmusic-msid-16#page-10

备注：webrtc中SdpSerialize函数第二个参数需要设置为true才可以有该属性，如果直接用jsep的toString函数，就不会有这个属性

1.11 group属性
a=group:
1
​ a=group:BUNDLE

“a=group” lines are used to group together several “m” lines that are identified by their “mid” attribute（group属性用于通过mid标识符把多个m属性连接起来）

There MAY be several “a=group” lines in a session description.The “a=group” lines of a session description can use the same or different semantics（group属性可以有多个，并且可以有相同或不同的语义）

参考自：

https://tools.ietf.org/html/rfc5888

https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-39

1.12 bundle-only属性
a=bundle-only
1
​ a=bundle-only

和group属性结合使用。表示不同的media使用同一个port

1.13 rtcp-fb属性
a=rtcp-fb:
1
​ a=rtcp-fb:96 ccm fir

参考自：https://tools.ietf.org/html/rfc4585

1.14 rtcp-rsize属性
a=rtcp-rsize
1
​ a=rtcp-rsize

参考自：https://tools.ietf.org/html/rfc5506

1.15 fingerprint属性
a=fingerprint:
1
​ a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

参考自：https://tools.ietf.org/html/rfc4572#page-7

1.16 extmap属性
a=extmap:
1
​ a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing

rtp的头部扩展。具有三个属性：

1.非对称（可以表示recvonly，sendonly）

2.可以有相互排斥的选择（answer可以选择offer提供相同id中的其中一个rtpextension，id须为4096~4351）

3.在一个会话中可以表示多个头部扩展

参考自：https://tools.ietf.org/html/rfc5285

1.17 fmtp属性
a=fmtp:
1
​ a=fmtp:97 apt=96

表示codec对应的payloadtype，以及param

参考自：https://tools.ietf.org/html/rfc4566

1.18 mid属性
a=mid:
1
​ a=mid:audio

表示media的名字，用于查找具体的media

1.19 setup属性
a=setup:
1
​ a=setup:active

表示连接中的角色，是主动连接，还是被动连接等

2 v字段
v=0

参考自：https://tools.ietf.org/html/rfc4566

3 o字段
​ o=(用户名)（会话标识）（版本）（网络类型）（地址类型）（地址）

​ o=- 18446744069414584320 18446462598732840960 IN IP4 127.0.0.1

参考自：https://tools.ietf.org/html/rfc4566

4 s字段
​ s=(会话名)

参考自：https://tools.ietf.org/html/rfc4566

5 m字段
​ m=(媒体)（端口）（传送层）（格式列表）

​ m=audio 2345 RTP/SAVPF 111 103 104

参考自：https://tools.ietf.org/html/rfc4566

6 b字段
传输速率

参考自：https://tools.ietf.org/html/rfc4566

offer/answer：
对于offer/answer，可以查看：

https://tools.ietf.org/html/rfc3264#page-8

注：

1.The answer MUST contain exactly the same number of “m=” lines as the offer（m属性的个数和offer的m属性个数要一致）

2.If the answerer has no media formats in common for a particular offered stream, the answerer MUST reject that media stream by setting the port to zero.（如果answer方没有和offer一样的media formats，那么就通过设置端口为0拒绝这个media stream）

3.answer拒绝：如果要拒绝掉一个media stream，那么就需要把拒绝的media的port设置为0，但是有一种情况要注意，就是a=bundle-only，在前面还有a=group:BUNDLE字段，表示几个media stream公用一个端口，这个时候的media可以设置port为0

CreateAnswer比较codec
1.对于audio和video，都会比较两者的name是否一致，如果payload小于等于95，也会比较id是否一致（因为小于等于95的都是静态的payload）

2.对于audio，会比较两者的clockrate，bitrate，channels必须都一致，或者其中一个为0。

3.对于video，如果是H264，则会比较profile-level-id是否一致

from: https://blog.csdn.net/myiloveuuu/article/details/78998183