Open Bug 1393407 Opened 7 years ago Updated 2 years ago

PeerConnection stops sending video RTP when the first m= section (audio) becomes a=inactive


(Core :: WebRTC: Signaling, enhancement, P2)

57 Branch



Tracking Status
firefox57 --- affected


(Reporter: ibc, Unassigned)


User Story


* PeerConnection sending audio (first m= section) and video (second m= section) using BUNDLE (single transport).

* The app calls pc.removeTrack(audioSender) and calls pc.createOffer, pc.setLocalDescription and pc.setRemoteDescription.

What should happen?:

* Video RTP should be still sent.

What happens?:

* No more video RTP is sent.

More info:

Once the audio RtpSender is removed from the PeerConnection and the SDP O/A ceremony done, the localDescription.sdp looks as follows:

* It does not have a=group:BUNDLE line.
* The first m= audio section has port 0, a=inactive, and doesn't have a=mid nor ICE/DTLS attributes.

It seems that Firefox becomes crazy when the m= section (in which the ICE+DTLS stuff was initially negotiated) becomes inactive, and assumes that there is no transport now.

NOTE: If I add a new audio track to the PeerConnection and do SDP O/A ceremoy, both audio and video are sent again (using same DTLS transport as before).


* Related question in public-webrtc mailing list:
      No description provided.
User Story: (updated)

My peerconnection is not receiving any remote audio/video track. It's just for sending audio and video. So yes, when I stop the audio `RTCRtpSender` the first m= section becomes inactive.
Rank: 15
Component: WebRTC: Audio/Video → WebRTC: Signaling
Priority: -- → P1
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
This no longer happens in Firefox 57. Once the sending audio section becomes inactive, createOffer() generates a new SDP with "a=group:BUNDLE sdparta_1", pointing to the video m section.

Even if later I close the video RtpSender (so the SDP has just a=inactive m sections) and later enable it again, video transmission works.

So good work :)
Unfortunately this still fails in the reverse direction. This is:

* PeerConnection receiving audio (first m= section) and video (second m= section) using BUNDLE (single transport).

* Call setRemoteDescription() with a SDP re-offer that makes the m=audio section inactive and makes a=group:BUNDLE point to just the m=video tag.

* The app calls pc.createAnswer() and pc.setLocalDescription().

What should happen?:

* Video RTP should be still received.

What happens?:

* No more video RTP is received.
So, it sounds like you're describing a bundle renegotiation bug, where each end has different ideas about transport reuse. In Firefox, removing the bundle tag from the bundle means that the bundle needs to create a new transport (this is because Firefox uses "transport follows m-section").

I could verify this with a test-case.
I'd say that this is already handled and explained in issue #1438534
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.