Re: Please clarify whether onsignalingstatechange fires for the final state change into "closed"

I agree that this and the whole topic of closing a PC needs clarification.

If close() is a blocking function then:
   - we do not need to fire the onsignalingstatechange callback
   - but the implementation would have to either:
     - cancel all pending callbacks from previous async function calls
     - wait for all pending callbacks to fire which could result in a 
really long blocking
   - depending on the device and the implementation cleaning up 
everything (even without pending callbacks) could take substantial time
If close() is async:
   - we need to fire the onsignalingstatechange callback once the close 
state has been reached
   - we should clarify what happens with pending callback from previous 
async function calls:
     - the current wording for createAnswer() and createOffer() seem to 
suggest that all callback should be silently suppressed (this leave it 
up to the implementer if he wants to cancel them or wait for the 
callback to happen but not deliver them)
     - all pending callbacks no matter if successful or not could call 
the failure callback as the underlying PC object is dead now

I'm in favor adding clarification that close() is async, and therefore 
need to fire the onsignalingstatechange callback and furthermore results 
in all pending callbacks being suppressed.

If people agree with this I can provide clarifying paragraphs for the doc.

Best Regards
   Nils Ohlmeier

On 4/11/14, 8:48 AM, Jan-Ivar Bruaroey wrote:
> Sorry, I buried my lead:
>
> Please clarify whether onsignalingstatechange fires for the final 
> state change into "closed".
>
> .: Jan-Ivar :.
>
> On 4/10/14 10:00 PM, Jan-Ivar Bruaroey wrote:
>> I have a follow-up request related to something that hasn't been 
>> fixed yet:
>>
>> On 8/5/13 12:44 PM, Jan-Ivar Bruaroey wrote in 
>> http://lists.w3.org/Archives/Public/public-webrtc/2013Aug/0011.html :
>>> Just wanted to point out a typo here: 
>>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPeerConnection-onsignalingstatechange
>>>> onsignalingstatechange of type EventHandler,
>>>>     This event handler, of event handler event type 
>>>> signalingstatechange, MUST be supported by all objects implementing 
>>>> the RTCPeerConnection interface. It is called any time the 
>>>> readyState changes, i.e., from a call to setLocalDescription, a 
>>>> call to setRemoteDescription, or code. It does not fire for the 
>>>> initial state change into new.
>>>
>>> s/readyState/signalingstate/
>>>
>>> readyState was the old name.
>>>
>>> Not to be confused with RTCDataChannel.readyState or 
>>> MediaStreamTrack.readyState (e.g. all other references to readyState 
>>> in this doc).
>>
>> The text says: "It does not fire for the initial state change into 
>> new." - I assume it means "stable".
>>
>> Here's the request: Please clarify whether it fires for the final 
>> state change into "closed".
>>
>> .: Jan-Ivar :.
>>
>