- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 22 Jan 2014 17:14:05 +0100
- To: "piranna@gmail.com" <piranna@gmail.com>, Adam Roach <abr@mozilla.com>
- CC: public-webrtc <public-webrtc@w3.org>
Cullen beat me to it. :) /Adam On 2014-01-22 17:05, Adam Bergkvist wrote: > 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:14:29 UTC