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

In the clue wg we have need for a data channel for some application 
level signaling. 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.
- 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!

As far as we can see now, clue will only need a single 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.

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

	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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>