Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp

[Christer Holmberg <[e-mail]>]

Hi,

I am also not sure whether I would like to mandate procedures.

We COULD say that the offerer MUST NOT process the ClientHello before it
has received the answer, but I am not sure we say more than that…

Regards,

Christer



On 27/04/17 09:29, "Martin Thomson" <[e-mail]> wrote:

>On 27 April 2017 at 15:48, Christer Holmberg
><[e-mail]> wrote:
>> Is that supported by DTLS? Shouldn¹t it be considered an error if you
>> receive a ClientHello that you shouldn¹t receive?
>
>DTLS can handle all sorts of abuse, but I think that Christer is right
>in that we shouldn't tolerate a ClientHello if the answer contains
>'passive'.
>
>The question as to whether we should mandate this is a tougher one.
>All the discussion about unauthenticated media and so forth has
>convinced me that the best we get here is an optimization.  I would
>prefer to keep any recommendations about how to optimize out of the
>specifications.
>
>DTLS will re-send the ClientHello.  The only risk here is that the
>DTLS client will give up before the answer arrives.  Frankly, that
>doesn't seem particularly likely unless the answerer has insane delays
>and glacial signaling.  I really don't want to cater to this to the
>extent of mandating special behaviour for handling this corner case.
>
>I'd be OK with a suggestion.  With ICE, it can't send the ServerHello
>until it has an ICE password, so the process stalls there.  An offerer
>could save a ClientHello and process it when it receives the answer.
>That saves some time.
>
>If we want to acknowledge the absence of ICE as well, we could say
>that it could allow the handshake to complete, but delay reporting
>success until it can validate the remote certificate.