RtpSender.send() must enforce stricter rules

[ibc]

RtpSender.send():

7- For each value of i from 0 to the number of codecs, check that each value of withParameters.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, return a promise rejected with InvalidParameters.

That is a too much simplistic check. The fact that the codec name matches one in getCapabilities() does not mean, at all, that it is the "same" codec. Lot of scenarios here:

• What would happen if send() is called with an "audio/opus" codec that includes rtcpFeedback entries not present in the "audio/opus" codec of the local capabilities?
• Or what would happen if clockRate does not match?
• Or imagine that local "video/H264" supports packetization-mode 0 and 1, but send() is called with codec.parameters.packetizationMode: 2.

[aboba]

Related to #473

[aboba]

Beyond developing the checks, there is also the question of how error reporting works if an issue is found.
Let us say that parameters.headerExtensions[j].uri does not match one of the values of
sender.getCapabilities().headerExtensions[i].uri where i = 0 to the number of header extensions.
Is there text in error.message to make it clear what went wrong?

[ibc]

We don't have a granular API here but a send() method that accepts a complex Object params argument. It those params are wrong the method should fail with a TypeError? instance and a custom text message describing the issue. However such a text message is up to each vendor and it's just valid for debugging, nothing else.

[robin-raymond]

@ibc did we get everything?

[ibc]

Sorry, I was on vacation. Yes, much better now.