RTCP BYE is sent for every media stream on renegotiation, replaceTrack, or setParameters
Categories
(Core :: WebRTC: Networking, defect, P2)
Tracking
()
backlog | webrtc/webaudio+ |
People
(Reporter: solmaks, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [WebRTC])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36 Steps to reproduce: 1. Negotiate a sendrecv audio stream between 2 instances of PC - PC1 and PC2 2. Add video track to PC1, this triggers re-negotiation 3. Create offer on PC1, set it as a local description 4. Set PC1 offer as a remote description on PC2 5. Create answer on PC2 6. Set answer as a local description on PC2 Actual results: After setting local answer on PC2 RTCP BYE will be sent out for previously negotiated outgoing audio stream source, immediately followed by new RTP packets for the same source. Although this behaviour is tolerated by FF and Chrome, it is not tolerated by other WebRTC compatible implementations, and also violates RFC3550, which states that: 6.1 RTCP Packet Format BYE or APP: Other RTCP packet types, including those yet to be defined, MAY follow in any order, except that BYE SHOULD be the last packet sent with a given SSRC/CSRC. 6.3.4 Receiving an RTCP BYE Packet Except as described in Section 6.3.7 for the case when an RTCP BYE is to be transmitted, if the received packet is an RTCP BYE packet, the SSRC is checked against the member table. If present, the entry is removed from the table, and the value for members is updated. The SSRC is then checked against the sender table. If present, the entry is removed from the table, and the value for senders is updated. 6.3.7 Transmitting a BYE Packet When a participant wishes to leave a session, a BYE packet is transmitted to inform the other participants of the event. Expected results: Instead of sending RTCP BYE followed by new RTP packets for the same source, implementation should have either: * Not send RTCP BYE at all, since nothing has really changed around the outgoing audio stream or * Change SSRC of the outgoing audio stream after concluding the previous source with RTCP BYE
Comment 1•9 years ago
|
||
Likely largely due to webrtc.org code combined with how we interact with it at a renegotiation. Does chrome send the same thing?
No, Chrome implementation does not stop streaming and does not emit RTCP BYE during renegotiation, unless explicitly told to, e.g. by remote description removing send direction (e.g. remote offering sendonly).
Updated•9 years ago
|
Updated•9 years ago
|
Comment 3•9 years ago
|
||
Is there a preexisting test that would exercise this behavior (even though it doesn't check for it)?
Comment 4•9 years ago
|
||
The renegotiation mochitests would be your best bet, for instance test_peerConnection_addSecondVideoStream.html. Look for mochitests that use |addRenegotiation|, that have at least one track that doesn't go away when the renegotiation happens.
Comment 6•9 years ago
|
||
(In reply to solmaks from comment #5) > Is there a chance this would be addressed any time soon? Yes, I am working on it, and hope to have something in the next week or two.
Comment 7•7 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Chrome has similar behaviour, for instance, I've caught it sending a BYE as a result of a call to SetLocalDescription, so I think this is something we'd want to fix in upstream webrtc.org first and then backport to Firefox. Comment 2 may have been accurate when this bug was originally filed, but that is not the case anymore.
Since this blocks spec compatibility for mute/unmute on RTCP BYE, I think this should be a P2. I'll reset the assignee, because I think this will end up being a large project and we should plan for it as such rather than leaving it in Nico's backlog.
Comment 9•4 years ago
|
||
Unfortunately, Chrome covers up their lack of RTCP BYE muting with their fake mute behavior (crbug 941740) which seems to listen for lack of packets instead, which is in no standard.
Comment 10•3 years ago
|
||
I can confirm Chrome (89-92) also sends RTCP BYE on renegotiations. See STRs in bug 1704947.
Comment 11•3 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #10)
I can confirm Chrome (89-92) also sends RTCP BYE on renegotiations. See STRs in bug 1704947.
Turns out Chrome only sends BYE when it's the offerer: it offers a=extmap-allow-mixed
which sends BYE on lack of support, a recent regression.
So that's a red herring for us, because in many cases (like MS Teams), the SFU is the offerer, and things work wo/any BYEs in Chrome but not Firefox.
The main obstacle for Firefox then remains bug 1685671.
Comment 12•3 years ago
|
||
Turns out this is fixed by bug 1654112. 🎉 I've verified using the following fiddles:
- No-op renegotiation: https://jsfiddle.net/jib1/gyxu73ha/
- setParameters: https://jsfiddle.net/jib1/1fcr7ozk/
- replaceTrack: https://jsfiddle.net/jib1/ef4trvbd/
I'll open a new issue to turn those into WPT tests.
Updated•3 years ago
|
Comment 13•2 years ago
|
||
It is possible that bug 1812293 has fixed this, or at least made it better. Also, pehrsons is working on simplifications to the mute/unmute stuff right now, which may also make this better.
Needinfoing pehrsons just to put this on his radar.
Comment 14•2 years ago
|
||
Wait, it looks like this is already closed. We need to update some wpt bug links...
Description
•