- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Mon, 18 Jun 2012 18:55:40 +0000
- To: Justin Uberti <juberti@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Jun 15, 2012, at 12:02 PM, Justin Uberti wrote: > We recently changed createOffer/createAnswer to be async, since they may need to reach down into the media layer to get their information. Since setLocal/setRemoteDescription need to reach down to actually set the supplied descriptions, it seems like these operations will also need to report their success/failure asynchronously. > > Suggestion: Like createOffer/createAnswer, allow callbacks to be specified to indicate success/failure: > > e.g. > > void setLocalDescription (SessionDescription description, > optional voidCallback successCallback, > optional PeerConnectionErrorCallback failureCallback); > void setRemoteDescription (SessionDescription description, > optional voidCallback successCallback, > optional PeerConnectionErrorCallback failureCallback); > > successCallback would be invoked upon successful application of the description. failureCallback would be invoked if the description was a valid description, but could not be applied at the media layer. An exception would be thrown if the description was not valid (e.g. failed to parse). > > If failureCallback was invoked, the session's media state would be kept as it was before the call. (This may involve rollback, if the description was partially applied when the failure occurred; another option would be to simply make this a fatal callback). > > localDescription and remoteDescription would return the previous description until the new description was completely applied. > > > sounds fine to me
Received on Monday, 18 June 2012 18:56:10 UTC