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

On 5/3/13 6:03 PM, Martin Thomson wrote:
> 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.

I guess a lot of these details are still TBD. If we (or rather the IETF) 
goes with Plan B, then there is a three way handshake, and the initial 
offer merely indicates the media types wanted in the session if I get it 
right. Plan A is another story.

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

I agree on the first point! For the second, it seems the approach in 
Plan B sort of removes this problem, but at the cost of 1/2 RTT 
signaling in extra delay (OTOH the answerer does not have to wait for 
gUM any more before carrying on with the signaling).

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

Precisely, but my point was rather that we should have a view on what 
API functionality we need:

* Do we need APIs for rejecting streams/tracks that the other end-point 
wants to send? I'm not convinced, can't this be resolved in when 
developing the app?

* Do we need APIs that enable the app to handle incoming media that has 
not been signaled in any way? I guess the potential gain would be 
reduced audio clipping, but I have no idea how big a problem that is in 
practice.


Stefan
>
> --Martin
>

Received on Friday, 3 May 2013 18:00:29 UTC