Re: Question about sync / async for createOffer and createAnswer

On 10 May 2012 07:04, Cullen Jennings <fluffy@cisco.com> wrote:
> We working on the assumption that the thing returned by createOffer must "work" if passed to setLocalDesctiption - the time is needs to be "valid" for is at least until the browser user agent returns to stable state. So I think that matches what you are saying - it needs to work for bit, but not long.

So the browser needs to go touch a few things during the creation of
the offer, so we have...

pc.createOffer(offerCallback);

... time passes ...

function offerCallback(sdp) {
   pc.setLocalDescription(sdp);
}

...
The assumption is that setLocalDescription() works.  That is going to
be true a very large proportion of the times you do this.

Say however that you are doing H.264 and you need to grab exclusive
use of a DSP to do that.  When you call createOffer the browser
performs a quick check to see if the DSP is free.  It is, so the SDP
reflects that.  Later, you call setLocalDescription, which causes the
browser to actually grab the DSP.  It doesn't matter how fast you call
one then the other, you cannot guarantee that the DSP hasn't been
taken by another process on the machine.

Of course, you can be a little clever and actually grab the resources
when you do createOffer.  Then you have to be prepared for the
application to take the SDP and never come back with
setLocalDescription.  That means timers, which tends to lead to
surprises.

As long as browsers implement createOffer with the intent to have it
work in setLocalDescription, and given the likely probability of
failure, I'd be inclined to avoid cleverness and simply acknowledge
that setLocalDescription can fail if passed the output of createOffer.
 It's not a particularly onerous error case to handle, just recreate
the offer and try again.  Trivial applications can ignore the error in
the same way that they don't check for JSON.parse throwing an error.
Anyone writing a serious application with this is going to be munging
SDP, so they had better be prepared to handle an error or two.

--Martin

Received on Thursday, 10 May 2012 15:55:48 UTC