Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?

[Flemming Andreasen <[e-mail]>]

Can we get some specific text proposals from the people that seem to 
care about what we end up with here ?

Thanks

-- Flemming (as MMUSIC co-chair)


On 6/5/17 12:58 PM, Roman Shpount wrote:
> On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     > On May 31, 2017, at 4:51 PM, Roman Shpount <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     > 1. Starting DTLS handshake until the corresponded answer is
>     received is NOT RECOMMENDED since it can result in unauthenticated
>     media. If unauthenticated media is played to the end user, in
>     cases such as early media in SIP calls, this should be indicated
>     to the end user.
>
>     No. Doing the handshake as quickly as possible is recommend - it's
>     what you do with the media before you know who you are talking to
>     that is the issue you are concerned with. And knowing who you are
>     talking often involves much more than checking the fingerprint. So
>     I don't agree this is not recommended.
>
>
> There are also implementation issues with getting media and not 
> playing it. End point will still need to either buffer or somehow 
> process the received packets so that playback can be started when the 
> answer is received. If handshake is delayed until answer is received, 
> none of this is an issue, so implementation is simpler.
>
> More importantly, I do not think new systems should be built without 
> ICE. I understand there are legacy implementations which use symmetric 
> UDP for media. In such cases it is allowed to complete handshake. Such 
> solutions are legacy and building new systems like this are not 
> recommended. It is recommended that new systems should implement full 
> ICE, consent to send, and do not complete DTLS handshake before an 
> answer SDP is received.
>
> Regards,
> _____________
> Roman Shpount