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

[Paul Kyzivat <[e-mail]>]

On 3/3/16 7:31 PM, Eric Rescorla wrote:
>
>
> On Thu, Mar 3, 2016 at 4:12 PM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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?
>
>
> How many people actually get a=connection right?

I don't know. But it should be pretty obvious when they get it wrong. 
And they have had a long time to get the bugs worked out of their code.

	Thanks,
	Paul