Re: [MMUSIC] Handling of unverified data and media

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 11 March 2017 15:30 UTC

Return-Path: <christer.holmberg@ericsson.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 0910E12951E for <mmusic@ietfa.amsl.com>; Sat, 11 Mar 2017 07:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.319
X-Spam-Level:
X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QKafL-rx-6UW for <mmusic@ietfa.amsl.com>; Sat, 11 Mar 2017 07:30:31 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D852129484 for <mmusic@ietf.org>; Sat, 11 Mar 2017 07:30:31 -0800 (PST)
X-AuditID: c1b4fb25-e49bd98000004cad-8b-58c41815a0b6
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 2F.86.19629.51814C85; Sat, 11 Mar 2017 16:30:29 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Sat, 11 Mar 2017 16:30:28 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
Thread-Topic: [MMUSIC] Handling of unverified data and media
Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGPrxoAgAATT2D///B1AIAAEW+A
Date: Sat, 11 Mar 2017 15:30:25 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB06F0E@ESESSMB109.ericsson.se>
References: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com> <CABkgnnUc-XsYivUzSs6W4it_Krykr-reJMDJXqKf5FvGw_NBPg@mail.gmail.com> <CAD5OKxvXTsTPaKFNdwS6tPBTAksD=jgiAFGuGMgbepOtBoFT+Q@mail.gmail.com> <CALiegfmyKz4JUXBoX7LaRe7U_yE2-_pbBKXHp14zm4DRSYGZgA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4CB06EB1@ESESSMB109.ericsson.se> <CALiegfkfntWj56NEXhr_waogJtsw9oy_P0Jo331ba_WNzBGRSQ@mail.gmail.com>
In-Reply-To: <CALiegfkfntWj56NEXhr_waogJtsw9oy_P0Jo331ba_WNzBGRSQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB06F0EESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7k66oxJEIg3XT9CzeX9C1OHHjNLPF 9H02FlOXP2axmHFhKrMDq8e5hvfsHlN+b2T1WLCp1GPJkp9MHremFASwRnHZpKTmZJalFunb JXBlTP3KV3AttKJnz0m2BsYVwV2MnBwSAiYSM05PZeli5OIQEljHKHH47xooZzGjxKeLk9m6 GDk42AQsJLr/aYM0iAjYSPy7cIEdpIZZYBajxNYt3awgNcIC1hJX+sFMkJqVv2ohyt0kzl1+ zQ5iswioSvw42ARm8wr4Smyf3MIGsWoDs8Sr62cZQRKcAoESqyd2s4DYjAJiEt9PrWECsZkF xCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2EoSaw9vZ4Goz5d4dWwpG8QyQYmTM5+wTGAUmYVk 1CwkZbOQlM0CeoFZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspNNzLWSy3K TC4uzs/Ty0st2cQIjMODW36r7mC8/MbxEKMAB6MSD2/B/kMRQqyJZcWVuYcYJTiYlUR4PeYD hXhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamAsPSjRGen1 TLxJrKji2h+BeWs4Ju6ZdOrKUTuXdpnSQ9umyXTq7J5R317VtzeNaYVlt/0pZ+a6Uw+Nwkof 9sVK67a9iSsPiH73tuL0x2OFDMELD9grZqTdS3uTXjzvYPXZv8s5/DbZBvl+mTVnRdKHQ+yn 9uw+yeQ9S9Pip6/H41IGc56rBiVKLMUZiYZazEXFiQDTThcpvwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/V_aGrEmRLRcj3C7jhl6yCxRzeyM>
Cc: Flemming Andreasen <fandreas@cisco.com>, "hta@google.com" <hta@google.com>, "mmusic@ietf.org" <mmusic@ietf.org>
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: Sat, 11 Mar 2017 15:30:33 -0000

Hi,

>AFAIK you dont need a SDP aswer for that.

Perhaps not, but it will still take some time to do, so maybe the offerer will have received the answer once it’s done and it is possible to start sending any media?

Regards,

Christer


El 11/3/2017 16:24, "Christer Holmberg" <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> escribió:
Hi,

In case of a Data Channel, you also need to establish the SCTP association before you can send any content.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>] On Behalf Of Iñaki Baz Castillo
Sent: 11 March 2017 17:12
To: Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>
Cc: Flemming Andreasen <fandreas@cisco.com<mailto:fandreas@cisco.com>>; hta@google.com<mailto:hta@google.com>; mmusic WG <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: Re: [MMUSIC] Handling of unverified data and media

2017-03-10 23:47 GMT+01:00 Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>:
> My assumption always was that data is received, decoded and discarded
> until fingerprint is received and verified. This way DTLS handshake
> completes, key frames are decoded, but user is nor presented with any unverified media.

Just imagine an app (running in a computer with public IP) which sends the SDP offer to a server, DTLS handshake is done, and the server sends DataChannel messages to the browser *before* the browser receives the SDP answer.

Do you mean that such a DataChannel messages should be discarded? I consider that catastrophic as the server may not know whether the browser has yet received the answer or not. Apps should implement some kind of 3-way signaling handshake (send offer, receive answer, send
ACK) before the server sends any DataChannel message.


--
Iñaki Baz Castillo
<ibc@aliax.net<mailto:ibc@aliax.net>>

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic