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