Re: Panic between createOffer() and setLocalDescription()

I think the problem with the trickle ICE will be solved by internally
setting the localDescription instead of that from the browser (which I
missed to add in the previous points).
In the case where sdpMangling is set to false, the flow will be like this.

-> createOffer/createAnswer(sdpMangling = false, other
arguments/constraints);
             This creates the offer, sets it as localDescription (which
invokes the further processing) and returns the SDP.

This may or may not contain candidates, which is just like existing case.
If candidates are present in the SDP then the process will be faster.
on receiving the new ICE candidates, ICE candidates should be added to
localDescription and onIceCandidate callBack will be invoked,
Based on the onIceCandidate callBack, application can get the new SDP by
calling localDescription.

For now I am adding sdpMangling as argument, later we can decide how and
where it should be passed once every one accepts this approach.

Thanks,
Kiran.





On Mon, Mar 10, 2014 at 1:17 PM, piranna@gmail.com <piranna@gmail.com>wrote:

> > Setting sdpMangling to false (which is case for majority of
> scenarios/apps) will speedup the process, because browser can start
> processing the sdp without waiting for setLocalDescription.
> >
> I agree with you in that's the way to go, but there's another issue:
> trickle ICE. Without the hability to disable it, the offer description on
> createOffer/createAnswer is fairly useless by don't having candidates. And
> yes, needing to wait for externally dispatched candidate events is
> counter-intuitive, after all this time dealing with WebRTC I still forget
> them when creating new code code from scratch. Trickle ICE should be an
> advanced functionality behind a flag (the same as your proposed sdpMangling
> flag) instead of a by default feature if we really want WebRTC to be easy
> to use by newcomers. I think this will greatly help to increase WebRTC
> adoption that releasing a 1.0 spec soon, and it's a thing that will not
> delay it beyond than one release more.
>
>