Re: [MMUSIC] DTLS-over-SCTP, anyone?

[Christer Holmberg <[e-mail]>]

Hi Roman,

> I think we can add the following to section 7.1 of dtls-sdp:
>
> If DTLS is transmitted over a reliable transport and if DTLS procedures for retransmissions are not used, for instance as described in
> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span across multiple transports. Using 'dtls-connection' attribute with 
> an 'existing' value in combination with change of such a reliable transport should be treated as an error and DTLS association MUST be 
> terminated.

Your text as such looks ok. But, do we really want to add it as a generic restriction in draft-dtls-sdp? Shouldn't it be specific for DTLS-over-SCTP instead? What if someone defines DTLS-over-<new-fancy-reliable-transport> and they DO allow span?

Regards,

Christer




_____________
Roman Shpount

On Mon, Feb 8, 2016 at 8:57 PM, Christian Groves <[e-mail]> wrote:
Hello

I think the fact that the draft doesn't support DTLS-over-SCTP has been known for some time. No one has been pushing for its inclusion. I'd be happy if it was left out to be able to progress the draft.

Alternatively we can do what I think Albrecht is suggesting. Reserve proto values for DTLS/SCTP/IP and SCTP/UDP/IP in the draft and indicate their use by SDP should be defined in a future specification. I don't think its worth solving that problem now.

Regards, Christian

On 9/02/2016 7:45 AM, Christer Holmberg wrote:

Hi,

> The problem with DTLS-over-SCTP (RFC 6083) is that it is not fully compatible with draft-ietf-mmusic-dtls-sdp.

> In particular, RFC 6083 does not allow DTLS association span across multiple SCTP associations, but

> draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association through a transport change. The most likely

> solution to this is updating RFC 6083, but, if no one is using DTLS-over-SCTP, it would be easier just to say

> that DTLS-over-SCTP is not supported.

**If** we decide to keep DTLS-over-SCTP in the draft, my suggestion would be to say that “DTLS preservation over transport change” does not apply to DTLS-over-SCTP, with a reference to RFC 6083.

Then, if someone at some point updates RFC 6083, the SCTP-SDP spec also has to be updated.

I do NOT want to delay draft-sctp-sdp until a possible RFC 6083 update has been done (assuming people would agree to do it in the first place).

Regards,

Christer

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) <[e-mail] <mailto:[e-mail]>> wrote:

    Hello Christer,

    the titel of the (future) RFC will not exclude any SCTP transport
    modes.

    And a comprehensive and future safe protocol specification should
    cover all existing ones, which is “DTLS/SCTP/IP” as well as
    “SCTP/UDP/IP” (RFC 6951).

    These two SCTP transport modes should be indicated as well,
    independent of potential intentions to be used soon.

    Codepoint space could be reserved, placeholder sections tagged as
    “not yet supported” of “for further studies”, etc, but the worst
    case would be any kind of interaction issues in future.

    My view,

    Albrecht

    *From:*mmusic [mailto:[e-mail]
    <mailto:[e-mail]>] *On Behalf Of *EXT Christer Holmberg
    *Sent:* Montag, 8. Februar 2016 15:33
    *To:* mmusic <[e-mail] <mailto:[e-mail]>>
    *Subject:* [MMUSIC] DTLS-over-SCTP, anyone?

    Hi,

    draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A
    procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP.

    As we know, SCTP-over-DTLS is used for the WebRTC data channel.

    My question is: does anyone intend to use DTLS-over-SCTP?

    Regards,

    Christer


    _______________________________________________
    mmusic mailing list
    [e-mail] <mailto:[e-mail]>
    https://www.ietf.org/mailman/listinfo/mmusic



_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic