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.
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.
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
You need to log in before you can comment on or make changes to this bug.