Re: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 8/17/17 3:54 PM, Roman Shpount wrote:
> On Wed, Aug 16, 2017 at 7:06 PM, Adam Roach <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Section 5.4 says:
>
>        NOTE: A new DTLS association can be established based on changes in
>        either an SDP offer or answer.  When communicating with legacy
>        endpoints, an offerer can receive an answer that includes the same
>        fingerprint set and setup role.  A new DTLS association MUST
>     still be
>        established if such an answer was received as a response to an
>     offer
>        which requested the establishment of a new DTLS association.
>
>     Unless I've misunderstood something important, this isn't going to
>     work with
>     legacy implementations, unless you also specify that an "offer
>     which requested
>     the establishment of a new DTLS association" must also change
>     something else
>     that the legacy answerer will recognize as requiring a new DTLS
>     association.
>     For example, if I send a re-offer with a changed tls-id but the same
>     fingerprint, setup, and transport, the far end will have no reason
>     to think it
>     needs to establish a new DTLS association. So I'll sit there
>     waiting for a new
>     association to be established, and the remote side will never send
>     one.
>
>     This doesn't seem backwards-compatible. At the very least, more
>     text needs to
>     be added explaining how this is intended to work.
>
>
> The intention was to specify that an offering party sends an offer 
> with new value of tls-id, it can get back an answer without tls-id, 
> unchanged remote fingerprint values and setup role . In this case new 
> DTLS association MUST be established.
>
> As you have correctly mentioned, tls-id can be changed with no changes 
> in fingerprints, but current specification requires changing the 
> transport parameters whenever tls-id is changed. The transport 
> parameter change should cause new DTLS association to be established, 
> even if remote is a legacy end point. In this case, even if remote 
> legacy end point responds with existing fingerprints, transport 
> parameters and setup role, it is safer to assume that new DTLS 
> association should be established.

Ah, okay. This makes sense. Perhaps add a bit of text to that effect 
(e.g., "A new DTLS will still be established if such an answer was 
received as a response to an offer which requested the establishment of 
a new DTLS association, as the transport parameters will have been 
changed in the offer.")

Clearing my DISCUSS.

> JSEP needs to be adjusted in this case. Specification does not work if 
> tls-id is reflected in the answer. Different tls-id in the answer are 
> used to disambiguate multiple DTLS associations in case of forking.

That was my assumption too.

/a