Re: Minimizing the protocol (Re: Data API)

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

Received on Wednesday, 29 February 2012 23:27:24 UTC