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

Re: Calling close() on a closed PeerConnection

From: <piranna@gmail.com>
Date: Wed, 22 Jan 2014 16:18:04 +0100
Message-ID: <CAKfGGh12+ZUe-iNNUq4uCymy92QSN=_8Cpj6PJrSLUxtLNqAcA@mail.gmail.com>
To: Adam Roach <abr@mozilla.com>
Cc: public-webrtc <public-webrtc@w3.org>
+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> 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
> +1 650 903 0800 x863
>
Received on Wednesday, 22 January 2014 15:18:32 UTC

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