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

From: Salvatore Loreto <[email-masked]>
Date: Mon, 8 Oct 2012 11:12:49 +0300

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2012 16:43:36 -0400

Salvatore,

Comment/question inline

> which is describing the format of the media... so they should go in a

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.

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.

I have more to say, but I'll start another thread for that.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2012 17:12:46 -0400

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:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 11 Oct 2012 18:28:30 +0300

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

> 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

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 11 Oct 2012 18:45:15 +0300

On 10/11/12 12:12 AM, Paul Kyzivat wrote:
> 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
great!
>     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

> be used to negotiate a channel over which a dynamic assignment protocol

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.

> discussed in MMUSIC or RTCWEB.

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

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Oct 2012 11:59:51 -0400

> sorry not to have been enough clear about that.

OK. Glad to have that cleared up.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Oct 2012 12:53:16 -0400

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

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

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

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

OK.

	Thanks,
	Paul