W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2014

RE: Panic between createOffer() and setLocalDescription()

From: <piranna@gmail.com>
Date: Wed, 19 Feb 2014 15:09:14 +0100
Message-ID: <CAKfGGh1n76=zYYkeGpzsDFrBZsVaQabjFSnH0XnW4vgaz4Jdcg@mail.gmail.com>
To: "Matthew Kaufman, (SKYPE)" <matthew.kaufman@skype.net>
Cc: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-webrtc <public-webrtc@w3.org>, Iñaki Baz Castillo <ibc@aliax.net>
I don't think so, in fact I believe it fixes it: you are creating an offer
description that wants to send to the other peer. Why you would need to set
it again on the same object? The only valid use case I see here it's if you
need to cusyomize it... I believe this way it helps to improve the
principle of least surprise, specially for WebRTC new comers.

Send from my Samsung Galaxy Note II
El 19/02/2014 15:02, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>

>  I believe what you suggest would violate the principle of least surprise.
> Matthew Kaufman
> *From:* piranna@gmail.com [mailto:piranna@gmail.com]
> *Sent:* Wednesday, February 19, 2014 1:06 AM
> *To:* Iñaki Baz Castillo
> *Cc:* public-webrtc; Stefan Håkansson LK; Christer Holmberg; Silvia
> Pfeiffer
> *Subject:* Re: Panic between createOffer() and setLocalDescription()
> > - 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 modificatio
Received on Wednesday, 19 February 2014 14:09:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:54 UTC