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

On Wed, May 3, 2017 at 4:09 AM, T H Panton <thp@westhawk.co.uk> 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.
>

This case seems to be legitimate but extremely unlikely.


> As Roman says, "prohibit to start DTLS handshake until the answer is
> received" will cover that unlikely case nicely.
>
>
Do you agree with me that it is a good idea to postpone DTLS handshake
until answer is received?

I see no benefit in allowing DTLS handshake to proceed before the answer is
received by the end point, but I do see a lot of potential problems. As I
have mentioned before the main motivation for doing this was to convert
unusual call scenarios to the most common behavior and to avoid unverified
media and handshake in the process. I think this would make the whole
negotiation process easier to test and will prevent unexpected negotiation
flows.

Regards,
_____________
Roman Shpount