RTCRtpSender and RTCRtpReceiver state #399

Closed
aboba opened this Issue Feb 29, 2016 · 15 comments

Projects

None yet

4 participants

@aboba
Contributor
aboba commented Feb 29, 2016

Neither the RTCRtpSender nor the RTCRtpReceiver objects have an associated state attribute or state change events. When the onerror event handler is fired is this equivalent to calling stop() (e.g. always non-recoverable)?

@aboba aboba added the 1.1 label Feb 29, 2016
@aboba
Contributor
aboba commented Mar 1, 2016

At the moment, it is not clear when the onerror event handler will be called.

@robin-raymond
Contributor

If "onerror" is ever fired, it's not fatal. This was more done because we didn't want send() and receive() to have a promise but some issues may be discovered asynchronously later. If this is the case, the error can be fired and calling send() or receive() again can resolve the issue. I'm open for discussion on this behaviour but that's how it currently is working...

@aboba aboba added the question label Mar 4, 2016
@robin-raymond
Contributor

We should have a section defining receiver.receive() and sender.send(). Specifically, how to process errors, and what is fatal, non-fatal. E.g. redefining header extensions to have different ID mappings for different receivers on the same transport would be fatal and bad.

@robin-raymond
Contributor

Is a promise needed on a receiver.receive() so that errors on calling receive() are clear as to what happened with what receive() method being called?

E.g. if you called receive() three times in a row for slight adjustments and a method called onerror fired, which receive() call actually failed?

@aboba
Contributor
aboba commented Mar 11, 2016

Since some errors might require accessing multiple objects (e.g. checking the header extension mappings for all receivers on the same transport), receive() (and send(), for that matter) might need to be async. If that change is made, I'm not sure what onerror would be used for.

@aboba aboba added Asignee Action Needed and removed question labels Apr 2, 2016
@robin-raymond robin-raymond was assigned by aboba Apr 2, 2016
@aboba
Contributor
aboba commented Apr 2, 2016

@robin-raymond What do you recommend we do here? Change send() and receive() to async? Clarify the usage of onerror?

@robin-raymond
Contributor

@aboba I'm thinking send(...) and receive(...) should return promises. If the promise failed, then it can be a rejected promise with a failure.

What does 1.0 return?

Plus then we can have getParameters() method that returns the post-filled information for the sender method too if we so choose to add that and we can know it is safe to call because the promise was resolved...

@robin-raymond
Contributor

I think the movement is clearly towards a promise. There's just no other way to know what failed for an asynchronous based operation that fails later after receive() / send() returns. onerror would not resolve this problem.

@robin-raymond
Contributor

This is the fix that we need to do:

partial interface RTCRtpSender {
   Promise<void>  send(RTCRtpParameters parameters);
   attribute EventHandler?     onerror;  // REMOVE THIS
}

partial interface RTCRtpReceiver {
    Promise<void>    receive (RTCRtpParameters parameters);
   attribute EventHandler?     onerror;  // REMOVE THIS
}

The event summary also needs to remove those events for onerror.

@ibc
Contributor
ibc commented Apr 16, 2016

👍

BTW: wouldn't we need the very same for setTransport()?

@robin-raymond robin-raymond removed their assignment Apr 16, 2016
@aboba
Contributor
aboba commented Apr 20, 2016

Yes, setTransport() probably needs to be async as well.

@robin-raymond
Contributor

@aboba @ibc I can't think of anything (other than the transport being in an invalid state, i.e. "closed") that would cause adverse affects only detected later. Do you have any ideas? I'm not sure there will be a possible "rejection", more of an exception of the transports are in the wrong state at the time of being passed into the sender/receiver.

However, I think of is the promise would indicate when the change of transport has completed. For example, if you were remapping from one transport to another and you wanted to know when it was "safe" to dump an old transport in favour of a new one then you'd want to know when the promise was resolved and thus it's safe to close out the old transport. That's a justification for making "setTransport" a promise.

I'm already convinced "send / receive" methods require a promise because "onerror" is just confusing when / if it fires.

Thoughts?

@ibc
Contributor
ibc commented Apr 20, 2016 edited

I'm not aware of which kind of internal complexity could make setTransport() fail asynchronously and, if so, I don't understand why we should wait for a returned Promise to resolve in order to close the old transport. The only I don't want is a onerror event triggered by user initiated actions.

So I'm fine with setTransport() returning void or raising an Error.

@murillo128

setTransport should return a promise as per #467

@aboba aboba added PR exists and removed to-do-next-draft labels Apr 25, 2016
@aboba aboba added a commit that referenced this issue Apr 25, 2016
@aboba aboba Promise for send(), receive() and setTransport()
Addresses the following Issues: 
#399
#469
94a13e5
@aboba aboba added a commit that referenced this issue Apr 26, 2016
@aboba aboba Examples: async usage of send(), receive() and setTransport()
Fix for Issues: 
#399
#469

More work to do (please do not merge yet).
31e9395
@robin-raymond
Contributor

Looks better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment