W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2017

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

From: Roman Shpount <roman@telurix.com>
Date: Wed, 3 May 2017 16:00:04 -0400
Message-ID: <CAD5OKxtwU7gLRY2C7RVksMCb8tWx95ua_w6wbcL8+rLv3aE4bg@mail.gmail.com>
To: T H Panton <thp@westhawk.co.uk>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

Roman Shpount
Received on Wednesday, 3 May 2017 20:00:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:31 UTC