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

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.

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.

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

Note that we guarantee that the first frame delivered to the
application is either ordered or the in-band open message, so this
provides a pretty high degree of assurance about the nature of the
channel when the first message is ready for delivery.

>
> For SCTP-based datachannels, the "open" message seems to be exactly what
> you're asking for, but we don't have such a thing for RTP (unless you're
> thinking of adding yet more RTCP-based extensions).

No, I'm looking for API and for data channels only.  We're already
talking about RTP solutions in the IETF.  This is why I raised the
question over here.

Received on Monday, 18 November 2013 19:47:18 UTC