W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

Re: [Bug 23832] New: Requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 18 Nov 2013 21:15:23 +0100
Message-ID: <528A755B.9030804@alvestrand.no>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 11/18/2013 08:46 PM, Martin Thomson wrote:
> To begin, the context was a comment made by Randell in the last
> meeting.  New channels that are marked as negotiated can be created
> asymmetrically.  The side that doesn't create the channel doesn't get
> any indication that something is going on.
> I would prefer that a channel be created in these cases, even if it
> doesn't correspond with reality.  At a minimum, this would allow an
> application to learn that their "negotiation" failed.  At best, it
> would allow for unilateral creation of data channels, which is a usage
> mode that I really like for some applications.  Maybe the created data
> channel doesn't allow for sending, maybe it can be replaced by a new
> channel.

Why not just fire an error when data (not an open message) arrives on a
stream ID that doesn't correspond to an existing channel?

That would serve the purpose of alerting the JS that something was
wrong, without having to deal with a half-open, half-configured or
half-confused channel.

> On 18 November 2013 01:55, Harald Alvestrand <harald@alvestrand.no> wrote:
>> Martin, can you explain what you mean by "negotiated streams" in this
>> context?
>> In the summary you use the word "channels", which usually means
>> datachannels, but I can't tell from the rest of the message whether you are
>> talking about SCTP-based datachannels or RTP SSRCs.
> I was talking about data channels.
> I'm really sorry.  SCTP uses the word stream.  So does HTTP/2.0.  It's
> hard to make the switch cleanly some times.  I even caught myself a
> couple of times writing this email.

I tend to think of a stream as being unidirectional, and a channel as
two linked streams that point in opposite directions; that seems to work
for most usages of the words around webRTC. Not sure about HTTP/2.0 - I
haven't read that spec.

>>>    These cannot be
>>> unilaterally created.  They depend on signaling.  Some usages require that
>>> streams be created and used very quickly without signaling.  These usages
>>> typically have a fixed configuration for tracks and the receiving end is
>>> typically able to create a data channel when packets start arriving.
>>> Alternatively, the initial packets could contain hints to the application
>>> about
>>> what configuration to apply.  The current API prohibits/prevents this.
>>> That is
>>> bad.
>>> The API should fire an event when packets arrive on an unannounced
>>> channel.
>>> Whether this results in an actual data channel or not is probably up for
>>> debate
>>> (I can see several options here).
>>> Remaining silent on the issue as the spec currently does is not
>>> acceptable.
>> As long as I don't understand what you mean by "channel", it's a bit hard to
>> know what to say here; in general, I think "hints contained in the channel"
>> means that you use an embedded configuration subprotocol, so then the
>> question is ... is this subprotocol standardized, or is use of this
>> subprotocol negotiated?
> SCTP provides some hints about what the channel might look like, even
> without the open message.  For instance, the U bit in the DATA chunk
> indicates that the chunk should be delivered in order (or not).  If
> you don't know what a data channel is supposed to look like because it
> was negotiated, then this might be used to create a channel in the
> right form.

If the app wants the unilateral creation ability, what's the overhead in
sending an open message?

I really feel uncomfortable extending the current two types of channel
(configured using open messages and configured using external
signalling) with a third type (configured using external configuration
on one side and guesswork on the other).

At this juncture, I'm looking for ways to simplify things; adding more
complexity worries me.

Surveillance is pervasive. Go Dark.
Received on Monday, 18 November 2013 20:15:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:51 UTC