Re: Suggested resolution of Issue 849: Specify an AllowUnverifiedMedia RTCConfiguration property

On 5/3/2017 4:09 AM, T H Panton wrote:
> For what it is worth I've come up with a scenario where this can 
> happen, but I think it is unlikely.
>
> If you have
> 1) an un-ordered or lossy signalling transport (SIP over UDP or JSON 
> over an SCTP _unordered_ channel)
> 2) are using trickle-ice which
> 3) are sending a=candidates containing ufrag and password set
>
> Then you could (theoretically) have the situation where the candidate 
> (with ufrag/pass) arrives before the answer with the fingerprint.
>
> If the ICE consent and DTLS handshakes complete (2 x rtt) before that 
> delayed answer arrives, you could legitimately get
> media sent and received (2.5 rtt) before the fingerprint can be used 
> to verify the channel.
>
> In practice I think browsers wait for a RTCP exchange before sending 
> video, so that's >3rtts delay needed before you lose a keyframe.

I do not believe this is the case, though there would be some advantages 
to this IF the other side sprayed a bunch of RTCP at you at the start of 
a call.
We modified the webrtc.org code to support the early-sync mandated by 
the spec, which involves sending a (single) RTCP at the start - it 
wasn't there before.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam