[MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

[Christer Holmberg <[e-mail]>]

Hi,
Currently the draft-ietf-mmusic-dtls-sdp defines the usage of existing SDP "connection" attribute for DTLS. The attribute is used to explicitly indicate whether a new DTLS association shall be created or not.
One of the open questions is whether we should use existing "connection" attribute for this purpose, define a new attribute (working name: "dtls_connection") with similar semantics, or design a new usage which is more robust in cases of 3PCC.
Why would we use a different attribute?
In most cases (e.g. UDP/DTLS) existing "connection" attribute works well. However, if you layer other connection oriented protocols over DTLS (e.g. 'SCTP/DTLS' or 'UDP/DTLS/SCTP') "connection" attribute would apply to both the SCTP *and* DTLS layer. This might be an acceptable usage, but are there use cases when DTLS connection would need to be re-established, but SCTP connection still maintained?

There are also more exotic use cases, when DTLS is layered over connection oriented protocols (e.g. 'TCP/DTLS/SCTP'). In such cases "connection" attribute would apply to the SCTP *AND* the DTLS *AND* the TCP layer.
Having a dedicated attribute would allow separate control over the DTLS layer. E.g. in the case of 'UDP/DTLS/SCTP' it would be possible to re-establish the SCTP association without touching the DTLS association.

Another option is to define a "ufrag" which identifies an end point in DTLS association (working name: "dtls_ufrag"). Each endpoint in the offer/answer exchange would generate its own "dtls-ufrag". If either "dtls-ufrag" values changed, then new DTLS association would need to be established.

Why would we need something like this?

ICE and 3PCC and oferless INVITEs. When ICE end point responds to an offer-less INVITE, it will allocate new ufrag, collects the full set of ICE candidates, but would still like to keep the existing DTLS connection and local ICE candidates which it is currently using. It will send the response with the generated answer with all this information, but the value for old style "connection" SDP attribute is unclear. If value "connection:new" is specified, none of the existing ICE candidates can be used, complete new set would need to be allocated to prevent transport pair reuse for multiple DTLS associations, and new DTLS association would need to be created even if the same two end-points get reconnected. If value "connection:existing" is used, then existing DTLS association and candidates can be used, but the generated offer cannot be used as an initial offer to the new end point.

If "dtls_ufrag" value is used, then in response to offer-less invite the existing value of this attribute will be provided in the generated offer. The answering party, if it is an end point which is already communicating with the current end-point can respond with its current "dtls_ufrag" value and the existing DTLS association will be re-used. If answering party is a new end point which was not part of the existing DTLS association, it will reply with new value of "dtls_ufrag". Since one of the values changed, a new DTLS association will be established. There is no risk of transport re-use for several DTLS associations, since answering party will allocate a complete new set of ICE candidates.

What do you prefer, wasting resource in response to offer-less invite and allocating a complete new set of ICE candidates every time such INVITE is receive or dealing with a more complex attribute semantics?
Comments? Preferences?
Regards,
Christer