- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 5 Nov 2014 22:43:21 +0000
- To: "public-ortc@w3.org" <public-ortc@w3.org>
In addition to support within Parameters, we also need to describe how FEC, RTX and RED are indicated in Capabilities. One way to indicate support for RTX might be to modify RTCRtpCodecCapability as follows: partial dictionary RTCRtpCodecCapability { DOMString name; DOMString kind; payloadtype preferredPayloadType; payloadtype preferredRtxPayloadType; }; Since FEC mechanisms are exposed in RTCRtpCapabilities, we can discover what mechanisms are available (assuming we actually define an MTI FEC scheme so we have at least one). dictionary RTCRtpCapabilities { sequence<RTCRtpCodecCapability> codecs; sequence<RTCRtpHeaderExtension> headerExtensions; sequence<DOMString> fecMechanisms; }; However, I am wondering how we discover some other details about FEC (whether it can be supported stand-alone or with RED, the preferredPayload types, etc.). In other words, should we have sequence<RTCFecCapability> instead of sequence <DOMString>? There is also an underlying assumption here, which we should perhaps state explicitly, which is that RED is used to package FEC along with the encoding, not for redundant encodings of more than one codec. It is this assumption which allows us to discover RED capabilities and set RED parameters as part of FEC capability/parameters, rather than on its own (as would be the case if it were treated as a codec).
Received on Wednesday, 5 November 2014 22:43:50 UTC