RE: RED and FEC and RTX (and related questions!)

Sergio said:

What worries me about this API is that there are a lot of points of failure:

If you don't set rtx.sssrc to same value in each encoding, it will be incorrect

If you don't set same fec.ssrc as media ssrc it will be incorrect
If red ssrc is not set same as media ssrc it will be incorrect

[BA] In this respect ORTC is uglier than SDP where the SSRC of RTX/FEC is only specified once (on the ssrc-group:fec-fr or FID line)

If you set same rtx payload in the encoding with different payload it will be incorrect

[BA] This one we can fix by removing rtx.payload as an encoding parameter, and making it a codec parameter (“apt”) instead.

if you set fec.mechanism to red+ulpfec in one encoding, but you don't add an encoding with fec, it will be incorrect

I foresee it will be a nightmare to both check for all the preconditions that need to be fulfilled in order to verify the encoding parameters, and to actually implement software in top that is aware of all the constrains above that are not obvious by just checking at the api.

[BA] One of the consequences may be that sender.send() and receiver.receive() have to become async.  The alternative (have the onerror eventhandler called with a fatal error after sender.send() or receiver.receive() return) seems ugly at best.

IMHO, the API should make easier to fill all the restrictions. Especially I don't understand why some values like ssrcs and payload types has to be set by the application and not generated internally by the ORTC api and be exposed read only to the app.

In fact, do you realice, that the code above can be reduced to: "I want 1 stream, with vp9,vp8, rtx and red+ulpfec"? or:

streams[0].rtx = yes
streams[0].fec = “red+ulpfec”;
streams[0].encodings[0].name = "vp8"
streams[0].encodings[1].name = "vp9"

At least, we should have an encoding parameters factory that takes as input the information above, and creates the encoding parameters with correct data and default settings.

Internally the ortc stack would find valid ssrcs, payload type numbers, and fill all the data with the known restrictions

Then app could change the returned parameters it at will then at own risk, and be blamed if sets some data that could violate the restrictions.

My 2 cents.

Best regards
Sergio