Re: Minimizing the protocol (Re: Data API)

On 03/01/2012 12:26 AM, Cullen Jennings 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.
Since I'm continually imagining a setup with the two clients in a single 
office in northern Finland and the server that relays SDP in a 
datacenter in Japan, I am hesitant.

Of course, there's always the option of running the SDP on channel zero 
of the SCTP channel, a la what I've heard people claim that Facetime 
does, which would make *that* one a non-concern - but that scenario 
doesn't work for the cases where the relaying server for some reason 
needs to inspect and/or modify the SDP (of which I think I've heard 
some, but I'm not sure if any of those scenarios need data).
>
> 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 Thursday, 1 March 2012 09:23:08 UTC