1.a field
1.1 crypto properties
a = crypto：<tag> <crypto-suite> <key-params> [<session-params>]
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
Label: Used to select a crypto attribute in offer/answer
Encryption suite: describes the encrypted identifier and authentication algorithm
Key parameters: method: info. Currently there is only one definition of method "inline", indicating that the secret key is info
Session parameters:
Reference from: https://tools.ietf.org/html/rfc4568#section-4
1.2 ssrc attribute
a = ssrc：<ssrc-id> <attribute>：<value>
a=ssrc:2 cname:stream_1_cname
a=ssrc:2 label:video_track_id_1
Attribute includes: cname (uniquely identify a client, a client has only one cname)
msid
mslabel
label
fmtp
Reference from: https://tools.ietf.org/html/rfc5576#section-4
Remarks: label attribute, you can refer to: https://www.packetizer.com/rfc/rfc4574/
1.3 ssrc-group attributes
a=ssrc-group:<semantics> <ssrc-id> ...
a=ssrc-group:FEC 2 3
semantics: FID (stream identification), FEC (forward error correction), SIM (for simulcate).
FID: It means that only one codec can be used at the same time. Note that one FID should not use the same port/ip. FID implementation scenario: can be used to implement the retransmission mechanism
ssrc-id: There are multiple, which means all ssrc in a group
Reference from: https://tools.ietf.org/html/rfc5576#section-4
Remarks: Documentation on rtx https://tools.ietf.org/html/rfc4588
1.4 rtpmap attributes
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
a=rtpmap:120 VP8/90000
payload type: payload type
encoding name: encoder
encoding parameters: If it is audio, it may indicate the number of channels
(Note: There are two types of payloads, ulpfec and flexfec. The reference document is:
ulpfec：https://tools.ietf.org/html/rfc5109
flexfec：https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-05）
Reference from: https://tools.ietf.org/html/rfc4566
1.5 MediaContentDirection property
a=sendrecv a = recvonly a=sendonly a=inactive
Reference from: https://tools.ietf.org/html/rfc4566
1.6 ice-ufrag and ice-pwd attributes
a=ice-ufrag:<ufrag> a=ice-pwd:<pwd>
a=ice-ufrag:ufrag_video
a=ice-pwd:pwd_video
The username and password of the ice hole
a=ice-ufrag:ufrag_video
a=ice-pwd:pwd_video
Reference from: https://tools.ietf.org/html/rfc5245#section-15.4
1.7 candidate attributes
a=candidate <foundation> <component-id> <transport> <priority> <connection-address> typ <candidate-types> <rel-addr> <rel-port>
a=candidate:a0+B/4 1 udp 2130706432 74.125.224.39 3457 typ relay generation 2
foundation: used to distinguish whether two candidates are of the same type, the same base addr, and the same stun server
component-id: start from 1 and increase. RTP must be 1, RTCP must be 2
priority: priority, I don’t know how to use it
cand-type: There are four types of "host", "srflx", "prflx", and "relay". srflx means server reflexive, prflx means peer reflexive, and relay means relayed candidates. There should be four connection methods.
rel-addr: The current understanding is the address of the stun or turn server
rel-port:
Reference from: https://tools.ietf.org/html/rfc5245
1.8 rtcp attributes
a=rtcp:<port> <nettype> <addrtype> <connection-address>
a=rtcp:2347 IN IP4 74.125.127.126
rtcp attribute information
Reference from: https://tools.ietf.org/id/draft-ietf-mmusic-sdp4nat-00.txt
1.9 msid-semantic attribute
a=msid-semantic:<msid>
a=msid-semantic: WMS local_stream_1
WMS Display Webrtc Media Streams
local_stream_1 means msid (the specific role of msid should correspond to ssrc)
Reference from: https://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-02#section-3
1.10 msid attribute
a=msid:<msid>
a=msid: local_stream_1
The value of the "msid" attribute consists of an identifier and an optional "appdata" field. (msid attribute consists of an identifier and appdata)
This new attribute allows endpoints to associate RTP streams that are described in different media descriptions with the same MediaStreams (msid attribute allows endpoints and RTP stream connections to use the same MediaStreams in different media descriptions)
and to carry an identifier for each MediaStreamTrack in its “appdata” field（appdata放置MediaStreamTrack）
Reference from: https://tools.ietf.org/html/draft-ietf-mmusic-msid-16#page-10
Note: The second parameter of the SdpSerialize function in webrtc needs to be set to true to have this attribute. If you use the toString function of jsep directly, there will be no such attribute
1.11 group attributes
a=group:<semantics> <semantics-extension>
a=group:BUNDLE
"A=group" lines are used to group together several "m" lines that are identified by their "mid" attribute (group attribute is used to connect multiple m attributes by mid identifier)
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 attributes can have multiple, and can have the same or different semantics)
Reference from:
https://tools.ietf.org/html/rfc5888
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-39
1.12 bundle-only attribute
a=bundle-only
a=bundle-only
Used in conjunction with the group attribute. Indicates that different media use the same port
1.13 rtcp-fb attributes
a=rtcp-fb:<payload> <param>
a = rtcp-fb: 96 ccm fir
Reference from: https://tools.ietf.org/html/rfc4585
1.14 rtcp-rsize attribute
a=rtcp-rsize
a=rtcp-rsize
Reference from: https://tools.ietf.org/html/rfc5506
1.15 fingerprint attribute
a=fingerprint:<hash-func> <fingerprint>
a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Reference from: https://tools.ietf.org/html/rfc4572#page-7
1.16 extmap attributes
a=extmap:<id> <uri>
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
The head extension of rtp. Has three attributes:
1. Asymmetric (recvonly, sendonly can be expressed)
2. There can be mutually exclusive options (answer can choose offer to provide one of the rtpextension with the same id, the id must be 4096~4351)
3. Multiple header extensions can be represented in a session
Reference from: https://tools.ietf.org/html/rfc5285
1.17 fmtp attributes
a=fmtp:<payload> <param>
a=fmtp:97 apt=96
Indicates the payloadtype corresponding to the codec and param
Reference from: https://tools.ietf.org/html/rfc4566
1.18 mid attribute
a=mid:<media name>
a=mid:audio
Represents the name of the media, used to find specific media
1.19 setup properties
a=setup:<role>
a=setup:active
Indicates the role in the connection, whether it is an active connection or a passive connection, etc.
2 v field
v = 0
Reference from: https://tools.ietf.org/html/rfc4566
3 o field
o=(user name) (session ID) (version) (network type) (address type) (address)
o=- 18446744069414584320 18446462598732840960 IN IP4 127.0.0.1
Reference from: https://tools.ietf.org/html/rfc4566
4 s field
s=(session name)
Reference from: https://tools.ietf.org/html/rfc4566
5 m field
m=(media) (port) (transport layer) (list of formats)
m=audio 2345 RTP/SAVPF 111 103 104
Reference from: https://tools.ietf.org/html/rfc4566
6 b field
Transmission rate
Reference from: https://tools.ietf.org/html/rfc4566
offer/answer：
For offer/answer, you can view:
https://tools.ietf.org/html/rfc3264#page-8
Note:
1. The answer MUST contain exactly the same number of "m=" lines as the offer (the number of m attributes must be the same as the number of m attributes of offer)
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. (If the answerer has no media formats as the offer, then set the port to 0 Reject this media stream)
3. Answer rejection: If you want to reject a media stream, you need to set the port of the rejected media to 0, but there is a situation to pay attention to, that is, a=bundle-only, and a=group:BUNDLE field in front , Which means that several media streams share a port. At this time, the media can be set to 0
CreateAnswer compare codec
1. For audio and video, they will compare whether the names of the two are consistent. If the payload is less than or equal to 95, it will also compare whether the id is consistent (because those less than or equal to 95 are static payloads)
2. For audio, the clockrate, bitrate, and channels of the two must be the same, or one of them is 0.
3. For video, if it is H264, it will compare whether the profile-level-id is consistent