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

The sender can change the SSRC whenever it becomes aware of a SSRC collisions and the receiver has to deal with that. It's one of the many reasons for use of identifiers other than SSRC (like rid)



> On Mar 11, 2016, at 4:25 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> 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ñaki Baz Castillo
> <ibc@aliax.net>
>

Received on Thursday, 14 April 2016 18:47:45 UTC