W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2016

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

From: Cullen Jennings <fluffy@iii.ca>
Date: Thu, 14 Apr 2016 12:45:37 -0600
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <9ED06304-58CA-4270-8BF9-81D45EE3E328@iii.ca>
To: Iñaki Baz Castillo <ibc@aliax.net>

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

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