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
Received on Wednesday, 3 May 2017 20:00:41 UTC