Re: Minimizing the protocol (Re: Data API)

Media stream labels are currently signaled through SDP attributes on media
sources. I proposed a similar approach for data, to be consistent in how we
handle media and data streams, but nobody really liked that idea that much;
the thinking was that we could exchange the needed meta-info within the
SCTP protocol instead of having to do it out-of-band using SDP.

On Wed, Feb 29, 2012 at 4:14 PM, Cullen Jennings <fluffy@cisco.com> wrote:

>
> I think we are going about this the wrong way. Lets sort out how labels
> work with media tracks then ask why if data channels would be any
> different. I think that this is going to turn out to be a non issue.
>
>
> On Feb 28, 2012, at 4:28 PM, Randell Jesup wrote:
>
> > On 2/28/2012 4:18 PM, Harald Alvestrand wrote:
> >> On 02/28/2012 06:36 PM, Randell Jesup wrote:
> > [SNIP]
> >>> Sorry.
> >>
> >> argh. was fun while it lasted :-)
> >> second suggestion is to have the first message contain the label and
> >> flags.....
> >
> > Yup.  My rough plan was:
> >
> > First message on a stream (or first after a reset of the stream):
> > (pseudo-structure)
> > {
> >    CHANNEL_OPEN,
> >    flags, // reliable, unreliable, out-of-order, partially-reliable (and
> type), etc
> >    pr_value,  // partially-reliable
> >    DOMString label,
> > }
> >
> > and response:
> > {
> >    CHANNEL_OPENED,
> >    forward_stream_id, // optional
> > }
> >
> > This assumes we can avoid stream number glare by using an even/odd
> differentiation.  If we can't or don't want to, we can include in the
> response the forward channel it's responding to (it would come in on the
> reverse channel for that bidirectional pair).  This allows us to avoid
> stream ID glare by never requiring the bidirectional pair have the same
> stream number.
> >
> > --
> > Randell Jesup
> > randell-ietf@jesup.org
> >
>
>
>