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

[Paul Kyzivat <[e-mail]>]

On 10/11/12 11:45 AM, Salvatore Loreto wrote:
> 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.

Sorry - I didn't pay enough attention when I re-reviewed the draft and 
forgot the terminology.

Yes, we need a single bidirectional channel for the clue signaling.

There may be reasons to use other channels for separate but related 
purposes. For instance, we are likely to want to use bfcp with clue. If 
there were an SCTP mapping for bfcp then there would be an opportunity 
to use a single SCTP connection with one channel for clue-specific 
signaling and another channel for bfcp. While AFAIK there is currently 
no work to define bfcp over SCTP it would be nice if such a combined use 
could be supported.

>>   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

AFAICT the above doesn't specify what streamids are to be used. As long 
as the number of streams is just 1 this question is moot since the only 
valid value is 0. But in a more general case it is not.

Is the intent that the definition of datachannel means that the streamid 
in each direction is always the same? Or can arbitrary streamids be 
paired into a channel?

>> 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.

Something like that. We would need to work out how the protocol and 
intended use for each channel is signaled. This is very similar to the 
issues now being confronted about signaling information about individual 
RTP streams within a single RTP session.

>> 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!

OK.

	Thanks,
	Paul