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

[Salvatore Loreto <[e-mail]>]

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.

> 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 have more to say, but I'll start another thread for that.
let me read it before

thanks for your comments

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com