That reasoning makes sense to me. I also think that this should result in an async callback rather than an exception, to be consistent with similar handling of bad session descriptions (e.g. invalid SDP). Let me know when you've done the edits and I can take another look. Thanks! On Thu, Feb 28, 2013 at 6:58 AM, Adam Bergkvist <adam.bergkvist@ericsson.com > wrote: > 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 19:29:58 UTC