- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 15 Apr 2016 06:59:08 +0200
- To: public-webrtc@w3.org
I think the behavior described is a browser bug, and should be dealt with as such. Den 14. april 2016 20:45, skrev Cullen Jennings: > > 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 Friday, 15 April 2016 04:59:40 UTC