Subject: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06

From: Paul Kyzivat <[email-masked]>
Date: Sat, 22 Feb 2014 18:07:07 -0500

I've commented earlier on some threads about this draft.
Now I'm going through it carefully again, and have new comments:

* Section 4:

This covers media descriptions using three different <proto> fields: 
'SCTP', 'SCTP/DTLS', and 'DTLS/SCTP'.

For both 'SCTP' and 'SCTP/DTLS' the "bottom" of the protocol stack is 
SCTP, and the identifier of one end for an association consists of an IP 
address and an SCTP port. This fits with m-line syntax - the SCTP port 
number can be carried in the <port> field.

For 'DTLS/SCTP', the "bottom" of the protocol stack is UDP, with SCTP 
over it. In this case the identifier for one end of an association 
consists of an IP address, an SCTP port, and a UDP port. This doesn't 
fit well into the syntax of an m-line.

Because the *UDP* port is carried in the <port> field, for a single 
m-line there can be multiple DTLS/SCTP associations, one per SCTP port 
number. The <fmt> field is repurposed to carry the SCTP port numbers.

Then, the problems caused by DTLS/SCTP are propagated to 'SCTP' and 
'SCTP/DTLS' usages, by also placing the SCTP port number in the <fmt> 
field in these usages. (For these protos it is redundant.)

Because <fmt> is used this way, it was necessary to introduce a=sctpmap 
to specify what otherwise could have been specified using the <fmt> field.

IMO this could be made much clearer by making the following changes:

- an m-line with <proto> of 'SCTP', 'SCTP/DTLS', or 'DTLS/SCTP' always 
describes a *single* SCTP association.

- define the usage of <fmt> for these protos so that it can be used to 
carry the info currently in sctpmap, and in the DTLS/SCTP the SCTP port 
number.

- use BUNDLE for the (unlikely) case of multiple SCTP associations over 
a single UDP port.

It is a little difficult, but possible, to fit they necessary info into 
the restricted syntax of <fmt>. Here is an example of one possibility:

   m=application 12345 DTLS/SCTP webrtc-datachannel \
           sctp-port#1 streams#16 max-message-size#100000

The following is a syntax that does does that:

sctp-m-line = %x6d "="
    ("application" SP sctp-port SP "SCTP"      SP sctp-fmt CRLF) /
    ("application" SP sctp-port SP "SCTP/DTLS" SP sctp-fmt CRLF) /
    ("application" SP udp-port  SP "DTLS/SCTP" SP sctp-fmt CRLF)

sctp-port = port

udp-port = port

sctp-fmt = sctp-app *(SP sctp-param)

sctp-app = token

sctp-param = maxmsg-param / streams-param / sctp-port-param

maxmsg-param = "max-message-size#" port

streams-param = "streams#" 1*DIGIT

sctp-port-param = "sctp-port#" sctp-port

(The use of "#" as separator isn't ideal, but it is the best choice of 
what is permitted in a token, and it seems to read reasonably well. If 
people hate this there are other ways to get the same effect.)

Of course sctp-port-param is only meaningful with DTLS/SCTP. It and the 
other sctp-params can be optional, with suitable defaults defined. (For 
normal use, with only one association per UDP port everyone would 
probably take the default sctp port, and so the parameter could be omitted.)

This then also allows a=fmtp to be used with these - most likely only 
with sctp-app. E.g.,

   m=application 12345 DTLS/SCTP webrtc-datachannel \
           sctp-port#1 streams#16 max-message-size#100000
   c=IN IP4 example.com
   a=fmtp:webrtc-datachannel <whatever>

At the moment nothing webrtc-datachannel specific has been defined that 
needs to be declared in SDP, so this may not be needed. It *could* be 
used as a replacement for "a=dcmap" in 
draft-ejzak-mmusic-data-channel-sdpneg.

Bundling would apply in a case such as in section 10.1 of 
draft-ietf-mmusic-sdp-bundle-negotiation-05. That example would be 
rewritten as follows:

   a=group:BUNDLE dc bfcp t38
   m=application 12345 DTLS/SCTP webrtc-datachannel \
           sctp-port#5000 streams#16 max-message-size#100000
   c=IN IP4 example.com
   a=mid:dc
   m=application 12345 DTLS/SCTP bfcp \
           sctp-port#5001 streams#1 max-message-size#16384
   c=IN IP4 example.com
   a=mid:bfcp

   m=application 12345 DTLS/SCTP t38 \
           sctp-port#5002 streams#1 max-message-size#65536
   c=IN IP4 example.com
   a=mid:t38

* Section 5.1:

This section starts out with:

    The sctpmap attribute maps from a port number (as used in an "m="
    line) to an encoding name denoting the payload format to be used on
    top of the SCTP association or the actual protocol running on top of
    it.

This is just wrong. It doesn't really map to an encoding name denoted a 
payload format. Immediately following the above is:

    The sctpmap MUST include the app parameter indicating the application
    running on top of the association.

And the syntax defines an app parameter, instead of an encoding name. 
And as best I can tell the app parameter doesn't denote a payload 
format. (Payload formats can vary from stream to stream.) The app seems 
to denote the overall set of conventions that are used to ascribe 
meaning and format to the streams. (This needs better definition. 
Section 11.1 has an open issue to define a new IANA registry for this. 
But there is also need to say more about the semantics - what a new 
value must specify.)

Later in this section:

    Any offered association MAY be rejected in the answer, for any
    reason.  If an association offer is rejected, the offerer and
    answerer MUST NOT establish an SCTP association for it.  To reject an
    SCTP association, the SCTP port number in the "a=sctpmap:" attribute
    line in the answer MUST be set to zero.

In the case of DTLS/SCTP there are two ports - the udp port and the sctp 
port. Either can be set to zero, with different consequences. Something 
should be said about the behavior when the udp port is set to zero. (Of 
course my suggestion to revamp the m-line renders this moot.)

* Section 7:

What if the c= line contains a DNS name rather than an IP address?
Can that cause the initialization of more than one IP address?

* Section 8:

This contains the following statements:

    ... Therefore, this
    specification does not define how to describe SCTP-over-UDP streams
    in SDP or how to establish and maintain SCTP associations using ICE.
    Should these features be specified for SCTP in the future, there will
    be a need to specify how to use them in an SDP environment as well.

Doesn't the definition of DTLS/SCTP render the above incorrect?

	Thanks,
	Paul