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
Categories
(Core :: WebRTC: Signaling, enhancement, P2)
Tracking
()
NEW
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.
Reporter | ||
Updated•7 years ago
|
User Story: (updated)
Reporter | ||
Comment 1•7 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.
Updated•7 years ago
|
Rank: 15
Component: WebRTC: Audio/Video → WebRTC: Signaling
Priority: -- → P1
Comment 2•7 years ago
|
||
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Reporter | ||
Comment 3•6 years 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•6 years 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.
Comment 5•6 years ago
|
||
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•6 years ago
|
||
I'd say that this is already handled and explained in issue #1438534
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•