- From: adamroach via GitHub <sysbot+gh@w3.org>
- Date: Mon, 03 Apr 2017 16:21:44 +0000
- To: public-webrtc-logs@w3.org
The MMUSIC discussion seems, at the moment, to conclude that the only the situation under discussion can arise is: 1. When using ORTC rather than WebRTC -- which clearly requires no text in the WebRTC document, or 2. When an ICE lite endpoint is in use, the ICE lite endpoint itself (but not the full ICE endpoint it is talking to) can get early media. Since browsers cannot be ICE lite endpoints, this situation *also* requires no text in the WebRTC document. The only thing that I've seen mentioned is some interaction between PRANSWER and trickle ICE in which a fingerprint has been received by the offerer, but that fingerprint is incorrect. Leaving aside for a moment that this sounds like it goes beyond "unverified media" and clear into "indistinguishable from forged media", it's still not clear how this can happen. Minimally, I think the working group needs to understand the circumstances leading to such a situation (hence my request for a ladder diagram); and, ideally, such a situation should be clearly described in the text around unverified media. It does no good to give webdevs an affordance to control the behavior in this situation if they don't have any way to understand what the situation actually *is*. And if it's not obvious to *us*, then they have no hope whatsoever. -- GitHub Notification of comment by adamroach Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291194679 using your GitHub account
Received on Monday, 3 April 2017 16:21:50 UTC