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.