- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Mon, 25 May 2015 12:20:01 +0200
- 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