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

[Paul Kyzivat <[e-mail]>]

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

On 4/7/14 11:47 PM, Christian Groves wrote:
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>