- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 28 Feb 2013 15:58:51 +0100
- To: Justin Uberti <juberti@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, Per Kjellander <perkj@google.com>, Mallinath Bareddy <mallinath@google.com>, Harald Alvestrand <hta@google.com>
I think we could start to edit this into the spec. I think the "null candidate behavior" is missing in the spec today and that will be good to have described. A minor comment below. On 2013-02-21 00:44, Justin Uberti wrote: > > 4. 4.3.2.2 <http://4.3.2.2>: setLocalDescription > The description for this function should indicate that it > triggers a signaling state change. It should also indicate that > an INVALID_STATE exception is triggered if the wrong > SessionDescription.type is supplied for the current state. > 5. 4.3.2.2 <http://4.3.2.2>: setRemoteDescription > The description for this function should indicate that it > triggers a signaling state change. It should also indicate that > an INVALID_STATE exception is triggered if the wrong > SessionDescription.type is supplied for the current state. We've used INVALID_STATE consistently when an operation/function is not permitted at the current state. In this case, the operation itself (to set a remote description) is OK, but it's the argument that's bad. It would be more consistent with the text in 4.6.1 and our other functions to throw INVALID_STATE if the PeerConnection is closed and use, e.g., INVALID_SESSION_DESCRIPTION if the argument is invalid. /Adam
Received on Thursday, 28 February 2013 14:59:18 UTC