W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

Re: Obj-C RTCMediaStreamTrackDelegate reports "ended" when it shouldn't

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 25 May 2015 12:20:01 +0200
Message-ID: <CALiegfnVOroYi2QfSCbg5aUg5vMNRQm72G1bBvX2gGku_-qxZA@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
2015-05-25 11:02 GMT+02:00 Iñaki Baz Castillo <ibc@aliax.net>:
> Scenario:
>
> - iOS device generates an audio/video offer and establishes a session
> with a remote peer (let's say Chrome desktop).
>
> - Later, Chrome puts the call "on hold" by sending its previous SDP
> with all the m= lines having "a=sendonly" (but still same msid and so
> on, the SDP is just mangled at JS level).
>
> - iOS receives the re-offer, calls to setRemoteDescription() followed
> by createAnswer() and setLocalDescription().
>
> - The remote RTCMediaStreamTracks of the RTCPeerConnection report
> RTCTrackStateEnded state (by means of their
> RTCMediaStreamTrackDelegate instances).
>
> Why? Does it make sense? Those are the exact same MediaStreamTracks
> than before. It is just that now they are offered with "a=sendonly"
> which means that the remote peer just wants to send media to iOS but
> not receive from it. This is: the tracks remain alive! why is
> RTCTrackStateEnded reported?

I may be wrong, I see a different behavior right now so something may
be wrong in my code. Will update later.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Monday, 25 May 2015 10:20:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC