- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Apr 2017 00:35:59 +0000
- To: public-webrtc-logs@w3.org
I think I understand Cullen's use case. I just didn't consider there being a second DTLS handshake in the picture. Let me break down the important steps that occur here (if I understand correctly): 1. Offer and provisional answer exchanged between browser and gateway. 2. DTLS handshake completes using the fingerprint in the provisional answer. 3. Before receiving a final answer, the WebRTC endpoint receives a Client Hello on a new candidate pair with a new ufrag (addressing @rshpount's point about needing a new 5-tuple). 4. The WebRTC endpoint completes this second handshake, maintaining the two DTLS associations in parallel? 5. At this point, early media can be received on the second DTLS association. 6. Eventually the answer is received, the first DTLS association is discarded and the fingerprint of the second one can be verified. However, this goes into extreme pranswer edge case territory, which JSEP doesn't currently define. This is what a really robust implementation _might_ do, but I don't see anything preventing it from just ignoring the second Client Hello until it gets the final answer and discards the first DTLS association. A very related issue is https://github.com/rtcweb-wg/jsep/issues/600 (scroll down to find stuff about maintaining N DTLS associations in parallel...). In the PR I wrote to address this issue, I didn't end up adding any requirements related to early media, since @juberti said "implementations should be allowed to only handle one remote username at a time", which seemed reasonable to me. -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291691251 using your GitHub account
Received on Wednesday, 5 April 2017 00:36:06 UTC