RTP parameters describe the media that a producer endpoint sends to mediasoup (RTP send parameters) or the media that mediasoup forwards to a consumer endpoint (RTP receive parameters).
RTP capabilities, instead, define what mediasoup or a consumer endpoint can receive, thus RTP parameters depend on (or are constrained to) the remote RTP capabilities.
When a mediasoup Router is created it's provided with a set of RtpCodecCapability that define the audio and video codecs enabled in that router. The application then retrieves the computed router.rtpCapabilities (which include the router codecs enhanced with retransmission and RTCP capabilities, and the list of RTP header extensions supported by mediasoup) and provides the endpoints with those RTP capabilities.
The endpoint wishing to send media to mediasoup uses the router's RTP capabilities and its own ones to compute its sending RTP parameters and transmits them to the router (assuming it has already created a transport to send media). The application then creates a Producer instance in the router by using the transport.produce() API.
When an endpoint wishes to receive from the router media associated to a specific producer (assuming it has already created a transport to receive media) the application takes the endpoint's RTP capabilities and uses the transport.consume() API indicating those capabilities and the producerId
to be consumed, thus generating a Consumer instance whose RTP receive parameters have been calculated by merging both, the producer's RTP parameters and the endpoint's RTP capabilities. The application can then signal the resulting consumer.rtpParameters (along with other information) to the endpoint.
mediasoup is flexible in what it receives from endpoints, meaning that the producer's RTP parameters can have codec payloadType
values and RTP header extension id
values that differ from the preferred ones in the router's RTP capabilities. However, the producer's RTP parameters MUST NOT include codecs not present in the router's capabilities.
mediasoup is strict in what it sends to endpoints, meaning that the codec preferredPayloadType
values and RTP header extension preferredId
values in the endpoint's RTP capabilities MUST match those in the router's RTP capabilities. And then mediasoup will build a RTP receive parameters based on the RTP parameters of the producer being consumed and the endpoint's RTP capabilities.
At the end, the rule is simple:
There are two types of RTP parameters (RtpSendParameters and RtpReceiveParameters), both sharing the following definition:
Field | Type | Description | Required | Default |
---|---|---|---|---|
mid |
String | The MID RTP extension value as defined in the BUNDLE specification. | No | |
codecs |
Array<RtpCodecParameters> | Media and RTX codecs in use. | Yes | |
headerExtensions |
Array<RtpHeaderExtensionParameters> | RTP header extensions in use. | No | [ ] |
encodings |
Array<RtpEncodingParameters> | Transmitted RTP streams and their settings. | No | |
rtcp |
RtcpParameters | Parameters used for RTCP. | No |
@inherits
RtpParameters
The RTP send parameters describe a media stream received by mediasoup from an endpoint through its corresponding mediasoup Producer.
mid
value that the mediasoup transport will use to match received RTP packets based on their MID RTP extension value.encodings
array must include a ssrc
field or a rid
field (the RID RTP extension value).mid
value or the encoding must indicate the ssrc
of the stream.mid
value.
@inherits
RtpParameters
The RTP receive parameters describe a media stream as sent by mediasoup to an endpoint through its corresponding mediasoup Consumer.
encodings
array (even if the corresponding producer uses simulcast). The consumer sends a single and continuous RTP stream to the endpoint and spatial/temporal layer selection is possible via consumer.setPreferredLayers().ssrc
values randomly generated for all of its encodings
(and optional rtx: { ssrc: XXXX }
if the endpoint supports RTX), regardless of the original RTP send parameters in the associated producer. This applies even if the producer's encodings
have rid
set.The RTP capabilities define what mediasoup or an endpoint can receive at media level.
Field | Type | Description | Required | Default |
---|---|---|---|---|
codecs |
Array<RtpCodecCapability> | Supported media and RTX codecs. | No | [ ] |
headerExtensions |
Array<RtpHeaderExtension> | Supported RTP header extensions. | No | [ ] |
Provides information on codec settings within the RTP parameters. The list of media codecs supported by mediasoup and their settings is defined in the supportedRtpCapabilities.ts file.
Field | Type | Description | Required | Default |
---|---|---|---|---|
mimeType |
String | The codec MIME media type/subtype (e.g. “audio/opus”, “video/VP8”). | Yes | |
payloadType |
Number | The value that goes in the RTP Payload Type Field. Must be unique. | Yes | |
clockRate |
Number | Codec clock rate expressed in Hertz. | Yes | |
channels |
Number | The number of channels supported (e.g. two for stereo). Just for audio. | No | 1 |
parameters |
Object | Codec-specific parameters available for signaling. Some parameters (such as “packetization-mode” and “profile-level-id” in H264 or “profile-id” in VP9) are critical for codec matching. | No | |
rtcpFeedback |
Array<RtcpFeedback> | Transport layer and codec-specific feedback messages for this codec. | No | [ ] |
See the Codec Parameters section below for more info about the codec parameters
.
Provides information on RTCP feedback messages for a specific codec. Those messages can be transport layer feedback messages or codec-specific feedback messages. The list of RTCP feedbacks supported by mediasoup is defined in the supportedRtpCapabilities.ts file.
Field | Type | Description | Required | Default |
---|---|---|---|---|
type |
String | RTCP feedback type. | Yes | |
parameter |
String | RTCP feedback parameter. | No |
Provides information relating to an encoding, which represents a media RTP stream and its associated RTX stream (if any).
Field | Type | Description | Required | Default |
---|---|---|---|---|
ssrc |
Number | The media SSRC. | No | |
rid |
String | The RID RTP extension value. Must be unique. | No | |
rtx |
Object | RTX stream information. It must contain a numeric ssrc field indicating the RTX SSRC. |
No. | |
dtx |
Boolean | It indicates whether discontinuous RTP transmission will be used. Useful for audio (if the codec supports it) and for video screen sharing (when static content is being transmitted). | No | false |
scalabilityMode |
String | Number of spatial and temporal layers in the RTP stream (e.g. “L1T3”). See webrtc-svc. | No | |
maxBitrate |
Number | Maximum bitrate the sender will produce for this stream. | No | |
maxFramerate |
Double | Maximum video frame rate (in frames per second) the sender will produce for this stream. | No | |
adaptivePtime |
Boolean | Whether this encoding may dynamically change the frame length. | No | false |
scalabilityMode
is defined in the Scalable Video Coding (SVC) Extension for WebRTC specification (check the Simulcast and SVC sections for more information).maxFramerate
and adaptivePtime
are defined in the WebRTC Extensions specification.Defines a RTP header extension within the RTP parameters. The list of RTP header extensions supported by mediasoup is defined in the supportedRtpCapabilities.ts file.
Field | Type | Description | Required | Default |
---|---|---|---|---|
uri |
String | The URI of the RTP header extension, as defined in RFC 5285. | Yes | |
id |
Number | The numeric identifier that goes in the RTP packet. Must be unique. | Yes | |
encrypt |
Boolean | If true , the value in the header is encrypted as per RFC 6904. |
No | false |
parameters |
Object | Configuration parameters for the header extension. | No |
parameters
are currently considered.Provides information on RTCP settings within the RTP parameters.
Field | Type | Description | Required | Default |
---|---|---|---|---|
cname |
String | The Canonical Name (CNAME) used by RTCP (e.g. in SDES messages). | No | |
reducedSize |
Boolean | Whether reduced size RTCP RFC 5506 is configured (if true ) or compound RTCP as specified in RFC 3550 (if false ). |
No | true |
cname
is given in a producer's RTP parameters, the mediasoup transport will choose a random one that will be used into RTCP SDES messages sent to all its associated consumers.reducedSize
to always be true
.Provides information on the capabilities of a codec within the RTP capabilities. The list of media codecs supported by mediasoup and their settings is defined in the supportedRtpCapabilities.ts file.
Exactly one RtpCodecCapability
will be present for each supported combination of parameters that requires a distinct value of preferredPayloadType
. For example:
Field | Type | Description | Required | Default |
---|---|---|---|---|
kind |
MediaKind | Media kind (“audio” or “video”). | Yes | |
mimeType |
String | The codec MIME media type/subtype (e.g. “audio/opus”, “video/VP8”). | Yes | |
preferredPayloadType |
Number | The preferred RTP payload type. | Yes | |
clockRate |
Number | Codec clock rate expressed in Hertz. | Yes | |
channels |
Number | The number of channels supported (e.g. two for stereo). Just for audio. | No | 1 |
parameters |
Object | Codec specific parameters. Some parameters (such as “packetization-mode” and “profile-level-id” in H264 or “profile-id” in VP9) are critical for codec matching. | No | |
rtcpFeedback |
Array<RtcpFeedback> | Transport layer and codec-specific feedback messages for this codec. | No | [ ] |
RtpCodecCapability
entries in the mediaCodecs
array of RouterOptions do not require preferredPayloadType
field (if unset, mediasoup will choose a random one). If given, make sure it's in the 96-127 range. Neither it requires rtcpFeedback
.
Provides information relating to supported header extensions. The list of RTP header extensions supported by mediasoup is defined in the supportedRtpCapabilities.ts file.
Field | Type | Description | Required | Default |
---|---|---|---|---|
kind |
MediaKind | Media kind (“audio” or “video”). | Yes | |
uri |
String | The URI of the RTP header extension, as defined in RFC 5285. | Yes | |
preferredId |
Number | The preferred numeric identifier that goes in the RTP packet. Must be unique. | Yes | |
preferredEncrypt |
Boolean | If true , it is preferred that the value in the header be encrypted as per RFC 6904. |
No | false |
direction |
String | If “sendrecv”, mediasoup supports sending and receiving this RTP extension. “sendonly” means that mediasoup can send (but not receive) it. “recvonly” means that mediasoup can receive (but not send) it. | No |
direction
field is just present in mediasoup RTP capabilities (retrieved via router.rtpCapabilities or mediasoup.getSupportedRtpCapabilities()). It's ignored if present in endpoints' RTP capabilities.Value | Description |
---|---|
“audio” | Audio media kind. |
“video” | Video media kind. |
When a producer includes codec parameters into its RTP send parameters, those parameters are passed verbatim to the RTP receive parameters of the consumers associated to that producer.
Some of those parameters are part of the codec settings and are used for codec matching. Some other codec parameters affect the operation of mediasoup for the corresponding producer and consumers.
These parameters are part of the codec settings, meaning that their values determine whether an entry in rtpParameters.codecs
matches or not an entry in the remote rtpCapabilities.codecs
. These parameters are codec-specific:
H264 codec matching rules are complex and involve inspection of the following parameters (see the RFC 6184 for more details):
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
“packetization-mode” | Number | 0 means that the single NAL mode must be used. 1 means that the non-interleaved mode must be used. | No | 0 |
“profile-level-id” | String | Indicates the default sub-profile and the default level of the stream. | Yes | |
“level-asymmetry-allowed” | Number | Indicates whether level asymmetry is allowed. | No | 0 |
mediasoup uses the h264-profile-level-id JavaScript library to evaluate those parameters and perform proper H264 codec matching.
Depending the negotiated H264 “packetization-mode” and “profile-level-id”, Chrome may use OpenH264 software encoder or H264 external hardware encoder. In the latter case, Chrome will NOT generate simulcast but a single stream.
See the reported issue for more information.
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
“profile-id” | Number | VP9 coding profile (more info). Supported values are 0 and 2. | No | 0 |
These parameters influence the mediasoup operation by enabling or disabling some features. These parameters are codec-specific:
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
“useinbandfec” | Number | If 1, mediasoup will use the worst packet fraction lost in the RTCP Receiver Report received from the consuming endpoints and use it into the Receiver Report that mediasoup sends to the OPUS producer endpoint. This will force it to generate more in-band FEC into the OPUS packets to accommodate to the worst receiver. | No | 0 |
“usedtx” | Number | If 1, mediasoup will not consider the stream as inactive when there is no RTP traffic. Same behavior is achieved by indicating dtx : true in the corresponding encoding in the RTP send parameters. |
No | 0 |
Simulcast involves sending N separate video RTP streams (so N different SSRCs) representing N different qualities of the same video source. If RTX is used, there would also be N additional RTP RTX streams, one for each media RTP stream. Each media RTP stream may also contain M temporal layers.
scalabilityMode
in the encoding
.When creating a simulcast producer, the associated rtpParameters given to transport.produce() must conform to the following rules:
encodings
array or a single entry with scalabilityMode
indicating 1 spatial layer and more than 1 temporal layer.ssrc
field or a rid
field (the RID RTP extension value) to help the mediasoup producer identify which RTP stream each packet belongs to.encodings
must be ordered from lowest to highest resolution (encodings[0]
means “spatial layer 0” while encodings[N-1]
means “spatial layer N-1”, being N the number of simulcast streams).scalabilityMode
in each encoding must be 1.scalabilityMode
field can be omitted (it defaults to “L1T1”, this is, one spatial layer and one temporal layer).Simulcast consumers will just get a single stream and hence a single entry in their rtpParameters.encodings
array. Such a encoding entry has a scalabilityMode
value that determines the number of spatial layers (number of simulcast streams in the producer) and the number of temporal layers.
To clarify, if the producer uses simulcast with 3 streams (3 SSRCs), mediasoup will forward a single and continuous stream (1 SSRC) to the consumer.
The encoding entry in rtpParameters.encodings
of the consumer contains a scalabilityMode
field whose L value (number of spatial layers) matches the number of streams in the producer, and whose T value (number of temporal layers) matches the number of temporal layers in each stream in the producer.
The following examples just show the rtpParameters.encodings
field and, for simplicity, do not include RTX information.
encodings :
[
{ ssrc: 111110 },
{ ssrc: 111111 },
{ ssrc: 111112 }
]
encodings :
[
{ ssrc: 222220, scalabilityMode: 'L3T1' }
]
encodings :
[
{ rid: 'r0', scalabilityMode: 'L1T3' },
{ rid: 'r1', scalabilityMode: 'L1T3' },
{ rid: 'r2', scalabilityMode: 'L1T3' },
{ rid: 'r3', scalabilityMode: 'L1T3' }
]
encodings :
[
{ ssrc: 222220, scalabilityMode: 'L4T3' }
]
SVC involves sending a single RTP stream with N spatial layers and M temporal layers. If RTX is used, there would also be an additional RTP RTX stream.
mediasoup implements two types of SVC, full SVC and K-SVC. The main difference is that, in K-SVC, a RTP key frame is required in order to up/down switch the maximun spatial layer that mediasoup forwards to a consumer. For more information about SVC in WebRTC check the webrtc-svc specification (work in progress).
Currently mediasoup supports SVC for VP9 codec in both, full SVC and K-SVC modes. </div>
When creating a SVC producer, the associated rtpParameters given to transport.produce() must conform to the following rules:
encodings
array.SVC consumers will get a single stream and hence a single entry in their rtpParameters.encodings
array. Such a encoding entry has a scalabilityMode
value that determines the number of available spatial and temporal layers (same value as in the associated producer).
The following examples just show the rtpParameters.encodings
field and, for simplicity, do not include RTX information.
encodings :
[
{ ssrc: 111110, scalabilityMode: 'L3T2' }
]
encodings :
[
{ ssrc: 222220, scalabilityMode: 'L3T2' }
]
encodings :
[
{ ssrc: 111110, scalabilityMode: 'L4T5_KEY' }
]
encodings :
[
{ ssrc: 222220, scalabilityMode: 'L4T5_KEY' }
]