Suggested resolution of Issue 849: Specify an AllowUnverifiedMedia RTCConfiguration property

At the March 1, 2017 virtual interim, the WEBRTC WG discussed Issue 849<https://github.com/w3c/webrtc-pc/issues/849> and PR 1026<https://github.com/w3c/webrtc-pc/pull/1026> and Peter and Cullen were given the task of producing "more exact info on the offers and answers": https://www.w3.org/2017/03/01-webrtc-minutes

Since then, we have had considerable discussion on Github relating to PR 1026<https://github.com/w3c/webrtc-pc/pull/1026> , as well as related discussion on the IETF MMUSIC WG mailing list and at the IETF 98 MMUSIC WG meeting.

Over time, the focus of the discussion has narrowed to whether it is possible for unverified media to arise within the WebRTC 1.0 API.

The MMUSIC WG is now in the process of drafting a response to the W3C WEBRTC WG liaison statement<https://datatracker.ietf.org/liaison/1511/> :
https://mailarchive.ietf.org/arch/msg/mmusic/TcyynbwyBsmJhE9eLac-gt33wtQ

In this draft liaison response, the IETF MMUSIC WG indicates that they "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


  1.  How ICE can complete prior to DTLS fingerprint exchange, or
  2.  How media can be received prior to ICE completing"

Looking over the discussion of PR 1026<https://github.com/w3c/webrtc-pc/pull/1026> , multiple scenarios are investigated, but in the end, it appears that in each scenario the above conditions cannot be met.

Given the extensive discussion that has taken place, and the inability to come up with a sequence of events, I would like to propose that we close Issue 849.

Thoughts?