Re: Panic between createOffer() and setLocalDescription()

On 02/19/2014 10:05 AM, piranna@gmail.com wrote:
>
> > - It forces the developer to retrieve a SDP from the PeerConnection
> (via createOffer) and then to pass it back again to the same
> PeerConnection (via setLocalDescription).
> >
> That's the thing I find most annoying, that it's the same
> PeerConnection object. Wouldn't it be possible that when calling to
> createOffer() and createAnswer() they call internally to
> setLocalDescription(), so developers only need to call it explicitly
> if they need to modify the SDP string? This will make easier the usage
> of vast mayority of use cases, and also it is a backwards compatible
> modification...
>
To my mind, once we have the necessary controls in place for specifying
the properties we want out of CreateOffer, the main reason the JS would
have for not calling SetLocalDescription is that it is not happy with
the result of calling CreateOffer.

I'm not sure that's a compelling reason to separate the two, but it's a
possible reason, even in the absence of SDP modification.

The separation also allows some timing scenarios that would otherwise be
impossible (such as sending the SDP blob off to another entity that did
the actual protocol negotiation, and only installing the local
description with SetLocalDescription after negotiation was complete) -
but we decided long ago that in this case, there was no guarantee that
resources continued to be available, so this is a case that we might
consider unsupported.

Again, I'm not sure the reason is compelling. But then again, I don't
see a compelling reason to change either.


-- 
Surveillance is pervasive. Go Dark.

Received on Thursday, 20 February 2014 00:47:42 UTC