W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2014

[Bug 25360] New: MediaStreamTrack should not be considered as ended just because remote peer stopped sending data.

From: <bugzilla@jessica.w3.org>
Date: Wed, 16 Apr 2014 04:15:25 +0000
To: public-media-capture@w3.org
Message-ID: <bug-25360-5753@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25360

            Bug ID: 25360
           Summary: MediaStreamTrack should not be considered as ended
                    just because remote peer stopped sending data.
           Product: WebRTC Working Group
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Capture and Streams
          Assignee: public-media-capture@w3.org
          Reporter: kiran.guduru@samsung.com
                CC: public-media-capture@w3.org

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
Received on Wednesday, 16 April 2014 04:15:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:26 UTC