Re: Proposed resolution to Issue 119: RTCRtpSender/Reciever is calling send() after send() or receiver() after receive() legal?

I’m not sure how we overlooked this but there is a problem with the RTCRtpReceiver. We either:
a) need to throw an exception if the JS supplies a mixed “kind” of audio and video codecs to the RTCRtpReceiver so that calling receive() will produce a valid .track with a valid kind.
b) allow JS to call receive() with mixed kinds of audio/video but have the .track object be null until an event fires for the RTCRtpReceiver saying the track object is now valid

Right now we have it where the track object is in an undetermined state of neither audio nor video and allow mixed kinds for the RTCRtpReceiver with no event that tells us that the track object is now valid. That doesn’t seem right to me. I’m fine with either (a) or (b) solution. I think (a) is somewhat better because then the .track object is always valid and ready to be wired and we don’t need an additional event.

-- 
Robin Raymond


On August 6, 2014 at 4:21:42 PM, Bernard Aboba (bernard.aboba@microsoft.com) wrote:

I believe that send() after send() and receive() after receive() are both legal.

 

Here are the proposed changes to the text of the send() and receive() methods:

 

send

Media to be sent is controlled by parameters. If send() is called with invalid parameters, throw an InvalidParametersexception. The send() method does not update parameters based on what is currently being sent, so that the value ofparameters remains that last passed to the send() method. The RTCRtpSender object starts sending when send() is called for the first time, and changes the sending parameters when send() is called again. The RTCRtpSender object stops sending when stop() is called.

 

receive

Media to be received is controlled by parameters. If receive() is called with invalid parameters, throw an InvalidParameters exception. The receive() method does not update parameters based on what is currently being received, so that the value of parameters remains that last passed to the receive() method. The RTCRtpReceiver object starts receiving when receive() is called for the first time, and changes the receiving parameters when receive() is called again. The RTCRtpReceiver object stops receiving when stop() is called. 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 parameters.codecs are all of a single kind then track.kind is set to that kind; if parameters.codecs are of mixed kind, then track.kind is set to "".