Re: What is the closing state for?

On Fri, Aug 24, 2012 at 8:42 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
> On 8/24/2012 10:15 AM, Eric Rescorla wrote:
>>
>> Looking over the current specification I see that it specifies a "closing"
>> state
>> for the RTCPeerStateEnum (see S 5.1.6). However, I don't see any way
>> to get into that state. The specification requires that when you call
>> pc.close()
>> you transition right to the CLOSED state:
>>
>>    When the close() method is invoked, the user agent must run the
>> following steps:
>>
>>    If the RTCPeerConnection object's RTCPeerConnection readiness state
>> is CLOSED (3), throw an INVALID_STATE_ERR exception.
>>
>>    Destroy the RTCPeerConnection ICE Agent, abruptly ending any active
>> ICE processing and any active streaming, and releasing any relevant
>> resources (e.g. TURN permissions).
>>
>>    Set the object's RTCPeerConnection readiness state to CLOSED (3).
>>
>> And looking through the document I see no references to any state
>> transition
>> that would bring the PC (as opposed to the DataChannel) to CLOSING.
>>
>> I propose we remove the CLOSING state.
>
>
> This may be the right solution.  I believe the assumption may have been that
> Close would do a clean shutdown, or that when an app was (via application
> protocol) is in the process of a clean shutdown via signaling, the state
> would be closing.  (Perhaps set to CLOSING, send "BYE"-equivalent to peer,
> when peer says OK ACK the OK and call Close).  But this only makes sense if
> the CLOSING state somehow helps us during that time period.

My guess is that this was the intention but then it got lost somewhere in favor
of the current abrupt algorithm.

-Ekr

Received on Friday, 24 August 2012 15:50:56 UTC