- From: Eric Rescorla <ekr@rtfm.com>
- Date: Mon, 18 Jun 2012 16:57:17 -0700
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- Cc: Justin Uberti <juberti@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
WFM On Mon, Jun 18, 2012 at 11:55 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote: > > 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 23:58:25 UTC