Re: [MMUSIC] New Liaison Statement, "W3C WEBRTC WG to IETF MMUSIC WG"

Flemming Andreasen <> Fri, 21 April 2017 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E03D9124234 for <>; Fri, 21 Apr 2017 05:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i_RV1li0JOsA for <>; Fri, 21 Apr 2017 05:44:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0A58120454 for <>; Fri, 21 Apr 2017 05:44:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4036; q=dns/txt; s=iport; t=1492778649; x=1493988249; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5fvSf1IPQFrDxSdRHc94/8PJJveNOKr7Rlx7dkUGxjA=; b=LR4swXuGUwq+DfWgfsQ3gygWdqLFQtae7Kjv7BKrgqIlNwuU3eb1/gxf Atbaz1UgPjZMypuJcAPK09EAu9MGj+dNBi+V/ir+L9D4zb4pTMCzPmIY8 NBLFb48dv+daWJM+wowT7jT16Lqf2jEHSQeU+nMfpcHRPallvMzjvob4o k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.37,229,1488844800"; d="scan'208";a="235729033"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 12:44:08 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v3LCi6tb006943; Fri, 21 Apr 2017 12:44:07 GMT
To: Bo Burman <>
References: <>
Cc: Adam Roach <>, Ben Campbell <>,, Alexey Melnikov <>,, Multiparty Multimedia Session Control Discussion List <>,
From: Flemming Andreasen <>
Message-ID: <>
Date: Fri, 21 Apr 2017 08:44:06 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [MMUSIC] New Liaison Statement, "W3C WEBRTC WG to IETF MMUSIC WG"
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Apr 2017 12:44:12 -0000

Greetings MMUSIC.

The issue raised below has been discussed on the MMUSIC mailing (see 
thread starting at and 
the recent MMUSIC meeting at IETF 98 (Chicago). A summary discussion has 
been provided at as well.

Based on the above, we suggest to answer the liaison statement as follows:

Thank you for raising the question regarding playout of unverified media 
to the MMUSIC WG. We have looked further into the issue raised and we 
would like to request a clarification of the exact sequence of events 
that WEBRTC believes can lead to this. In particular, we ask you to 
please show either
(a) how ICE can complete prior to DTLS fingerprint exchange, or
(b) how media can be received prior to ICE completing

It is currently unclear to us how either of these situations can arise 
in which case we do not believe the issue raised would apply to WebRTC.

For further background information, please refer to:

Please let the chairs know (before April 28) if you have any comments.


-- Flemming

On 4/3/17 11:30 AM, Liaison Statement Management Tool wrote:
> Submission Date: 2017-04-03
> URL of the IETF Web page:
> Please reply by 2017-04-16
> From: Bernard Aboba <>
> To: Flemming Andreasen <>,Bo Burman <>
> Cc: Adam Roach <>,Flemming Andreasen <>,Ben Campbell <>,Bo Burman <>,Alexey Melnikov <>,Multiparty Multimedia Session Control Discussion List <>
> Response Contacts:,,
> Technical Contacts:
> Purpose: For action
> Body: Colleagues:
> In the W3C WEBRTC WG, an issue has been submitted relating to playout of unverified media:
> It has been suggested that if the browser is configured to do so, that playout be allowed for a limited period
> (e.g. 5 seconds) prior to fingerprint verification:
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following text, carried over from RFC 4572:
> Note that when the offer/answer model is being used, it is possible
> for a media connection to outrace the answer back to the offerer.
> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
> role, it MUST (as specified in RFC 4145 [7]) begin listening for an
> incoming connection as soon as it sends its offer. However, it MUST
> NOT assume that the data transmitted over the TLS connection is valid
> until it has received a matching fingerprint in an SDP answer. If
> the fingerprint, once it arrives, does not match the client's
> certificate, the server endpoint MUST terminate the media connection
> with a bad_certificate error, as stated in the previous paragraph.
> Given the outstanding issue relating to handling of unverified media, the Chairs of the W3C WEBRTC WG
> would like to request clarification from the IETF MMUSIC WG as to the meaning of the "MUST NOT" in the
> above paragraph. In particular, what is it permitted for a WebRTC implementation to do with received data prior
> to verification? For example:
> 1. May data received over the data channel be provided to the web application prior to verification?
> 2. May received media be played out prior to verification?
> Attachments:
>      webrtc-liason-to-mmusic copy.pdf
> .