Re: [MMUSIC] Handling of unverified data and media

Roman Shpount <roman@telurix.com> Mon, 13 March 2017 18:46 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB41298A3 for <mmusic@ietfa.amsl.com>; Mon, 13 Mar 2017 11:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkdjg_CiGj1q for <mmusic@ietfa.amsl.com>; Mon, 13 Mar 2017 11:46:58 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDEE129500 for <mmusic@ietf.org>; Mon, 13 Mar 2017 11:46:58 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id 77so67182029pgc.1 for <mmusic@ietf.org>; Mon, 13 Mar 2017 11:46:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RbnR5hsaei2OLS+Mtz/AouqE0KjLpaBanxmV4rcimq0=; b=PkAtS3K+UfdtJs2YHIXlRlptcpG8Y3PPwM1VnGC7t/eZiBQVZ4KMprsqEAx3/s/rgB RQNOsjP7PKQNso6L7Wo6/z7i2iaFTaQ1bPV7gbx95Lyk5/6+VoKgttQzAL01wr83Q4qW ZdFH6tnT5lAXo+0mpOggp0CgUcjRQZdwDPLgOWDR79+abNU4DNS2hO7HabuBoq6B1rDr Zm1KS2qHivYzJ7/DISxjTjBXOM56YIrFHcMvx2TJmMcmq1dYRgutlivfjPHe2c2WE5wL TZkvM2ZC7LftmLB/JqWhO1i9bt43cHa0WkTegEDY1evlRHR03mygRt4lgGbc0CfOKWWo 9MMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RbnR5hsaei2OLS+Mtz/AouqE0KjLpaBanxmV4rcimq0=; b=gGTyjAhQWdvp4vQFAa00wJQpQplJkZsKEDILXsoJJ5QNhmy81R+YbmjrOk1a/OiARa G8WqqDsvnQ6S14QPtmYjGbt6cnPJwrxsY+vj+ymN+DzaahkdP7KvVpsiO3GtPk1ty+/m hGdofBk++IUtgV4MxoiVQGHCSIufJ0V2qMZnMnMia7d9Thf8BXNmZMsAnhdLOTyQU3fa mCkc1tM49crkpxu3E/eeI26lXLe5tnrGq4BKMZgYsA/e3p49l+QhQQdb0yKvn6RJtr+T 3bxjetoqwmz7u9EQlOPdbhssNvGJah1KJWbLycmlfOYzMDd20H8aRtFqnY03FdTQ/oax kutA==
X-Gm-Message-State: AMke39mAG4hq6OVOrmoMc3GY4BUJKAJiGo+Q7i5PEKg7vtlygS7dF69laiZDXXpt2LOInA==
X-Received: by 10.84.137.106 with SMTP id 97mr49431430plm.68.1489430817512; Mon, 13 Mar 2017 11:46:57 -0700 (PDT)
Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com. [74.125.83.46]) by smtp.gmail.com with ESMTPSA id y67sm34002449pfa.96.2017.03.13.11.46.56 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 11:46:56 -0700 (PDT)
Received: by mail-pg0-f46.google.com with SMTP id g2so50042810pge.3 for <mmusic@ietf.org>; Mon, 13 Mar 2017 11:46:56 -0700 (PDT)
X-Received: by 10.98.217.140 with SMTP id b12mr39833117pfl.136.1489430816253; Mon, 13 Mar 2017 11:46:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.161.144 with HTTP; Mon, 13 Mar 2017 11:46:55 -0700 (PDT)
In-Reply-To: <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com>
References: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com> <CABkgnnUc-XsYivUzSs6W4it_Krykr-reJMDJXqKf5FvGw_NBPg@mail.gmail.com> <CAD5OKxvXTsTPaKFNdwS6tPBTAksD=jgiAFGuGMgbepOtBoFT+Q@mail.gmail.com> <CABcZeBO9MP0fqg=ubpgU8+3L9koB5grCyp-O8hS9Pis942-rhA@mail.gmail.com> <CAOW+2due+uNyWn-3GQnpXrR-L55XVZSXXRmC0E9-5BSGKynUYA@mail.gmail.com> <CABcZeBPr4OjUBSUdS3wWmUuRJh7XmgxfVaY1F15mjMAqjbTZRg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 13 Mar 2017 14:46:55 -0400
X-Gmail-Original-Message-ID: <CAD5OKxtr36gir0E+1mLmCzYe4Sn7EapiL3uK9a8PHD1veqrg6g@mail.gmail.com>
Message-ID: <CAD5OKxtr36gir0E+1mLmCzYe4Sn7EapiL3uK9a8PHD1veqrg6g@mail.gmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: multipart/alternative; boundary=94eb2c124ab8b871d9054aa1222f
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/3TSSx70rC0B0phQYys73KjPD2VM>
Cc: Flemming Andreasen <fandreas@cisco.com>, Harald Alvestrand <hta@google.com>, mmusic <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Handling of unverified data and media
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 18:46:59 -0000

On Mon, Mar 13, 2017 at 2:37 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

>
> On Mar 11, 2017, at 9:52 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> 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