Liaison statement

State Posted
Posted Date 2017-04-03
From Group W3C-WEBRTC
From Contact Bernard Aboba
To Group mmusic
To Contacts Flemming Andreasen
Bo Burman
CcAdam Roach
Flemming Andreasen
Ben Campbell
Bo Burman
Alexey Melnikov
Multiparty Multimedia Session Control Discussion List
Response Contact
Purpose For action
Deadline 2017-04-16 Action Taken
Attachments webrtc-liason-to-mmusic copy.pdf

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

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