Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?

[Christer Holmberg <[e-mail]>]

Hi,

>>If I understand correctly, you seem to suggest that we allow the
>>handshake
>> to ³proceed² (see 1st paragraph of your reply), but not to ³complete².
>>If
>> so, which endpoint is responsible to make sure that it doesn¹t
>>³complete²?
>
>Whichever endpoint is unable to acquire the information it needs in
>order to determine that the handshake is good.

Ok, so in the use-case we’ve been discussing it would still be the offerer.

But, what about data received before the completion is received? You said
that you would be ok to allow received data to be saved, but not used.
However, I assume Cullen would not agree to that.

Also, if I understand the FEDEX use-case, not only would you have to be
able to receive media - if you are e.g., going to provide DTMFs you could
also have to SEND data? Or?

>>>Second in preference to that is to allow received data to be saved,
>>>but not used.  In no circumstance should we allow data to be *sent*.
>>
>> I assume that also includes e.g., SCTP messages, i.e., in case of a
>>WebRTC
>> Data Channel it wouldn¹t be allowed to establish the SCTP association.
>
>Yes, if you don't know to whom you are sending things, the only safe
>action is not to send.  You can carve out exceptions for things like
>handshaking SCTP on the proviso that they are found to contain no
>actionable content, but that's tricky.

I agree. We should avoid specifying per-protocol exceptions, because
sooner or later it will end up in a mess.

Regards,

Christer