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   

Description Manjesh Malavalli 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.
Comment 1 youenn fablet 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.
Comment 2 youenn fablet 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.
Comment 3 Brent Fulgham 2022-07-01 16:16:05 PDT
@Youenn: Is this bug still an issue?