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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 20 March 2013 15:11 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 42DE121F8FC4 for <mmusic@ietfa.amsl.com>; Wed, 20 Mar 2013 08:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.619
X-Spam-Status: No, score=-106.619 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_INA=0.786, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id b+bZ6MOjvIPY for <mmusic@ietfa.amsl.com>; Wed, 20 Mar 2013 08:11:48 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 694CE21F8470 for <mmusic@ietf.org>; Wed, 20 Mar 2013 08:11:47 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-82-5149d1ab9dc6
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain []) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CB.45.10459.BA1D9415; Wed, 20 Mar 2013 16:11:39 +0100 (CET)
Received: from [] ( by esessmw0256.eemea.ericsson.se ( with Microsoft SMTP Server id; Wed, 20 Mar 2013 16:11:39 +0100
Message-ID: <5149D1AA.4010805@ericsson.com>
Date: Wed, 20 Mar 2013 16:11:38 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "mmusic (E-mail)" <mmusic@ietf.org>, draft-ietf-mmusic-sctp-sdp@tools.ietf.org
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvje7qi56BBjPPG1pMeTOD1WLq8scs DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAldGy94djAVPdSpaVnxjaWD8rdzFyMkhIWAi cad1MhuELSZx4d56IJuLQ0jgJKPE7u59rBDOckaJGf3zWUCqeAW0JSZ2n2EGsVkEVCWm9DeA xdkELCRu/mgEmyQqECzx89UZqHpBiZMzn4DZIgKhEi96VrGD2MICBhL7585mgtgsKbHlRTtY nFlAT2LK1RZGCFteonnrbLBdQkB7G5o6WCcw8s9CMnYWkpZZSFoWMDKvYmTPTczMSS833MQI DLKDW37r7mA8dU7kEKM0B4uSOG+Y64UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzWp2yn S2hdZb2sUyprtL3n8Xb2bb4zpHslRBPz+qZofXR5UR247I7RRdeUE7tWW9ettyxtl3Y0uZZt t0RiUiJD4M7SS4p+OdLqC6qXfBC22vDjUmz0NOEJVX3P1MqvHP/i6dGX+UjalfPyNdWfrKcd LF6sWLWhwIDj55xD8xOm//BpOqXoJq3EUpyRaKjFXFScCABajBv6AAIAAA==
Subject: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2013 15:11:49 -0000


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

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)

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
   SDP (Session Description Protocol) [RFC4566] provides a general-
   purpose format for describing multimedia sessions in announcements or

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 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

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.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com