On 8/23/2017 2:01 PM, Nils Ohlmeier wrote:
On Aug 23, 2017, at 08:34, Eric Green <eric.gr...@onsip.com> wrote:
I am working on implementing renegotiation into SIP.js, specifically looking at
hold/unhold via changing SDP attributes to sendonly. This is working when
Firefox negotiates audio only, or is the person triggering the renegotiation.
The problem starts when Firefox is doing a video call and is the target of
being put on hold. The browser will receive an SDP offer with a=sendonly for
both video and audio sections of the call. I successfully apply this to the
peer connection and the peer connection changes to have-remote-offer state. I
can successfully call createAnswer, generate the RTCSessionDescription, but
when I call setLocalDescription on my peer connection with the answer from
createAnswer, the browser will lock up.
This is one of my crash reports:
https://crash-stats.mozilla.com/report/index/9de4defb-5a39-4950-9f7f-c8e060170823
I could put together a simple demo to replicate this if needed. It is happening
in both the production version of Firefox and the Developer build. Chrome is
working successfully with the same javascript.
Any thoughts on what I can do to make Firefox not crash on this?
From looking at the crash report it would be super helpful if you could send
me a way to reproduce this, e.g. point me to github page with code, or a link
to web page for testing.
Or open a bug report about it on https://bugzilla.mozilla.org
<https://bugzilla.mozilla.org/>
Which ever is easier for you.
I agree with Nils -- an example would help a lot. I suspect there's
some sort deadlock on mCodecMutex -- apparently with thread 55, which is
calling WebrtcVideoConduit::SendVideoFrame(). OnVideoFrameConverted is
called with a lock on the pipeline listener mutex. Should be trivial to
debug with an example using 'rr' (and probably trivial in gdb)
Randell Jesup, Mozilla
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
