- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 15 May 2014 09:23:24 +0000
- To: tim panton <thp@westhawk.co.uk>, Martin Thomson <martin.thomson@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2014-05-15 10:18, tim panton wrote: > > On 15 May 2014, at 06:21, Martin Thomson <martin.thomson@gmail.com> wrote: > >> This is probably best handled in a room, but here goes. >> >> A has isolated streams because it thinks it's making a "private" call. You mean "private" in the sense that B's app should not be able to e.g. record (assuming B uses a browser). >> (Scare quotes intentional.) >> >> B has regular streams. >> >> A and B try to establish a call. Nothing in the signaling they are >> using (SDP, woo!) indicates that they are screwed. The browser runs >> the O/A exchange and it seems OK, until the DTLS session blows up. >> >> Do we want a signal in SDP for this state? I think that it would be >> nice. We can put a wee attributey thing on the a=identity line. >> >> Sorry, scratch that, we can request that the RTCWEB working group >> consider this as a new requirement on their signaling work. > > I think you are assuming that the only signalling between A and B is the SDP. > I’d imagine that in 99.99% of usages they will be visiting the same website > ‘confessional.com’ so both ends have javascript that requires the isolated taint. > > You only have a problem if a confessional.com user is somehow able to > connect to ‘theJeremyKileShowLive.com’ and accidentally broadcast their > ‘private confession’. For this to happen confessional.com and theJeremyKileShowLive.com > would have to agree to exchange signalling, but not bother to discuss their respective > business models, which I think is unlikely. > > A failure to connect is a perfectly satisfactory outcome. I agree. > > There is a question as to how we indicate DTLS setup failures, but isn’t that covered elsewhere? > > T. > > > >> > > >
Received on Thursday, 15 May 2014 09:23:48 UTC