Re: Minimizing the protocol (Re: Data API)

See
https://docs.google.com/a/google.com/document/d/16csYCaHxIYP83DzCZJL7relQm2QNxT-qkay4-jLxoKA/edit,
section 5.3 for examples of what I was proposing.

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

>
> I'd rather see it done in SDP as you were proposing - otherwise we end up
> reinventing the whole thing for no good reasons. And I think the SDP can
> associated the label with the correct SCTP channel. It will be trivial and
> not require any code that we did not have to already write for the RTP.
>
>
> On Feb 29, 2012, at 4:15 PM, Justin Uberti wrote:
>
> > 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
> > >
> >
> >
> >
>
>