Open Bug 1393407 Opened 8 years ago Updated 9 months ago

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

Categories

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

Product:
Core
Component:
WebRTC: Signaling
Version:
57 Branch
Type:
enhancement

Tracking

()

Tracking Flags:
Tracking Status
firefox57 --- affected

People

(Reporter: ibc, Unassigned)

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
No description provided.
User Story: (updated)
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
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
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.