Webrtc Intro - RTP RTCP SDP relevants

kRtcpFir - Full intra-frame Request (FIR)

RTP/SAVPF - Security, Audio, Video, Profile, Feedback

RTP-FEC - RFC 5109

RTP-NACK - RFC 4585

RFC 5109 - RTP Payload Format for Generic Forward Error Correction

RFC 5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)

(TMMBR, TMMBR) - Temporary Maximum Media Stream Bit Rate Request and Notification

RFC 4585 - Extended RTP Profile for RTCP-Based Feedback

(kRtcpPli, kRtcpSli, kRtcpRpsi, kRtcpFir)

RFC 3711 - The Secure Real-time Transport Protocol

RFC 5124 - Extended Secure RTP Profile for RTCP-Based feedback

DTLS stands for Datagram Transport Layer Security.

Simply put, DTLS is UDP + security.

DTLS provides similar security guarantees to thatTLS provides.

DTLS is used in WebRTC for secure media key exchange inDTLS-SRTP.

DTLS-SRTP is a key exchange mechanism that is mandated for use in WebRTC.

DTLS-SRTP uses DTLS to exchange keys for theSRTP
media transport.

SRTP requires an external key exchange mechanism for sharing its session keys, and DTLS-SRTP does that by multiplexing the DTLS-SRTP protocol within the same session as the SRTP media itself.

This method is considered to be more secure than theSDES mechanism
that was first used in WebRTC but later on banned from use altogether.

SDES stands for SDP Security Descriptions for Media Streams.

When keys needs to be exchanged for the use of
SRTP sessions this can be done in multiple ways. SDES is one of them.

With SDES, the keys to be exchanged are placed in clear-text inside the SDP. It is assumed that the SDP is then being sent on top of another secured transport such asTLS.
It is also assumed that end-to-end security is not necessary, as signaling here may traverse through an intermediary server who has access to the SDP information.

SDES has been explicitly banned from use in WebRTC.DTLS-SRTP
is to be used instead.



RFC 4585 - Extended RTP Profile for RTCP-Based Feedback

(kRtcpPli, kRtcpSli, kRtcpRpsi, kRtcpFir)

Feedback message type (FMT): 5 bits

This field identifies the type of the FB message and is

interpreted relative to the type (transport layer, payloadspecific, or application layer feedback). The values for each of

the three feedback types are defined in the respective sections

below.

6.2. Transport Layer Feedback Messages

Transport layer FB messages are identified by the value RTPFB as RTCP

message type.

A single general purpose transport layer FB message is defined in

this document: Generic NACK. It is identified by means of the FMT

parameter as follows:

0: unassigned

1: Generic NACK

2-30: unassigned

31: reserved for future expansion of the identifier number space

The Generic NACK message is identified by PT=RTPFB and FMT=1.

6.3. Payload-Specific Feedback Messages

Payload-Specific FB messages are identified by the value PT=PSFB as

RTCP message type.

Three payload-specific FB messages are defined so far plus an

application layer FB message. They are identified by means of the

FMT parameter as follows:

0: unassigned

1: Picture Loss Indication (PLI)

2: Slice Loss Indication (SLI)

3: Reference Picture Selection Indication (RPSI)

4-14: unassigned

15: Application layer FB (AFB) message

16-30: unassigned

31: reserved for future expansion of the sequence number space

The PLI FB message is identified
by PT=PSFB and FMT=1.

There MUST be exactly one PLI contained in the FCI field

The SLI FB message
is identified by PT=PSFB and FMT=2.

The FCI field MUST contain at least one and MAY contain more than one

SLI.

The RPSI FB message is identified by PT=PSFB and FMT=3.

There MUST be exactly one RPSI contained in the FCI field.

6.4 Application Layer Feedback Messages

Application layer FB messages are a special case of payload-specific

messages and are identified by PT=PSFB and FMT=15. There MUST be

exactly one application layer FB message contained in the FCI field,

unless the application layer FB message structure itself allows for

stacking (e.g., by means of a fixed size or explicit length

indicator).

These messages are used to transport application-defined data

directly from the receiver’s to the sender’s application. The data

that is transported is not identified by the FB message. Therefore,

the application MUST be able to identify the message payload.

Usually, applications define their own set of messages, e.g., NEWPRED

messages in MPEG-4 [16] (carried in RTP packets according to RFC 3016

[23]) or FB messages in H.263/Annex N, U [17] (packetized as per RFC

2429 [14]). These messages do not need any additional information

from the RTCP message. Thus, the application message is simply

placed into the FCI field as follows and the length field is set

accordingly.

Application Message (FCI): variable length

This field contains the original application message that should

be transported from the receiver to the source. The format is

application dependent. The length of this field is variable. If

the application data is not 32-bit aligned, padding bits and bytes

MUST be added to achieve 32-bit alignment. Identification of

padding is up to the application layer and not defined in this

specification.

The application layer FB message specification MUST define whether or

not the message needs to be interpreted specifically in the context

of a certain codec (identified by the RTP payload type). If a

reference to the payload type is required for proper processing, the

application layer FB message specification MUST define a way to

communicate the payload type information as part of the application

layer FB message itself.