Re: Suggested resolution of Issue 849: Specify an AllowUnverifiedMedia RTCConfiguration property

I'd be happy to join that call too please. 

T.

Sent from my iPod

> On 2 May 2017, at 23:46, Roman Shpount <roman@telurix.com> wrote:
> 
> Cullen,
> 
> Do you want to have call where you would walk me through this example? You seem to be the only one who understands it. Please contact me directly if you have time to discuss this.
> 
> We also are planning to update the dtls-sdp draft (https://github.com/cdh4u/draft-dtls-sdp/pull/31) which will prohibit to start DTLS handshake until the answer is received. This should prevent unverified media from ever occurring with DTLS, even if ICE and consent to send is not used.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
>> On Tue, May 2, 2017 at 5:15 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>> 
>> > On Apr 26, 2017, at 10:26 AM, Roman Shpount <roman@telurix.com> wrote:
>> >
>> > Cullen,
>> >
>> > Until we see the scenario where unverified media can be received by a full ICE end point which implements consent to send, there is general consensus that unverified media to WebRTC endpoint cannot happen.
>> >
>> > Regards,
>> 
>> The example I gave was fully consistent with everything WebRTC requires including consent.
>> 
>> >
>> > _____________
>> > Roman Shpount
>> >
>> > On Wed, Apr 26, 2017 at 11:45 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>> >
>> > I did explain the issue where this can happen in the PR. There may not be agreement that the case can not happen but there is also not agreement that it can not. So until someone explains to my why this can not happen, I think it should remain open. I'm not really following the mmusic conversation and have no idea why they are sending a liaison like that.
>> >
>> >
>> > > On Apr 25, 2017, at 11:52 AM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>> > >
>> > > At the March 1, 2017 virtual interim, the WEBRTC WG discussed Issue 849 and PR 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 , 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://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
>> > >
>> > >       • How ICE can complete prior to DTLS fingerprint exchange, or
>> > >       • How media can be received prior to ICE completing”
>> > >
>> > > Looking over the discussion of PR 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?
>> >
>> >
>