Re: [MMUSIC] Handling of unverified data and media

[Roman Shpount <[e-mail]>]

On Mon, Mar 13, 2017 at 2:37 PM, Jonathan Lennox <[e-mail]> wrote:

>
> On Mar 11, 2017, at 9:52 AM, Christer Holmberg <
> [e-mail]> wrote:
> Is this a theoretical issue?
>
> At least if you use ICE, you are going to receive the answer before you
> receive any media, as you are going to do the connectivity checks etc.
>
>
> No, even with ICE it’s possible for media or the DTLS handshake to outrace
> the answer.
>
> This is because ICE offering endpoints respond to connectivity checks
> before they receive an answer.  When the answerer receives this successful
> connectivity check response, it puts the relevant pair in the Valid list,
> and then (if it has the active role, as recommended) can legitimately
> initiate DTLS on this pair.
>
> If two ICE endpoints have a short RTT and clear connectivity between them,
> but a long RTT to their signaling server, this can happen quite easily.
>
> Also, in reality some implementations will not accept content before the
> answer arrives – no matter if DTLS is used or not – so the best thing is
> to, once the answer has been sent, just wait for a while before sending any
> content.
>
>
> Fortunately, DTLS has retransmissions, so this shouldn’t cause failure,
> just a brief setup delay.
>
>
I think what specification says right now is that DTLS ClientHello should
be processed before answer arrives (
https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-21#section-5.2 ). I
think this clearly means DTLS handshake should complete. What should happen
with data received after DTLS handshake before fingerprint arrives is a
different issue.

Without processing DTLS handshake before signaling answer, end point
effectively slows down the connection setup by 5 sec (DTLS re transmit
timer). In practice this is enough for substantial number of calls being
hanged up by the caller or called party saying that call ended up in dead
air.

Regards,
_____________
Roman Shpount