Subject: [MMUSIC] Some comments on draft-ietf-mmusic-sctp-sdp-03

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Feb 2013 16:27:49 -0500 (EST)

* section 4.3

The following example is given:

           m=application 54111 DTLS/SCTP 5000 5001 5002
           c=IN IP4 79.97.215.79
           a=sctpmap:5000 webrtc-DataChannel 2
           a=sctpmap:5001 bfcp 1
           a=sctpmap:5002 t38 1
           a=webrtc-DataChannel:5000 stream=1;label="channel 1";subprotocol="chat";
           a=webrtc-DataChannel:5000 stream=2;label="channel 2";subprotocol="file transfer";max_retr=3

This example is missing the a=fingerprint attribute, which is
mandatory according to section 3.

This specifies that SCTP-over-DTLS-over-DCCP will be used, with the
near-end DCCP port being 54111.  However, the numbers "5000", "5001",
and "5002" seem to have no function, in that they appear nowhere on
the wire.  At least one "format" number is syntactically required in
the m= line, but there seems to be no reason to provide multiple
format numbers.

A more natural organization of the attributes for DTLS/SCTP use seems
to be this, which identifies the component media by their SCTP stream
identifiers (which is how they will be demultiplexed):

           m=application 54111 DTLS/SCTP 0
           c=IN IP4 79.97.215.79
           a=sctpmap:webrtc-DataChannel 2
           a=sctpmap:bfcp 1
           a=sctpmap:t38 1
           a=webrtc-DataChannel:5000 stream=1;label="channel 1";subprotocol="chat";
           a=webrtc-DataChannel:5000 stream=2;label="channel 2";subprotocol="file transfer";max_retr=3

Or perhaps use the SCTP stream identifiers could be used as the
primary identifiers in the a=webrtc-DataChannel attributes:

           a=webrtc-DataChannel:1;label="channel 1";subprotocol="chat";
           a=webrtc-DataChannel:2;label="channel 2";subprotocol="file transfer";max_retr=3

It's also not clear why the BFCP and T.38 media are assigned the same
SCCP stream identifier (i.e., 1).  That seems to be a mistake.

* section 5

There are a number of attributes with the generic format
"a=<name>=<value>".  I believe this should be "a=<name>:<value>".

         stream-attr       =  "a=stream=" streamnumber
         label-attr       =  "a=label=" labelstring
         subprotocol-attr       =  "a=subprotocol=" labelstring
         maxretr-attr       =  "a=maxretr=" maxretrvalue
         maxtime-attr       =  "a=maxtime=" maxtimevalue

* section 5.3

This section defines an apparently new "a=label" attribute:

         label-attr       =  "a=label=" labelstring
         labelstring      =  text
         text             =  byte-string

But the label syntax is incompatible with the existing label
attribute:

    RFC 4574 section 4

      label-attribute    = "a=label:" pointer
      pointer            = token
      token              = 1*(token-char)
      token-char         = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                           / %x41-5A / %x5E-7E

And it's not clear why this "new" attribute is defined at all, since
there is a label carried in the a=webrtc-DataChannel attribute
already.

Dale