RTCRtpCapabilities

Bernard asked me what I thought the RTCRtpCapabilities should look
like.  Here's what I think they should look like:

dictionary RTCRtpCapabilities {
  sequence<RTCRtpCodec>    audioCodecs;
  sequence<RTCRtpCodec>    videoCodecs;
  sequence<DOMString>      headerExtensions;  // Just the URIs
  sequence<RTCRtpFeatures> features;
}

dictionary RTCRtpCodec {
  DOMString name;  // aka MIME media type
  int? clockrate;
  int? channels;
  sequence<KeyValueParam> formatParameters;
}

dictionary KeyValueParam {
  DOMString key;
  DOMString value;
};

enum RTCRtpFeatures {
  "nack",  // from RFC 4585,
  // ...
}


This is a lot like the existing RTCCodec, with the following notable
differences:
- There are two lists of codecs: one audio and one video.  I suppose
we could mix them together, but I think it's more convenient this way.
- The RTCCodec doesn't have a specific payload type, because that's
not part of a "capability".
- There are header extensions in the capabilities.
- There are "rtp features" in the capabilities, with a list we can
expand on later.

It still lacks RED and FEC, though, and I think we'd want to nail down
how those would fit into the RTCRtpCapabilities.  Are they an
RTCRtpFeature, or a new dictionary type?


In short, it's an expansion of the existing RTCCodec to match the new
RtpSender/RtpReceiver model.

Received on Tuesday, 4 February 2014 00:34:47 UTC