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 10:55:04 +0100
Message-ID: <5289E3F8.3060406@alvestrand.no>
To: public-webrtc@w3.org
On 11/14/2013 06:37 PM, bugzilla@jessica.w3.org wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23832
>
>              Bug ID: 23832
>             Summary: Requiring that negotiated channels be created on the
>                      receiver before any data can be received is
>                      problematic for some use cases
>             Product: WebRTC Working Group
>             Version: unspecified
>            Hardware: All
>                  OS: All
>              Status: NEW
>            Severity: normal
>            Priority: P2
>           Component: WebRTC API
>            Assignee: public-webrtc@w3.org
>            Reporter: martin.thomson@skype.net
>                  CC: public-webrtc@w3.org
>
> It is currently quite difficult to manage negotiated streams.

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.

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

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

>
Received on Monday, 18 November 2013 09:55:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC