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.
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.