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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 15 Apr 2016 06:59:08 +0200
To: public-webrtc@w3.org
Message-ID: <5710751C.9080604@alvestrand.no>
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

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