Re: Issue 444: RTX APT capability?

Peter said:


"Sorry for being late to the conversation. I have a few thoughts, and I'm not sure how redundant or different they are, since it's such a long conversation and it's hard to tell what the current state is.

1.    Capabilities shouldn't say anything about RTX. Just assume RTX can be sent for any codec. I think we are all in agreement about that.

2.    Parameters mostly just needs to specify an RTX PT one way or another. I think it would be nice if we had codec.rtxPayloadType instead of rtxCodec.parameters["apt"]. However, that will probably put it out of sync with WebRTC.

3.    You also have to pick a PT for FEC, but it's not dumb like RTX. You just need one, not one per other PT.
"

[BA] In my opinion, the current state is that neither ORTC nor the WebRTC 1.0 API spec are crystal clear about what is expected in Capabilities or Settings with respect to RTX/RED/FEC.  Some clarifying questions:


1.       Is RTX included within RTCRtpCapabilities?

a.       For example in WebRTC 1.0, should we expect to see RTCRtpCapabilities.codecs[j].mimeType = "rtx"?

b.      Assuming it is included, would it make sense to add a sentence to WebRTC 1.0/ORTC to say that the inclusion means that it can be used for any codec?  Sometimes it is good to explicitly say things that everyone agrees are obvious.

2.  In WebRTC 1.0, do you expect there to be multiple "rtx" entries within parameters.codecs[], one for each codec that is being retransmitted?  For example, codecs[i].sdpFmtpLine = "a=fmtp:99 apt=98;rtx-time=3000" for one rtx line and codecs[j].sdpFmtpLine = "a=fmtp:100 apt=101;rtx-time=3000" for another one.

a.       Would you support an WebRTC 1.0 PR that would remove rtx entries in codecs[] and add unsigned short rtxPayloadType to the RTCRtpCodecParameters dictionary?  Personally, I believe we either need to do this uniformly in both ORTC and WebRTC 1.0, or not do it.

3.       Do you advocate keeping FEC and RED as codecs with RTCRtpCapabilities and RTCRtpCodecParameters?