Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

[Paul Kyzivat <[e-mail]>]

On 3/3/16 6:23 PM, Roman Shpount wrote:

>     Assuming you are comfortable with the above, I think the indicator
>     we want is some sort of “connection-id” parameter, either as a
>     standalone value or as a value which is unique in association with
>     the fingerprint. This seems cleaner than having a “new” versus
>     “reuse” token. The semantics would be that if you see a new
>     identifier that means you need to form a new association but that
>     multiple replays of the same identifier mean that you reuse the same
>     association (i.e., do not DTLS reconnect).
>
>
>     This resolves the idempotency concern that present with the existing
>     proposal, and also makes backwards compatibility simpler; a change
>     in either a=fingerprint or a=dtls-connection-id will trigger a new
>     DTLS connection.
>
>
> I have actually proposed this very thing (dtls-association-id instead of
> dtls-connection), but people on the list found this to be too complex.
> This has an additional benefit of handling some of the 3pcc use cases
> when in response to empty INVITE it is unknown if generated offer will
> be used in the same session or in the new one. dtls-association-id
> resolves this nicely, but we settled for a simpler requirement to always
> respond with a=dtls-connection=new in response to empty INVITE.
>
> The question is does group feels strongly about changes to
> (dtls-association-id from dtls-connection at this late stage, since this
> will require a major rewrite.

I had discomfort with connection=new/existing back when it first came up 
with TCP, exactly because it isn't idempotent. I don't recall why I lost 
that battle.

But now that is water over the dam. So I think it takes a stronger 
argument for why to adopt a different pattern now for something so 
similar. If the SDP implementation already has to deal with this for 
a=connection, then why is it a problem to also do so for dtls-connection?

	Thanks,
	Paul