W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

RE: Our simple PeerConnection example with Futures/Promises

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Mon, 10 Jun 2013 12:50:35 +0000
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
CC: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D28104477C@GENSJZMBX02.msg.int.genesyslab.com>
If we use the 'streamsToAdd' form, we don't need removeStream, which might be simpler.  It seems a  bit odd to have removeStream but no addStream.

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Monday, June 10, 2013 8:44 AM
To: Jim Barnett
Cc: Jan-Ivar Bruaroey; public-webrtc@w3.org
Subject: Re: Our simple PeerConnection example with Futures/Promises

On 2013-06-10 14:23, Jim Barnett wrote:
> If we remove addStream(), what happens when renegotiation is needed?
> The streams will have already been added as part of the original 
> offer/answer.  Should the developer pass them in again?  If we say 
> that, then each offer or answer implicitly clears out any Streams that 
> are in the PC.  Alternatively, we could say that the offer/answer uses 
> any streams that are already in the PC, plus any that  are passed to 
> the CreateOffer/Answer call.

Yes, we need to be very clear about this.

In the short example I provided, I used the dictionary key "streamsToAdd" to try to imply that these are the *new streams* that must be added to the offer. We could go the other way and require each offer to include all the existing streams as well. A natural way to do that would be to get a sequence of all currently local/sent streams with getLocalStreams(), add or remove streams from that structure and feed it to createOffer().


Received on Monday, 10 June 2013 12:51:01 UTC

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