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

Re: asynchrony for addStream w/ error/success callbacks

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Fri, 10 Jan 2014 12:04:45 -0500
Message-ID: <52D0282D.7020307@mozilla.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 1/10/14 11:37 AM, Eric Rescorla wrote:
> On Fri, Jan 10, 2014 at 8:28 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> On 1/10/14 4:13 AM, Stefan HÃ¥kansson LK wrote:
>>> On 2014-01-10 02:39, Martin Thomson wrote:
>>>> Since we're required to enqueue all mutation operations on
>>>> RTCPeerConnection, I'm surprised that addStream, which has an
>>>> interdependency on createOffer/createAnswer, is synchronous.  It's not
>>>> in Firefox, which means that it's not possible to report errors
>>>> effectively.
>>> I'm not sure what errors there could be. To me addStream just adds a
>>> MediaStream to the "local stream set"; that "local stream set" is what
>>> is considered at next createOffer/Answer.
>>>
>>> Likewise I'm not sure why it would have to be asynchronous. The content
>>> of the "local stream set" will only matter  at createOffer/Answer, and I
>>> think there should be a synchronous part of those operations (they are
>>> underspecified currently) which says something like "let xxx be this
>>> RTCPeerConnection Object's local stream set; queue a task to perform the
>>> following steps; ...." - modeled from setLocal/Remote.
>>>
>>> I may be wrong...
>>>
>>>> I'd like to suggest that we consider making addStream and removeStream
>>>> asynchronous like everything else.
>>>>
>>>> Also, I looked, but I can't see a concrete use for the constraints on
>>>> addStream.  The algorithm forgets to even mention these.
>>> I agree to this.
>>
>> +1. Removing the open-ended settings argument (MediaConstraints) means
>> addStream cannot fail and does not need callbacks.
> Why do you think it can't fail? Say I have a single hardware video encoder
> and the programmer adds a second video stream. I'm not going to be
> able to make a suitable offer.
>
> I suppose you could argue that then I get a failure when I call "CreateOffer",
> but that's a fairly odd notion of where failures should be reported, since
> it leaves me in an almost unrecoverable state if I want to make any other
> change to the PC.

Good point about it being odd, tough I disagree it would be 
unrecoverable, as addStream would presumably push streams to a temporary 
list that createOffer discards (or prunes) if it fails.

Should addStream(a), addStream(b), removeStream(a), createOffer() work? 
That would not be possible unless the validation was deferred (along 
with the rest of the actions) to createOffer.

As I interpret the negotiationneeded event here, I think 
addStream/removeStream are request-builders for createOffer.

> -Ekr

.: Jan-Ivar :.
Received on Friday, 10 January 2014 17:05:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC