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

Hello Christer,

I'm for keeping it simple and having a specific dtls_connection attribute.

Regards, Christian

On 18/09/2015 4:48 PM, Christer Holmberg wrote:
>
> 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
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic