Bug 192468 - Calling transceiver.stop() does not set the direction of its m= line to "inactive".
Summary: Calling transceiver.stop() does not set the direction of its m= line to "inac...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari Technology Preview
Hardware: Mac macOS 10.13
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-06 12:18 PST by Manjesh Malavalli
Modified: 2018-12-06 15:16 PST (History)
1 user (show)

See Also:


Attachments

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