Re: WebRTC spec errata (regarding states)

On Tue, Mar 12, 2013 at 3:27 AM, Adam Bergkvist <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<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.


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