Re: [Bug 21877] API is unable to handle inbound streams prior to arrival of answer

On 3 May 2013 02:42, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> Perhaps we should take one step back. I've seen bugs filed on that we
> miss the possibility to reject incoming MediaStreams and
> MediaStreamTracks (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20809)
> and this bug saying that it should be possible to handle inbound streams
> prior to arrival of a signaling message describing those streams.

On one level, I think I agree.  The application needs to be informed
of inbound streams, and needs to be able to make choices about those
streams.

But this might be a little too meta-level to be of immediate use.  See below.

> It seems difficult to handle both things (at least at the same time).
> Perhaps we should first define what functionality we need, and then how
> we solve it.

I'm not sure that's entirely the problem.

When you make an offer, you explicitly (or implicitly?) grant
permission to receive inbound streams on the terms of the offer.  That
means that rejecting them in that case would be bipolar.  So for the
offerer, the problem is receipt of media prior to knowing everything
there is to know about that media.

The answerer has the other half of the problem.  They receive an
offer, they need the power to learn what might be coming and reject
those streams it doesn't want.

Plan A/B approaches need to be resolved before the answerer reject
issue can be addressed.  I don't think that the offerer problem (as
described by this bug) can be addressed with SDP mechanisms.

Note: both of these require that the IETF solve some problems.  What
they decide will need to be captured.

--Martin

Received on Friday, 3 May 2013 16:03:37 UTC