Re: [webrtc-pc] strawman text to show how unverified media would work

At the step 3, WebRTC end point should not send Server Hello on this
candidate pair until it sends its own consent check on this pair. WebRTC
end point cannot send this check until new remote ice-pwd is received in
the final answer. Because of this second DTLS association is not
established until the final answer is received.

Am I missing something here?

_____________
Roman Shpount

On Tue, Apr 4, 2017 at 8:36 PM, Taylor Brandstetter <
notifications@github.com> wrote:

> 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 <https://github.com/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 rtcweb-wg/jsep#600
> <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 <https://github.com/juberti> said
> "implementations should be allowed to only handle one remote username at a
> time", which seemed reasonable to me.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291691251>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AEh5Sv8brQF1ghxdRHuMlrI2_VQ3YIJfks5rsuHwgaJpZM4L-hgv>
> .
>


-- 
GitHub Notification of comment by rshpount
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291707966 using your GitHub account

Received on Wednesday, 5 April 2017 01:43:57 UTC