W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: Calling close() on a closed PeerConnection

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 22 Jan 2014 17:05:04 +0100
Message-ID: <52DFEC30.7030205@ericsson.com>
To: "piranna@gmail.com" <piranna@gmail.com>, Adam Roach <abr@mozilla.com>
CC: public-webrtc <public-webrtc@w3.org>
Yes

I'll go ahead and make the change right now.

/Adam

On 2014-01-22 16:18, piranna@gmail.com wrote:
> +1000, I have had recently some head-bumping against a wall due to this
> issue, and me and my work colleages found this behaviour totally non-sense.
>
> Send from my Samsung Galaxy Note II
>
> El 22/01/2014 16:00, "Adam Roach" <abr@mozilla.com
> <mailto:abr@mozilla.com>> escribió:
>
>     I distinctly recall (and have verified with other participants)
>     having a conversation around the expected behavior when close() is
>     invoked on a closed connection. My recollection is that the outcome
>     of that conversation was that close() should be idempotent -- that
>     is, calling close() on a closed connection should be a no-op.
>
>     The currently published editors' version of the spec, however,
>     contains the following text:
>
>>     When the |close()| method is invoked, the user agent /MUST/ run
>>     the following steps:
>>
>>     1.
>>
>>         If the ||RTCPeerConnection|
>>         <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCPeerConnection>|
>>         object's |RTCPeerConnection| signalingState
>>         <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-signaling-state>
>>         is |closed|, throw an |InvalidStateError| exception.
>>
>
>     Based on the conversation we had, this needs to be changed to read:
>     "If the RTCPeerConnection object's RTCPeerConnection signalingState
>     is closed, abort these steps."
>
>
>     --
>     Adam Roach
>     Principal Platform Engineer
>     abr@mozilla.com <mailto:abr@mozilla.com>
>     +1 650 903 0800 x863 <tel:%2B1%20650%20903%200800%20x863>
>
Received on Wednesday, 22 January 2014 16:05:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC