Re: SDP renegotiation with same msid but different ssrc (video becomes frozen)

Den 11. mars 2016 12:25, skrev Iñaki Baz Castillo:
> Hi, not sure whether this is a bug in Chrome or a wrong SDP usage in our side.
> 
> Chrome receives the SDP from the server (a media server), which has
> msid:1234 and ssrc:888888. Proper 'addstream' event is fired.
> 
> Later we renegotiate the media session and Chrome receives an updated
> SDP from the server, which now has the same msid:1234 but a different
> ssrc:999999. And yes, RTP packets also have ssrc 999999.
> 
> And this happens:
> 
> - There is no 'addstream' event. It makes sense since msid is the same. OK.
> 
> - But the remove video gets frozen.
> 
> - If I set the remote MediaStream into the <video> element again, then
> the remote video is rendered.
> 
> I insist, the first remote MediaStream got in the 'onaddstream' event
> and the remote MediaStream retrieved from the PeerConnection after the
> renegotiation are the *same* (same instance of MediaStream). But...
> somehow I need to re-set video.src = URL.createObjectURL(stream) for
> the remote video to be rendered.
> 
> Is it illegal to change the ssrc value(s) within the same m= section
> during a SDP O/A renegotiation?
> 
> I think that the browser does not fire 'addstream' because the msid is
> the same as before, but somehow it does not provide the <video>
> element with the received media once it comes on a different SSRC.
> 
> Thanks a lot.
> 

I am not at all surprised it does not work. I think it should, but I'm
not sure exactly how.

Question: When does the sender change its SSRC to the new value? When
sending the offer in the negotiation, or when getting the answer back
that it's accepted?
And what does it send inbetween those two times? Nothing, old SSRC or
new SSRC?

Received on Friday, 11 March 2016 13:48:59 UTC