RTCRtpSender and RTCRtpReceiver state

[aboba]

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]

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

[robin-raymond]

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

[robin-raymond]

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]

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]

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]

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

[robin-raymond]

@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]

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]

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]

👍

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

[aboba]

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

[robin-raymond]

@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]

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

[robin-raymond]

Looks better.