SDP:Example:ChromeToAiortc

Protocol version. Fixed at 0

Indicates the Owner/Creator that generated the SDP message. In order:

1. Username: -
2. Session-ID: 4623683867849772311
3. Session Version: 2
4. Network Type: IN
5. Address Type: IP4
6. Unicast Address: 127.0.0.1

Session name: required, with one or more UTF-8 encoded characters. Here it is "-".

Timing, in order:

1. start-time: 0
2. stop-time: 0

Note that "0 0" means a fixed session. This means the session is permanent and does not expire.

Media bundle group user-defined in the SDP. The list after a=group:BUNDLE later maps 1:1 to a=mid:. In the case above, they map to

1. a=mid:0
2. a=mid:1

respectively.

See RTCConfiguration.offerExtmapAllowMixed ¹. Allows backward interoperability with systems that do not support mixing one-byte and two-byte header extensions. <- what does this even mean...

The abbreviations are as follows:

• WMS: short for WebRTC Media Stream
• msid: MediaStream ID

A session-level attribute is defined to signal the semantics associated with msid grouping. This allows msid groups with different semantics to coexist. ^{2 3}

Defines attributes and information about the media stream, in order:

1. Media type, one of audio, video, application. In the case above, video
2. Media port number. In the case above, 9
3. Protocol. In the case above, UDP/TLS/RTP/SAVPF
4. Order of RTP payload formats. In the case above, 96, 97, 98, 99 ...

During negotiation between peers, the preferred profile numbers are tried in order. For example, it checks whether the codec for 96 is mutually supported, and if not, negotiates again with 97. Multiple media lines can be declared, and each defines only the negotiation details for that media beneath it. That is, order matters. Detailed information about the formats is specified further below after a=rtpmap:.

Exposes a reachable address for the peer connection. Usually reachable addresses are tested separately from the ICE candidates, so the address on the c line is not used. <- needs verification.

Specifies the address and port for the RTCP connection. When rtcp-mux is used, it is the same port as RTP.

ICE candidate list. After a=candidate:, in order: ^{4 5}

1. Foundation, a string that identifies the candidate. Here, 1211725180
2. Component-id, a string indicating whether the candidate is an RTP or RTCP candidate. If the candidate has RTP and RTCP multiplexed together, it is reported as an RTP candidate. Either "rtp" or "rtcp". (Note: 1 is rtp, 2 is rtcp) In the case above, 1
3. Transport. Either tcp or udp. In the case above, udp (if a Transport Extension is included, it is written like udp/token)
4. If there are multiple candidates, the User Agent always prefers the Candidate with the highest or equal Priority. In the case above, 2113937151
5. Candidate address. In the case above, c030213c-b605-4f44-b8fe-32cfc6f4976c.local
6. Port number. In the case above, 53986
7. Candidate type (Candidate-Type), prefixed with the string "typ". One of "host", "srflx", "prflx", "relay". In the case above, host (see ICE for details)
8. (Optional) rel-addr: if the string "raddr" is present, the next value is the connection-address. (Together with "rport", it is a transport address related to the candidate, useful for diagnostics and other purposes. If the candidate type is "host", <rel-addr> and <rel-port> must be omitted)
9. (Optional) rel-port: if the string "rport" is present, the next value is the port.
10. (Optional) Extension attributes. Pairs of "attribute name" and "attribute value" can be added repeatedly.
    1. generation 0
    2. network-cost 999

Defines ICE attribute values. Once ICE candidates are exchanged, a process of verifying each other begins; these are used then, and protect against potential attacks unrelated to the session.

Defines the DTLS attribute value. Contains the cryptographic hash of the certificate used for DTLS-SRTP negotiation.

Defines that this is a peer that can start DTLS negotiation. Defined by RFC4145 and updated by RFC4572.

Media identifier used in the BUNDLE group.

Indicates the direction of media exchange. It can be changed to sendonly, recvonly, or inactive through the options of the createOffer and createAnswer functions used to generate the SDP.

Definition of the payload format (RTP payload formats) declared in the m= line above. In the case above, the VP8 codec with 90000 sampling.

a=fmtp: is the format parameter.