- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 22 Jan 2014 17:05:04 +0100
- 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