RTCRtpSender/Reciever is calling send() after send() or receiver() after receive() legal? #119

Closed
robin-raymond opened this Issue Jun 27, 2014 · 3 comments

Projects

None yet

2 participants

@robin-raymond
Contributor

To change your encoding parameters, do you create a new sender/receiver object, or do you re-call "send()" (or "receive()") method again?

@robin-raymond robin-raymond added the 1.1 label Jun 27, 2014
@robin-raymond
Contributor

$related #103

@aboba
Contributor
aboba commented Jul 8, 2014

This should be legal. However, be aware that calling receive again could have unintended consequences due to latching rules.

@aboba aboba closed this Aug 6, 2014
@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Aug 19, 2014
Robin Raymond Clarification of the ICE restart issue, as noted in:
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
4916cd5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment