- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Mon, 25 May 2015 11:02:08 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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? Thanks a lot. -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Monday, 25 May 2015 09:02:58 UTC