Clarification on encodings codecPayloadType for RTCRtpSender

[murillo128]

It is not explicitly said nowhere in the specification, but I assume that encodings only make sense for media codecs. That is, for non-media codecs [CN,dtmf, RED and FEC] there is no sense of adding them in the encodings and will be used as follow:

-DTMF present in codecs only means that if can create a RTCDtmfSender for that sender and it will have the canInsertDTMF to true, and false if not present.
-RED will be used whenever an encoding has a fec.mechanishm of "red" or "red-ulpfec", and will not be used in an other case. It is ssrc-dependant so if an RTCRtpSender has two encodings with different ssrcs one with fec="red" and the other without it, it will only be used on the former one.
-FEC same as RED but on mechanishm = "red-ulpfec" or "flexfec".
-CN it will be used to send a comfort noise packets in case no voice is detected on track, on all ssrc streams.

RTX is a different kind and there are already other issues handling it.

So, I would recommend to add something like:

RTCRtpSender will ignore any encoding containing a codecPayloadType which references a non-media codec ("cn", "dtmf", "red", "rtx", or a forward error correction codec).

[robin-raymond]

@murillo128 Correct. We did add some text in the RTCRtpSender.send() about not matching non-media codecs. I'm guessing you feel more is needed to describe each of these codecs?

Media to be sent is controlled by parameters. If send() is called with invalid parameters, throw an InvalidParameters exception. If rtcpTransport is not set and send(parameters) is called with parameters.rtcp.mux set to "false", throw an InvalidParameters exception. For each value of i from 0 to the number of codecs, check that each value of parameters.codecs[i].name not equal to "red", "rtx" or a forward error correction codec is included in getCapabilities(track.kind).codecs[j].name, where j goes from 0 to the number of codecs. If a match is not found for any value of i, throw an InvalidParameters exception. If parameters.encodings is unset, the browser behaves as though a single encodings[0] entry was provided, with encodings[0].ssrc set to a browser-determined value, encodings[0].active set to "true", encodings[0].codecPayloadType set to codecs[j].payloadType where j is the index of the first codec that is not "cn", "dtmf", "red", "rtx" or a forward error correction codec, and all the other parameters.encodings[0] attributes (e.g. fec, rtx, priority, maxBitrate, minQuality, resolutionScale,etc.) unset. Calling send(parameters) does not update parameters based on what is currently being sent. The RTCRtpSender object starts sending when send() is called for the first time, and changes the sending parameters when send() is called again. The RTCRtpSender object stops sending when stop() is called. SSRC misusage results in an InvalidParameters exception.

[murillo128]

I think that adding the last phrase would be enough:

RTCRtpSender will ignore any encoding containing a codecPayloadType which references a non-media codec ("cn", "dtmf", "red", "rtx", or a forward error correction codec).

The list was mainly to confirm that I was not missing any case.

[aboba]

Is the PR enough to close this issue?

[robin-raymond]

I believe so, PR merged and closing.