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

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

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 11 Mar 2016 12:25:34 +0100
Message-ID: <CALiegfktpG34sMRy1sDdJqXuWH6R3Fpei8XoBjwokss42tHYqw@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 Friday, 11 March 2016 11:26:22 UTC

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