RE: Our simple PeerConnection example with Futures/Promises

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().

/Adam

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