- From: Shijun Sun <shijuns@microsoft.com>
- Date: Tue, 5 Aug 2014 19:11:01 +0000
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>, Peter Thatcher <pthatcher@google.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>
That should work as well. Along the same direction, since there is no guarantee that apps will always set the "kind" in the dictionary explicitly, we need to define a default value for it. In addition, the "kind" of receiver.track should be persistent, so we need the logic anyway to reject contradictory params in additional receive() calls. -----Original Message----- From: Bernard Aboba [mailto:Bernard.Aboba@microsoft.com] Sent: Tuesday, August 5, 2014 11:31 AM To: Peter Thatcher Cc: public-ortc@w3.org Subject: RE: Issue 141: Mandatory "kind" in RTCRtpReceiver constructor Peter Thatcher said: "Right, and I think this is easy to do in the implementation. In fact, if we had the JS pass down the kind explicitly, it would still need to do so anyway, because if the JS passes down kind=audio, and then passes down video codecs, the implementation should complain. So, it needs to check either way, and I'd prefer not having duplicate, possibly contradictory parameters." [BA] Question: would it make sense to include "kind" in RTCRtpCodecParameters? It is already in RTCRtpCodecCapability.
Received on Tuesday, 5 August 2014 19:11:32 UTC