Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?
From: Christer Holmberg <[email-masked]>
To: Roman Shpount <[email-masked]>, Paul Kyzivat <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 30 Sep 2015 07:38:42 +0000
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>

Hi,

The scope of the document is to define generic SDP offer/answer procedures for DTLS. That includes re-using/clarifying the existing procedures in DTLS-SRTP as much as possible, and make some technical changes (mainly related to how/if a change transport address information affects a DTLS association), and define an attribute that can be used to explicitly indicate whether to create a new DTLS association.

The intention is NOT to change the existing setup attribute, or do to anything else.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 30. syyskuuta 2015 1:28
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

On Tue, Sep 29, 2015 at 5:26 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
This proposal is good except that it is unclear how to deduce which
version of connection or setup attribute is supported by the remote end
point. Without such indication there is a high chance that remote end
point will not be able to correctly parse and process the connection or
setup attribute with transport suffix.

Can you clarify what situation you are concerned about?

As long as we are defining behavior for cases that aren't currently supported at all, then it is simply a matter of writing the specs the way we want them.

Are you concerned with backward compatibility with implementations in the wild?

I am concerned about existing implementations which are currently in the wild. There are plenty of implementations that do support "setup" attribute for DTLS (including all the WebRTC enabled browsers). If existing "setup" attribute would be extended to include the protocol suffix it will not be properly handled by current implementations. If setup attribute is used with protocol prefix, it is unclear if it will be correctly recognized by the remote party.

On the other hand we can definitely use protocol attribute syntax for the connection attribute for DTLS, since this behavior is not defined anywhere yet.

Also, please let me know if you need a more detailed explanation of dtls_ufrag option and its rational or if you simply need more time to get it sorted out.

Regards,
_____________
Roman Shpount