- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Tue, 18 Feb 2014 23:42:13 +0000
- To: Peter Thatcher <pthatcher@google.com>
- CC: "public-orca@w3.org" <public-orca@w3.org>
BTW, I think I've noticed a potentially unintended consequence in the definition of RTCRtpEncodingParameters. Because RTCRtpEncodingParameters.SSRC is not nullable, this implies that SSRC(s) MUST be specified for an RTCRtpReceiver object to receive a stream via RTCRtpReceiver.receive. In other words, in an audio scenario there is no way to just set RTCRtpCodec.payload-id to enable an RTCRtpReceiver object to receive an incoming audio stream without also configuring the SSRC and/or receive-appId. For a (legacy) audio scenario where there is no receive-appId, this seems like it could result in some audio loss. It seems like it would be desirable to be able to specify the payload-id and have the RTCRtpReceiver object receive a single stream right from the start without needing to handle an unsignaled SSRC event.
Received on Tuesday, 18 February 2014 23:42:43 UTC