wilhelm.wanecek Reporter
	Description • 6 years ago

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.

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

	Byron Campen [:bwc]
	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...

	wilhelm.wanecek 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? :)

	Byron Campen [:bwc]
	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.

	Alex Chronopoulos [:achronop]
	Comment 5 • 6 years ago

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

	Jan-Ivar Bruaroey [:jib] (needinfo? me)
	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

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

	Byron Campen [:bwc]
	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.