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 21877 - API is unable to handle inbound streams prior to arrival of answer
Summary: API is unable to handle inbound streams prior to arrival of answer
Status: RESOLVED LATER
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: WebRTC API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Martin Thomson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-30 17:04 UTC by Martin Thomson
Modified: 2014-12-15 10:39 UTC (History)
2 users (show)

See Also:


Attachments

Description Martin Thomson 2013-04-30 17:04:45 UTC
The ability to handle inbound media prior to an answer arriving is a key reason that the WebRTC API uses SDP offer/answer.  However, this presents several challenges.

1. ICE: the offerer is expected to nominate pairs, but it cannot send connectivity checks prior to learning about the answerer's ufrag and password.  Since the offerer is responsible for nominating, nothing happens until the answer arrives.

2a. Security Descriptions: the offerer doesn't know about the decryption keys for newly arrived streams.
2b. DTLS: the offerer can complete the handshake, but cannot render media until it obtains an identity assertion.

3a. Media: the offerer cannot correlate an inbound packet with an m= line by SSRC (if packet types are unique, then this could be used).  
3b. The offerer does not know how to identify the inbound media stream and what grouping it fits within (CNAME, if present, is unsuitable because CNAME can be the same for multiple MediaStreams).

This has been discussed at some length in the IETF.  It could be that the IETF arrive at some sort of conclusion on how to address this within SDP.  I consider that unlikely (as unlikely as any statement of the form "... IETF arrive at some sort of conclusion ... SDP").  There are also discussions in the IETF around providing labeling on the media path.

It may be that some of these can't be addressed easily, or the situation changes depending on what multiplexing is in place, for example.  Certainly, less of these factors are a problem when a new stream is added to a multiplexed bundle on an existing transport (only 3a, 3b and maybe 2a apply).

Regardless of what the IETF concludes it's likely that there will be a need for API changes to support this feature (3b in particular).

CU-RTC-Web addresses this problem by providing an event for an as-yet-unsignaled media flow.  This event indicates SSRC and packet type of the unknown packet.  It also requests that browsers buffer this inbound stream for a short time.  Buffering would probably just include enough time to allow the application to process and respond to the event, there is no need to allow enough time to perform any signaling, which would undermine the whole "real time" aspect of this and potentially cause buffering space to be larger than is tolerable. 

The CU-RTC-Web solution is fairly simple because it pushes responsibility onto the application.  That might be an undesirable property, though it might be argued that this is an advanced usage of the API and the extra application responsibility is commensurate with that.

An alternative solution involves the creation of "dummy" media streams that exist for a short time.  There are several variations on this.  In one solution the streams that are created are single track streams with undefined identifiers.  Another alternative suggests that a single default stream is created with all unannounced tracks attached to it.

There is another alternative to be considered for 3b, which is that identifiers could be allocated locally (CU-RTC-Web does this).  In order to correlate streams with the ones on the remote peer a new attribute, remoteid, is added to include the identifier used by the source.  The 'remoteid' would only be populated once signaling arrived.  

'remoteid' provides a measure of stability that the "dummy" stream configurations cannot provide.  'remoteid' would probably supplant the recently added 'remote' attribute.
Comment 1 Harald Alvestrand 2013-05-01 07:24:21 UTC
Sorry to be rude, but I'm closing this as invalid.

As far as I can tell, we gave up on the ability to handle inbound media prior to an answer arriving the day we decided to not allow unencrypted media - and this is something we can't work around as long as we use SDP offer/answer.
Comment 2 Martin Thomson 2013-05-02 22:08:44 UTC
Based on the brief on-list discussion, this is at least valid for point 3.
Comment 3 Harald Alvestrand 2014-10-28 18:53:04 UTC
BUNDLE's RTP header extension seems to address some of these concerns, but I don't think all of them are addressed there.

However, it's hard to see that this has an API impact.

What, if anything, do we need to do here?
Comment 4 Harald Alvestrand 2014-10-31 16:22:23 UTC
The only API change that might be relevant here is to surface error information about incoming data that has been thrown away because configuration data is not available.

Action: Text describing how the error is indicated should be added to document.
Comment 5 Martin Thomson 2014-11-05 00:44:53 UTC
https://github.com/w3c/webrtc-pc/pull/29
Comment 6 Dominique Hazael-Massieux 2014-12-15 10:39:21 UTC
WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues

Please subscribe to the issues you want to keep watching.