Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp: a concern from CLUE

[Salvatore Loreto <[e-mail]>]

On 10/11/12 12:12 AM, Paul Kyzivat wrote:
> In the clue wg we have need for a data channel for some application
> level signaling.
what is a data channel for CLUE wg.
As I said in the other thread in 
http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-03
we have the following definitions:

3.  Terminology

    This document uses the following terms:
    Association:  An SCTP association.
    Stream:  A unidirectional stream of an SCTP association.  It is
       uniquely identified by a stream identifier.
    Channel:  A bidirectional channel consisting of two SCTP streams.


>   While not yet settled, we have a strong interest in
> using the same SCTP over DTLS mechanism that RTCWEB is using. We have a
> couple of reasons for that:
> - it meets our needs for a reliable channel
> - rtcweb is doing the work of defining a mechanism that will
>     work through NATs, etc.
great!
> - we want to make it possible to implement clue in a webrtc client.
>     But we don't want to require that clue be implemented over webrtc!

this is reasonable
>
> As far as we can see now, clue will only need a single channel.
then you can do something like

m=application 60878 SCTP/DTLS
c=IN IP4 79.97.215.79
a=fmtp:datachannel streams=1

i.e. you are negotiating to establish an SCTP association with only one 
single stream in each direction,
and use it to establish a datachanel

>
> An webrtc implementation of clue will need to use the webrtc APIs to
> request a channel for clue use. But a native sip implementation of clue
> won't have the webrtc APIs. In sip the natural way to assign something
> like this would be via SDP.
>
> The bottom line for me is that there should be a mechanism via SDP to
> negotiate some SCTP channels for particular uses. If webrtc also wants
> to support dynamic assignment of channels, then the SDP mechanism could
> be used to negotiate a channel over which a dynamic assignment protocol
> can be run.

then perhaps what you need is a way to declare (in a label attribute?) what
you want to run within a specific channel
perhaps something like that

a=datachannel:0 stream=0;label=CLUE


i.e. the only datachannel that you have negotiated use the stream 0 and then
the "label" attribute tell you what you are going to run on top of it.

>
> I realize this is a bit messy. I don't know whether it is better
> discussed in MMUSIC or RTCWEB.

lets discuss in MMUSIC, as all the SPD expert are here!


-- 
Salvatore Loreto, PhD
www.sloreto.com


>
> 	Thanks,
> 	Paul
>
> 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.
>>
>> opinion, thoughts are welcome and required
>>
>> thanks
>> Salvatore
>>
>> --
>> Salvatore Loreto, PhD
>> www.sloreto.com
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>