W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2013

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

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 3 May 2013 09:42:26 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C2C0B50@ESESSMB209.ericsson.se>
On 5/2/13 6:59 PM, Martin Thomson wrote:
> On 2 May 2013 00:18, Harald Alvestrand <harald@alvestrand.no> wrote:
>> On 05/01/2013 04:13 PM, Martin Thomson wrote:
>>> No discussion?
>>> With an already-established DTLS-SRTP connection the crypto doesn't
>>> block new inbound media.
>> Ah - you're talking about subsequent additions of media after the first
>> offer/answer, not the initial addition of media. I thought you were talking
>> abou the initial media case.
> Yes, I was.  In part.
> I can imagine cases where a=fingerprint isn't needed ahead of time
> (the callee fingerprint is in your contacts list).  Then you only need
> to worry about ICE, and nothing says that you can't have the answerer
> nominate and use peer-reflexive addresses.
> Oh wait, we're using SDP offer/answer.  Sorry, the WebRTC API doesn't
> permit those scenarios.

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.

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.


Received on Friday, 3 May 2013 09:42:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:43 UTC