Re: [MMUSIC] updating draft-ietf-mmusic-sctp-sdp

[Paul Kyzivat <[e-mail]>]

On 10/11/12 11:28 AM, Salvatore Loreto wrote:
> On 10/10/12 11:43 PM, Paul Kyzivat wrote:
>> Salvatore,
>>
>> Comment/question inline
>>
>> On 10/8/12 4:12 AM, Salvatore Loreto wrote:
>>> Hi there,
>>>
>>> there has been a quite large discussion within the rtcweb mailing list and
>>> especially the w3c webrtc mailing list.
>>>
>>> Some of the points discussed are specific of how to negotiate the
>>> 'datachannel' protocol over SDP,
>>> and I lean on putting those in a separate draft and not in this one.
>>>
>>> However there are things that are general enough to is worth to insert
>>> in this draft
>>> as they can be used in other protocols that eventually will be specified
>>> in the future
>>> running on top of SCTP, or STCP over DTLS.
>>>
>>>    'streams' is some of those attributes,
>>>    so I am proposing to insert in the new version of the draft the
>>> following text
>>>
>>>    xxx.  Streams Attribute
>>>
>>>      The 'streams' attribute indicates time the number of streams to be supported by the association.
>>>      If this attribute is not present, the implementation should provide a default, with a suggested value
>>>      of 16.
>>>
>>>
>>>            streams-attr           =  "a=streams:" streamsnumbers
>>>            streamsnumbers         =1*DIGIT
>>>
>>>
>>> As I said, all the other attributes that has been discussed are tied to
>>> the 'datachannel'  protocol identifier ( to be registered?),
>>> which is describing the format of the media... so they should go in a
>>> different draft.
>> I'm confused by the above. The m-line syntax is:
>>
>>       m=<media> <port> <proto> <fmt> ...
>>
>> and this draft is defining SCTP, SCTP/DTLS and DTLS/SCTP values for
>> <proto>. Are you suggesting that "datachannel" be defined (in a
>> different draft) as an alternative to *these* values? I would think it
>> would make more sense to define "datachannel" as a <fmt> value.
> no, I also think that "datachannel" has to be defined as a <fmt> value.
> sorry not to have been enough clear about that.

OK. Glad to have that cleared up.

>> That brings up another issue:
>>
>> According to 4566, the values of the <fmt> field are protocol specific.
>> That means that *this* draft needs to specify how <fmt> values are to be
>> understood for sctp. That is actually a problem, one might want
>> different fmt semantics for each channel.
>
> as always you are right, RFC4566 states
>
>      For media using other transport protocols, the <fmt> field is
>        protocol specific.  Rules for interpretation of the <fmt> sub-
>        field MUST be defined when registering new protocols (seeSection  <http://tools.ietf.org/html/rfc4566#section-8.2.2>
>        8.2.2  <http://tools.ietf.org/html/rfc4566#section-8.2.2>).
>
> so we can define simply the data-channel <fmt> field as a
>
>      "A bidirectional channel consisting of two SCTP streams."

I'm not going to let you get by simply hand waving. :-)

You are proposing to define this syntax with only a single valid value 
for <fmt> and no mechanism for extending it???

For RTP the <fmt> values are payload type numbers, and there is a rich 
syntax for mapping them to codecs, etc. So this covers many kinds of 
content.

For UDP the <fmt> values are MIME subtypes, which when combined with the 
<media> field give a complete MIME type that defines the packet format 
for UDP packets. The MIME registration procedures provide the way to 
define new wire formats.

I would expect that the definition for SCTP would provide a similarly 
open ended mechanism, that can support various uses of SCTP. Surely 
there will be more uses of SCTP media than just RTCWEB.

Also, SCTP by its nature provides multiple unidirectional channels in 
both directions. The description you give above suggests that you are 
describing the intended RTCWEB usage, where two SCTP channels, one in 
each direction, are semantically bound. And RTCWEB intends to support 
multiple such pairs. The description above says nothing about this. At a 
minimum there should be a reference from the particular <fmt> value to a 
specification of the semantics corresponding to that value.

It occurs to me that the nature of SCTP with multiple channels lends 
itself to a <fmt> syntax similar to that used for RTP, with "channel 
numbers" being used in a way analogous to payload type numbers with RTP. 
Then there could be a-lines binding particular channel numbers to 
properties of that channel, such as the packet format, etc.

	Thanks,
	Paul