Re: WebRTC spec errata (regarding states)

On 2013-03-13 05:14, Justin Uberti wrote:
>
>
>
> On Tue, Mar 12, 2013 at 3:27 AM, Adam Bergkvist
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     On 2013-03-11 18:23, Justin Uberti wrote:
>
>
>         On Mon, Mar 11, 2013 at 8:33 AM, Adam Bergkvist
>         <adam.bergkvist@ericsson.com
>         <mailto:adam.bergkvist@ericsson.com>
>         <mailto:adam.bergkvist@__ericsson.com
>         <mailto:adam.bergkvist@ericsson.com>>> wrote:
>
>                  I think this would be the dreaded INTERNAL_ERROR; the PC is
>                  essentially
>                  in an undefined state at this point, and the
>         application should
>                  discard
>                  it. The session description might have been fine, but
>         we just
>                  exploded
>                  when trying to apply it.
>
>
>              Ok. We need to specify how that would work. I guess this
>         isn't the
>              only way to end up in such a state. Do you have any
>         suggestions for
>              this text?
>
>
>         Something like:
>
>         The RTCSessionDescription is a valid description but cannot be
>         applied
>         at the media layer.
>
>         This can happen, e.g., if there are insufficient resources to
>         apply the
>         SDP. The user agent
>         MUST then attempt to roll back to the previous session
>         description, if
>         the new description was
>         partially applied when the failure occurred.
>
>         If rollback was not necessary or was completed successfully, let
>         errorType be INCOMPATIBLE_SESSION___DESCRIPTION. The connection
>         retains
>         its previous state.
>         If rollback was not possible, let errorType be INTERNAL_ERROR.
>         The state
>         of the connection is now undefined, and the application should
>         discard
>         it and clean up.
>
>
>     This works, but I think we at least need to set the signaling state
>     to "closed" in the INTERNAL_ERROR case to fail further operations on
>     the connection.
>
>
> I'm not sure that we do. When sockets encounter errors, they don't
> automatically go into a closed state - something has to close them first.

But WebSocket and EventSource do.

>     A bit off-topic.. "closed" feels a bit alien in the signaling state
>     enum. For example, when something like INTERNAL_ERROR happens, it
>     would feel more natural to keep the signaling state in whatever sate
>     it was and have something else indicate that the entire connection
>     is down. So the signaling state would either reach "stable" or stall
>     in it's current state; never go to something like "closed".
>
>
> I know what you mean, especially if "closed" can only be reached by
> calling .close(). That said, I don't know if there's any better place
> for this information; last thing I want is a .closed property.

The ice connection, ice gathering and signaling states are reporting the 
state for rather specific pieces of the machinery. "closed" felt more 
suitable for the general readyState we had previously.

/Adam

Received on Wednesday, 13 March 2013 15:29:08 UTC