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

From: Christian Groves <[email-masked]>
Date: Tue, 08 Apr 2014 13:47:36 +1000

Hello Salvatore,

Is there any plans to update the draft according to Paul's comments? I 
think he has valid concerns regarding how fmt is currently specified in 
the draft.

Regards, Christian

On 23/02/2014 10:07 AM, Paul Kyzivat wrote:
> 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
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Apr 2014 11:53:01 -0400

We had an offline discussion of this in London - not exactly what is 
below, but similar. I thought we had agreement in principle and that Sal 
would be issuing a new version. But I don't recall hearing anything more 
since then.

	Thanks,
	Paul