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

[Justin Uberti <[e-mail]>]

On Thu, Mar 3, 2016 at 4:12 PM, Paul Kyzivat <[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?
>

I don't agree that the ship has sailed on this. If we unearth a compelling
reason (idempotency), we shouldn't be bound by decisions to a different
attribute made 10+ years ago.

Besides idempotency, the connection/instance id approach has the additional
benefit of simpler logic for old remote endpoints - if either the
fingerprint or id changes, make a new DTLS connection.