RTCRtpRtxParameters lacks "apt"

[aboba]

From: Iñaki Baz Castillo ibc@aliax.net Date: Wed, 15 Oct 2014 13:17:22 +0200 To: "public-ortc@w3.org" public-ortc@w3.org Link: http://lists.w3.org/Archives/Public/public-ortc/2014Oct/0048.html

[aboba]

Correction: http://lists.w3.org/Archives/Public/public-ortc/2014Oct/0049.html Response from Peter Thatcher: http://lists.w3.org/Archives/Public/public-ortc/2014Oct/0050.html Response from Bernard Aboba: http://lists.w3.org/Archives/Public/public-ortc/2014Oct/0051.html

[aboba]

Latest proposal from Peter Thatcher: http://lists.w3.org/Archives/Public/public-ortc/2014Nov/0001.html

There has been a lot of confusion of how to enable RTX, FEC, and RED. Previously we were a little vague about it, relying on the codecs list to contain them like SDP does. But several people think that's unclear, and I agree. So, here's a proposal that makes the RTX, FEC, and RED payload types explicit without having RTX, FED, and RED listed as codecs, and without using codec parameters like "APT":

dictionary RTCRtpCodecParameters { DOMString name; payloadtype payloadType; payloadtype rtxPayloadType; // ... };

dictionary RTCRtpFecParameters { payloadtype payloadType; payloadtype redPayloadType; // If RED is used, RTX refers to RED, not FEC payloadtype rtxPayloadType; // ... };

In case you're wondering why there are so many rtxPayloadTypes, it's because RTX requires a payload type for every other payload type that could be received.

I hope this simplifies and clarifies matters.

[aboba]

Mailing list discussion on capabilities: http://lists.w3.org/Archives/Public/public-ortc/2014Nov/0004.html

Pointer to presentation at IETF 91 on FEC multiplexing: http://www.ietf.org/proceedings/91/slides/slides-91-mmusic-11.pdf

[robin-raymond]

Issue #254 resolves this...