[MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the SDP description of SCTP and have some comments and
suggestions.

1. My first comments is a very general one and concerns the relationship
between the proposed SCTP related proto identifiers and ICE for the
DTLS/SCTP encapsulation.

When ICE was defined it was natural to include ICE by reftorfitting it
to existing proto identifiers. However, given that this specification
intorduce a number of new identifiers I do woner if we should be more
explicit about the ICE usage in the proto field. I think have both pro
and cons for this.

So my considerations is basically to include specification of
ICE/DTLS/SCTP, where the lower layer transport is defined by what ICE
agrees on. This makes a lot of sense given that ICE can in fact arrive
on the usage of TCP/framing/DTLS/SCTP, TCP/TURN/DTLS/SCTP in addition to
more expected choices as UDP/DTLS/SCTP. This makes it clears that you do
require ICE to negotiate this transport flow. At the same time it is a
significant downside if ones negotiation needs are to chose between
using ICE or a specific lower layer transport.

These comments doesn't apply when one runs SCTP on top of IP.

2. Section 1:
RFC4145 [RFC4145] specifies a general mechanism for
   describing and establishing TCP (Transmission Control Protocol)
   streams.

I do dislike that usage of the RFC number as the explanation of what the
referenced document is. The previous sentence is how I prefer it to be
done:
   SDP (Session Description Protocol) [RFC4566] provides a general-
   purpose format for describing multimedia sessions in announcements or
   invitations.

Use the document title or an abbreviated explanation for what the
referenced document specifies and one gets much better flow in the
reading as one don't have stop look up the reference to find out what is
referred to.

3. Section 1:
I think having first a paragraph for SCTP and then having "Additionaly
.." with the other two protos are bit strange. Why not simpley say. This
document defines three proto identifiers: list of them with explnation.

4. Section 1:
   DTLS/SCTP :  to allow the usage of SCTP on top of the Datagram
      Transport Layer Security (DTLS) protocol, as defined in
      [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP.  SCTP over DTLS is
      used by the RTCWeb protocol suite for transporting non- media data
      between browsers.

This definitions says nothing of the lower transport layer for DTLS/SCTP
even if UDP is referred to in a later section. I think this needs to be
clarified and discussed in the context of which lower layers do we
expect to be supported? From my perspective I think two makes sense.
ICE/DTLS/SCTP that allows ICE to negoiate what ever and then
UDP/DTSL/SCTP that only uses UDP as lower layer. Lets other add other
variants in the future if needed.

5. Section 3:
   The 'DTLS/SCTP' protocol identifier indicates that the media
   described will use SCTP on top of the Datagram Transport Layer
   Security (DTLS) protocol as specified in
   [I-D.tuexen-tsvwg-sctp-dtls-encaps].

I would like to point out that the referenced document does not at all
indicate what lower layer is being used under DTLS.

6. Section 4.1:

This section discuss the usage of the "data channels" within the SCTP
association. My personal position is that for the moment this appears to
be unnecessary. The most important part is the SCTP association
establishment. Then one can discuss the general application using the
SCTP association as whole. Examples of such are WebRTC data channel.

If anyone want stream level information in SDP then I propose that this
is handled as a extension to this signaling, not an from the start
included functionality as we don't appear to have clear requirement for
that.

7. Section 4.2:

What are the requirements behind being able to establish multiple SCTP
association over the same DTLS connection? I am very unclear why this
would be required, and if not really needed I would suggest keeping
things simple.

8. Section 4.3: I guess this can for the moment be removed as it appears
to be taken care in other places, such as the RTCWEB WG data channel
protocol proposal.

9. If you are removing the multiple association and the "data channel"
parameters then most of the issues in section 5 vanish. If not I have
additional feedback on this section.

10. Section 8.

   Current NATs do not typically support SCTP.  As an alternative to
   design SCTP specific NATs, Encapsulating SCTP into UDP
   [I-D.tuexen-sctp-udp-encaps] makes it possible to use SCTP in
   networks with legacy NAT and firewalls not supporting SCTP.

First of all, there is a WG version for this document:
draft-ietf-tsvwg-sctp-udp-encaps-14. Which is in IESG evaluation. Thus I
wonder why signalling for this is not included when all the other
options are included, even less mature ones then this?

To me it looks like this document need to have some high level decisions
on what to include and not and then try to finish it up within the
agreed constraints. From my perspective I think it should focus on a
single SCTP association per m= line and the actual SCTP association.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------