This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23832 - Requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases
Summary: Requiring that negotiated channels be created on the receiver before any data...
Status: RESOLVED WONTFIX
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: WebRTC API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Web RTC Working Group
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-14 17:37 UTC by Martin Thomson
Modified: 2014-10-31 16:31 UTC (History)
2 users (show)

See Also:

Attachments

Description Martin Thomson 2013-11-14 17:37:13 UTC 
It is currently quite difficult to manage negotiated streams.  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.
Comment 1 Harald Alvestrand 2014-10-31 16:31:48 UTC 
Doesn't seem to be applicable any more.