Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

[Christer Holmberg <[e-mail]>]

Hi,

>Any comments on this from others? We need to solve it.
>
>Anyone has issues with allowing connection:new for SRTP-DTLS and
>SCTP-DTLS, and use that as a trigger to re-negotiate DTLS?
>
>ISTM that this is being considered tactically. Maybe that is the best for now, but perhaps there should be consideration of a strategic approach to this as well.
>
>What I mean is that this seems to be a back handed way to introduce multipath support into protocols (specifically DTLS) that don't support it. Perhaps multipath ought to be officially added to all the protocols that potentially need ICE, and then ICE would simply be one way to populate >the paths.
>
> This will still leave the question of how to determine when the multipath protocol running over ICE communicates with the new end point (i.e. connection needs to be re-established) or when this is a path update and the connection needs to be preserved. For ICE there is no easy way to determine if what >currently is happening is ICE-restart on the existing connection which should allow existing mutlipath protocol session to continue vs setting up ICE to a new end point which would require new connection setup. This problem currently affects DTLS, but I assume this will apply also to other multipath >protocols which require externally initiated connection handshake when running over ICE. This can be addressed on the protocol side (connection new attribute which will apply to DTLS) or on ICE side (some sort of indication if this is a new end-point or re-start). Protocol side change seemed to be the less >disruptive and more backwards compatible option in case of DTLS. 
>
>The reason DTLS is running into problems with ICE, is due to the fact that it was not design to run multiple sessions over the same connection and does not allow setting up a new session unsolicited using transport messages only, which are properties of RTP for which ICE was originally designed. Extending >DTLS so that it is possible to multiplex several DTLS sessions over the same connection, and initiate new session setup using transport level messages, would be a better strategic solution. Unfortunately this is not going to be backwards compatible and would further complicate design and implementation.
>
>From my personal point of view, DTLS in combination with ICE is a design mess. It would be much cleaner and strategic if instead two separate protocols this was a single protocol which was responsible for authentication, encryption negotiation, connection path discovery, path updates, and communication >consent. These are closely related tasks and ideally they should be handled together instead of one on top of the other.

So, what is your suggestion? :)

Regards,

Christer