Re: Our simple PeerConnection example with Futures/Promises

On 2013-06-10 14:50, Jim Barnett wrote:
> 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.

A change like this should remove both addStream() and removeStream().

I'm thinking something like:

// include existing streams and add/remove listed ones
pc.createOffer({
     "streamsToAdd": [newStream],
     "streamsToRemove": [oldStream] },
     successCb, errorCb);

or

// list all streams (even previously negotiated; exclude to remove)
pc.createOffer({"streams": pc.getLocalStreams().concat(stream) },
     successCb, errorCb);

/Adam

>
> -----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 13:47:22 UTC