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

NEW
Unassigned

Status

()

enhancement
P2
normal
Rank:
15
2 years ago
a year ago

People

(Reporter: ibc, Unassigned)

Tracking

57 Branch
Points:
---

Firefox Tracking Flags

(firefox57 affected)

Details

User Story

Scenario:

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


References:

* Related question in public-webrtc mailing list: https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html
Reporter

Description

2 years ago
No description provided.
Reporter

Updated

2 years ago
User Story: (updated)
Reporter

Comment 1

2 years ago
IMPORTANT INFO I FORGOT TO ADD:

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
Reporter

Comment 3

a year ago
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 :)
Reporter

Comment 4

a year ago
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.
Reporter

Comment 6

a year ago
I'd say that this is already handled and explained in issue #1438534
You need to log in before you can comment on or make changes to this bug.