Bug 192468
Summary: | Calling transceiver.stop() does not set the direction of its m= line to "inactive". | ||
---|---|---|---|
Product: | WebKit | Reporter: | Manjesh Malavalli <mmalavalli> |
Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | bfulgham, youennf |
Priority: | P2 | ||
Version: | Safari Technology Preview | ||
Hardware: | Mac | ||
OS: | macOS 10.13 |
Manjesh Malavalli
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 | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
youenn fablet
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
(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
@Youenn: Is this bug still an issue?