- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Fri, 24 Aug 2012 11:42:32 -0400
- To: public-webrtc@w3.org
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. -- Randell Jesup randell-ietf@jesup.org
Received on Friday, 24 August 2012 15:43:26 UTC