1463838 - Closing RTCPeerConnection does not trigger RTCP BYE in Firefox 60

Status: RESOLVED DUPLICATE of bug 1654112

(Core :: WebRTC: Networking, defect, P2)

Description

[wilhelm.wanecek]

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

[Gingerbread Man]

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

[Byron Campen [:bwc]]

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...

Comment 3

[wilhelm.wanecek]

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

[Byron Campen [:bwc]]

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

[Alex Chronopoulos [:achronop]]

NI Byron to confirm or not this issue when he is ready.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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 7

[wilhelm.wanecek]

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

[Byron Campen [:bwc]]

(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.

Comment 9

[Andreas Pehrson [:pehrsons]]

I am fixing this in bug 1654112: D124370, D124371, D124372.

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

[Andreas Pehrson [:pehrsons]]

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.