Closing RTCPeerConnection does not trigger RTCP BYE in Firefox 60
Categories
(Core :: WebRTC: Networking, defect, P2)
Tracking
()
People
(Reporter: wilhelm.wanecek, Unassigned)
References
Details
(Keywords: parity-chrome)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180517113820 Steps to reproduce: I closed an RTCPeerConnection with an attached MediaStreamTrack using RTCPeerConnection.prototype.close in Firefox 60. Actual results: The session was closed, but no RTCP messages associated with the closing was sent to the receiver. Expected results: The session should have closed AND sent an RTCP BYE (203) message to the receiver, indicating that the session had ended. In comparison, an RTCP BYE is sent in Chrome, or when executing `RTCRtpReceiver.prototype.stop` instead.
Comment 1•6 years ago
|
||
If you recall for a fact that it used to work in a previous version, it would be useful if you could find the regression range. https://mozilla.github.io/mozregression/quickstart.html It's also worth checking if the bug is still reproducible in a brand new profile with the latest Nightly. https://support.mozilla.com/kb/profile-manager-create-and-remove-firefox-profiles https://www.mozilla.org/firefox/nightly/all/ If yes, then entering about:webrtc in the address bar and attaching the debugging log from there might help.
Comment 2•6 years ago
|
||
I wonder if we're just shutting down the transports before webrtc.org can send the BYE. Maybe all it would take is delaying that teardown for a second or so...
Reporter | ||
Comment 3•6 years ago
|
||
Thank you for your quick replies! Upon closer inspection this does **not** seem to be related to a regression in Firefox (there does _seem_ to be a regression in DTLS alert not being fired, or at least picked up by OpenSSL on the other end anymore, an event that triggered similar symptoms in our (proprietary) software, but that's a separate issue :)). I humbly apologize for the confusion! With that being said, as far as I can tell the initial description that no RTCP BYE is sent upon RTCPeerConnection.close, while such a message is in fact triggered with RTCRtpReceiver.stop, still stands :) I would love to create a reproducible example demonstrating the issue, but I'm not sure on how to obtain logs of RTCP messages sent and recieved in Firefox. Is this something you can help me with? I'm currently using proprietary software for the WebRTC server, which is how I've been able to debug this so far. The proprietary software may of course be source of the issue, so eliminating it from the testing and replacing it with some other means of logging is necessary to determine if Firefox is in fact at fault. about:webrtc does not seem to contain any logs regarding RTCP messages, or? :)
Comment 4•6 years ago
|
||
I suppose you could take a packet capture, but just looking at the code I can see how the RTCP BYE could get dropped. Looking into it further.
Comment 5•6 years ago
|
||
NI Byron to confirm or not this issue when he is ready.
Updated•6 years ago
|
Comment 6•6 years ago
|
||
The spec says RTCP BYE should set the muted state, so this is reproducible with: https://jsfiddle.net/jib1/y90sv8vu/ Expected result: checking connected closed video muted audio muted Actual result: checking connected closed Comparatively, Chrome appears to fire mute for video only (does anyone wanna file a crbug?): checking connected completed closed video muted In contrast to comment 0, I'm not seeing muted fire for transceiver.stop(). Since firing of muted was implemented in 59, I can't tell from JS if there's a wire regression (if we ever sent RTCP BYE). [1] http://w3c.github.io/webrtc-pc/#mediastreamtrack-network-use
Reporter | ||
Comment 7•6 years ago
|
||
Oh, that's a nifty way to check if RTCP BYE is sent! Nice! FWIW I can confirm that I cannot see any "muted" events firing upon transceiver.stop() either, which indeed contradicts the description I provided of this bug-report. I *can* still reproduce the issue locally, including the part where transceiver.stop() does trigger a RTCP BYE. If it's helpful, I can attempt creating a reproducible demo or some other way of confirming whether the issue is independent of the proprietary webrtc server I'm working with, or not. But it seems as if the bug has been confirmed anyway, so I assume that's not necessary? :) (In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #6) > The spec says RTCP BYE should set the muted state, so this is reproducible > with: https://jsfiddle.net/jib1/y90sv8vu/ > > Expected result: > checking > connected > closed > video muted > audio muted > > Actual result: > checking > connected > closed > > Comparatively, Chrome appears to fire mute for video only (does anyone wanna > file a crbug?): > > checking > connected > completed > closed > video muted > > In contrast to comment 0, I'm not seeing muted fire for transceiver.stop(). > > Since firing of muted was implemented in 59, I can't tell from JS if there's > a wire regression (if we ever sent RTCP BYE). > > [1] http://w3c.github.io/webrtc-pc/#mediastreamtrack-network-use
Comment 8•6 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #6) > The spec says RTCP BYE should set the muted state, so this is reproducible > with: https://jsfiddle.net/jib1/y90sv8vu/ > > Expected result: > checking > connected > closed > video muted > audio muted > > Actual result: > checking > connected > closed > > Comparatively, Chrome appears to fire mute for video only (does anyone wanna > file a crbug?): > > checking > connected > completed > closed > video muted > > In contrast to comment 0, I'm not seeing muted fire for transceiver.stop(). > > Since firing of muted was implemented in 59, I can't tell from JS if there's > a wire regression (if we ever sent RTCP BYE). > > [1] http://w3c.github.io/webrtc-pc/#mediastreamtrack-network-use I don't think we implement "mute on BYE" right now.
Updated•6 years ago
|
Comment 9•3 years ago
|
||
I am fixing this in bug 1654112: D124370, D124371, D124372.
Comment 10•3 years ago
|
||
AFAICT this works for me, even without bug 1654112. Using mozregression and https://jsfiddle.net/jib1/y90sv8vu/ it worked for me all the way back to bug 1595479.
Andreas, can you clarify what was fixed in comment 9? Is it intermittent?
Comment 11•3 years ago
|
||
It might have worked prior to bug 1654112 by chance; it was timing dependent. Bug 1654112 made it much more likely, which showed in tests (and pernosco). The fixes in comment 9 were to arrange the shutdown sequence of a peer connection / transceiver so that the webrtc::Call instance is destroyed before we start tearing other things down. With other things mainly being the network transport.
What would happen was that the transport and the webrtc::Call instance were destroyed in parallel on separate threads, so when the RTCP BYE was sent from the webrtc::Call in destruction, it reached a closed transport and got dropped.
You can kind of tell from the fruitful history of RTCPeerConnection-remote-track-mute.https.html.ini.
Updated•3 years ago
|
Description
•