Re: WebRTC spec errata (regarding states)

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

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

/Adam

Received on Tuesday, 12 March 2013 10:28:08 UTC