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

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 "".