Mandatory "kind" in RTCRtpReceiver constructor #141
If done, the interface would look like this:
[Constructor(DOMString kind, RTCDtlsTransport transport, optional RTCDtlsTransport rtcpTransport)]
Not that "readonly attribute MediaStreamTrack track" is also used in the WebRTC 1.0 RTCRtpReceiver definition.
What would be the advantage of supplying it?
On Mon, Aug 4, 2014 at 9:12 PM, aboba email@example.com wrote:
Here is a proposed resolution:
In Section 9.7.1, add the following text to the explanation of RTCRtpCodecParameters.name:
In Section 7.3.2, add the following explanatory text to "receive":
After receive() returns, track is set, and the value of track.kind is determined based on the kind of the codecs provided in parameters.codecs. If all the codecs are of a single kind then track.kind is set to that kind; if the kind differs between codecs, then track.kind is set to "all".
w3c#93 Clarified onerror usage in sender and receiver objects, as noted in: w3c#95 Clarified SST-MS capability issue noted in: w3c#108 Clarification of send() and receive() usage as noted in: w3c#119 Changed ICE state diagram as noted in: w3c#122 Removed getParameters methods and changed send() method as noted in: w3c#136 Changed definition of framerateScale and resolutionScale as noted in: w3c#137 Substituted "muxId" for the "receiverId" as noted in: w3c#138 w3c#140 Clarified the setting of track.kind as described in: w3c#141 Added SSRC conflict event to the RTCRtpSender, as described in: w3c#143 Addressed the "end of candidates" issues noted in: w3c#142 w3c#144