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

On 16/04/14 06:15, bugzilla@jessica.w3.org wrote:
> 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".
Would not an easy fix be to say "because the remote peer permanently
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
>

Received on Wednesday, 16 April 2014 05:45:34 UTC