Bug 192468

Summary: Calling transceiver.stop() does not set the direction of its m= line to "inactive".
Product: WebKit Reporter: Manjesh Malavalli <mmalavalli>
Component: WebRTCAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: bfulgham, youennf
Priority: P2    
Version: Safari Technology Preview   
Hardware: Mac   
OS: macOS 10.13   

Manjesh Malavalli
Reported 2018-12-06 12:18:52 PST
Steps to reproduce: Run this JSFiddle in a new tab: https://jsfiddle.net/nt0j39xL/ Expected behavior: When the first transceiver is stopped and a second one is added, the subsequent offer should set the direction for the first m= line to "inactive" (run the JSFiddle on Firefox). Actual behavior: The direction for the first m= line is still set to "sendrecv". Effect: The RTCPeerConnection fails to set the offer.
Attachments
youenn fablet
Comment 1 2018-12-06 14:51:06 PST
Thanks for the report, I reproed the issue and the m section should indeed have its port set to 0. I'll fix it. Given that max bundle is set, we will probably end up in encountering https://bugs.webkit.org/show_bug.cgi?id=191169.
youenn fablet
Comment 2 2018-12-06 15:16:20 PST
(In reply to youenn fablet from comment #1) > Thanks for the report, I reproed the issue and the m section should indeed > have its port set to 0. > I'll fix it. Actually, no, the stopped m section has its port set to 0. The way to achieve having the m line be inactive is to do: t1.direction = "inactive"; t1.stop(); This would make sense since doing t1.stop() does not change the value of t1.direction in Firefox. > Given that max bundle is set, we will probably end up in encountering > https://bugs.webkit.org/show_bug.cgi?id=191169.
Brent Fulgham
Comment 3 2022-07-01 16:16:05 PDT
@Youenn: Is this bug still an issue?
Note You need to log in before you can comment on or make changes to this bug.