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 25360 - MediaStreamTrack should not be considered as ended just because remote peer stopped sending data.
Summary: MediaStreamTrack should not be considered as ended just because remote peer s...
Status: RESOLVED FIXED
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-16 04:15 UTC by Kiran
Modified: 2014-05-08 08:09 UTC (History)
3 users (show)

See Also:

Attachments

Description Kiran 2014-04-16 04:15:25 UTC 
In section 10. Event Summary [1], non-normative section, it was specified for ended event that, ended event can be fired "because the remote peer stopped sending data".

But there are chances for remote peer to temporarily stop sending data as below.

When the user put remote peer on HOLD, the SDP will be negotiated with sendonly and recvonly in offer and answer respectively [2, 3]. In this scenario, remote peer will temporarily stop sending data until the time it is put to UNHOLD (offer, answer with sendrecv).

So MediaStreamTrack should not be considered as ended just because remote peer stopped sending data.


[1] http://www.w3.org/TR/mediacapture-streams/#event-summary
[2] http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-04#page-19
[3] http://tools.ietf.org/html/rfc3264#page-17
Comment 1 Adam Bergkvist 2014-04-16 08:04:43 UTC 
If the other peer temporarily stops sending data then the track should be considered muted. That means that the source isn't producing any data at the moment.
Comment 2 Kiran 2014-04-16 08:16:31 UTC 
(In reply to Adam Bergkvist from comment #1)
> If the other peer temporarily stops sending data then the track should be
> considered muted. That means that the source isn't producing any data at the
> moment.

It seems, perhaps, this comment should be apt for Bug 25360.
Comment 3 Kiran 2014-04-16 08:17:24 UTC 
(In reply to Kiran from comment #2)
> (In reply to Adam Bergkvist from comment #1)
> > If the other peer temporarily stops sending data then the track should be
> > considered muted. That means that the source isn't producing any data at the
> > moment.
> 
> It seems, perhaps, this comment should be apt for Bug 25360.

Sorry for the typo, it should be Bug 25361.
Comment 4 Kiran 2014-04-16 08:21:40 UTC 
This can be solved by modifying the prhase from

"because the remote peer stopped sending data"

to

"because the remote peer permanently stopped sending data".

(addition of "permanently" can remove other consequences like hold / unhold etc).
Comment 6 Stefan Hakansson LK 2014-05-08 08:09:58 UTC 
Fixed in http://dev.w3.org/2011/webrtc/editor/archives/20140507/getusermedia.html