RE: Panic between createOffer() and setLocalDescription()


> -----Original Message-----
> From: thomas.bruun@gmail.com [mailto:thomas.bruun@gmail.com] On
> Behalf Of Thomas Bruun
> Sent: Thursday, February 20, 2014 4:36 AM
> To: piranna@gmail.com
> Cc: Harald Alvestrand; public-webrtc
> Subject: Re: Panic between createOffer() and setLocalDescription()
> 
> On Thu, Feb 20, 2014 at 10:44 AM, piranna@gmail.com <piranna@gmail.com>
> wrote:
> > I'm not saying to remove setLocalDescription(), I'm only saying that
> > for most use cases is redundant to call to
> > createOffer()/createAnswer() and inmediately to setLocalDescription(),
> > so I'll change the spec to do the call implicitly and if some changes
> > are required, let the user to do the call explicitly, overwritting
> > this way the content of the local description with its custom one.
> > This will make easier to new comers what's the call flow:
> >
> > createOffer() -> send()
> > onmessage -> setRemoteDescription()
> > createAnswer() -> send()
> > onmessage -> setRemoteDescription()
> >
> > Honestly, if you need to call to setLocalDescription() with a modified
> > SDP, you are not in "WebRTC 101" anymore... Why complicate it?
> 
> Keep in mind that setLocalDescription() today doesn't just set a variable on
> the RTCPeerConnection object. For example, it starts ICE gathering. What
> you suggest assumes that the developer wishes to start this process when
> calling createOffer().
> 
> We have identified scenarios where we would want to do something with
> the sdp (either edit or inspect it), before we decide if we want to call
> setLocalDescription(). If setLocalDescription() is called implicitly, we need our
> code to hold of on relaying the offer and ICE candidates to the remote client
> in those scenarios.
> 

Even worse, there are cases where you need to edit the SDP *specifically* to adjust what ICE operations will ensue. I don't think it is acceptable for "createOffer()" to advance the state machine as "setLocalDescription()" currently does.

Also, "createOffer()" would no longer be the correct name for the API if it applied the description and started processing. (This is what I was referring to earlier with regard to "least surprise")

Matthew Kaufman

Received on Thursday, 20 February 2014 19:02:46 UTC