RTCP BYE is sent for every re-negotiated media stream

NEW
Assigned to

Status

()

Core
WebRTC: Networking
P3
normal
Rank:
28
2 years ago
28 days ago

People

(Reporter: solmaks, Assigned: ng)

Tracking

Trunk
x86_64
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC])

(Reporter)

Description

2 years ago
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
(Reporter)

Updated

2 years ago
Component: Untriaged → Untriaged
OS: Unspecified → Mac OS X
Product: Firefox → Core
Hardware: Unspecified → x86_64
Whiteboard: [WebRTC]

Updated

2 years ago
Component: Untriaged → WebRTC: Networking
Likely largely due to webrtc.org code combined with how we interact with it at a renegotiation.

Does chrome send the same thing?
Status: UNCONFIRMED → NEW
backlog: --- → webrtc/webaudio+
Rank: 33
Ever confirmed: true
Flags: needinfo?(solmaks)
Priority: -- → P3
(Reporter)

Comment 2

2 years ago
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).
Flags: needinfo?(solmaks)

Updated

2 years ago
Rank: 33 → 28
Priority: P3 → P2
Assignee: nobody → na-g
(Assignee)

Comment 3

2 years ago
Is there a preexisting test that would exercise this behavior (even though it doesn't check for it)?

Comment 4

2 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.
(Reporter)

Comment 5

2 years ago
Is there a chance this would be addressed any time soon?
(Assignee)

Comment 6

2 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.
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.