W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2016

[webrtc-pc] Section 5.1.1: Issue 2

From: aboba via GitHub <sysbot+gh@w3.org>
Date: Thu, 27 Oct 2016 17:42:16 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-185735209-1477590134-sysbot+gh@w3.org>
aboba has just created a new issue for 

== Section 5.1.1:  Issue 2 ==
"Issue 2" is contained within a note in Section 5.1.1.  It is time for
 this issue to be "fully considered". 

Since the beginning of this specification, remote MediaStreamTracks 
have been created by the setRemoteDescription call, one track for each
 non-rejected media description in the remote description. This meant 
that at the caller, MediaStreamTracks were not created until the 
answer was received, and any media received prior to a remote 
description (AKA "early media") would be discarded. If any form of 
remote description is provided (either an answer or a pranswer), this 
issue does not occur.

If we want to allow early media to be played out, minor changes are 
necessary. Fundamentally, we would need to change when tracks are 
created for the offerer;  this would have to happen either as a result
 of setLocalDescription, or when media packets are received. This 
ensures that these objects can be created and connected to media 
elements for playout.

However, there are three consequences to this potential change:

Media may arrive before the remote DTLS fingerprint has been received.
 This means that media could be played out before the validity of the 
DTLS fingerprint has been established, which may be hard to explain to
 users. As such, it is recommended that media not be played out unless
 some TBD RTCConfiguration property (e.g. AllowUnverifiedMedia) has 
been set.

The information needed to correlate MediaStreamTracks with their 
enclosing MediaStreams will not yet be present when the tracks are 
initially generated. Therefore, the implementation will need to create
 dummy MediaStream objects for each MediaStreamTrack, and then 
possibly change the associated MediaStream for each track when the 
remote description is received (e.g. if it indicates that an audio and
 video MediaStreamTrack should be combined into a single MediaStream).
 Since media elements act on MediaStreams, some complex reshuffling 
may need to occur when the remote description is received.

The track events fired and their timing will change. For the offerer, 
ontrack will now fire during setLocalDescription, once for each track 
being offered, and track.onended will fire during setRemoteDescription
 for any offered tracks that were rejected. For the answerer, ontrack 
will continue to fire during setRemoteDescription, as it does today 
(this is necessary to allow the answerer to reject offered tracks by 
stopping them).

Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/886 using your GitHub account
Received on Thursday, 27 October 2016 17:42:22 UTC

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