Summary: | sender.replaceTrack() fails with InvalidStateError if the transceiver.direction is "inactive" | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Iñaki Baz <ibc> | ||||||||
Component: | WebRTC | Assignee: | youenn fablet <youennf> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | commit-queue, eric.carlson, webkit-bug-importer, youennf | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | Safari Technology Preview | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Iñaki Baz
2018-11-02 11:48:59 PDT
NOTE: My workaround for now is not trying to reuse an inactive transceiver but, instead, creating always a new transceiver and leave inactive ones unused forever. Created attachment 353801 [details]
Test script
To test this script, just open Safari 12.1, have "Develop - Experimental Features - WebRTC Unified-Plan" enabled, and paste the script in the Safari console.
In this script the "InvalidStateError" does not happen, probably because there is no full SDP OA (there is no remote SDP). Anyway, it also fails with a 100% related issue:
* The scripts gets two audio tracks and creates a sending transceiver with the first audio track.
* Then it removes it via `pc.removeTrack(micTransceiver.sender);`.
* Then it replaces the previous mic track with the second one:
```js
micTransceiver.sender.replaceTrack(micTrack2);
micTransceiver.direction = 'sendonly'; // <--- IMPORTANT
```
* However, `pc.createOffer()` generates an SDP offer with `a=inactive`.
This is: once `pc.removeTrack(sender)` is called, the corresponding transceiver becomes 100% unusable for sending a new track. Setting the transceiver.direction = "sendonly" is ignored by Safari (here the bug probably).
NOTE: The script properly works in Chrome and Firefox.
(In reply to Iñaki Baz from comment #1) > NOTE: My workaround for now is not trying to reuse an inactive transceiver > but, instead, creating always a new transceiver and leave inactive ones > unused forever. You could also try using replaceTrack(null) instead of removeTrack() Created attachment 353842 [details]
Patch
Created attachment 353847 [details]
Test script 2 with sender.replaceTrack(null)
Unfortunately calling sender.replaceTrack(null) does not set "a=inactive". Instead it remains "a=sendonly" even if I set transceiver.direction = "inactive" once the replaceTrack(null) promise resolves.
The new attached script is similar to the first one, but instead of pc.removeTrack(sender) it uses sender.replaceTrack(null).then(() => { transceiver.direction = "inactive"; }):
* Once replaceTrack(null) resolves the script changes the transceiver direction to "inactive" and generates an offer. The offer still has a=sendonly, so this is not a valid solution yet.
* And much worse: If after that I call sameSender.replaceTrack(newTrack), it generates a new audio transceiver with its corresponding new m=audio section, both with "a=sendonly". This is an important bug somewhere IMHO.
This script properly works in Chrome and Firefox works fine.
NOTE: In Safari, and when doing real SDP O/A (with pc.setRemoteDescription() and so on) changing transceiver.direction produces an exception (something like "cannot change readonly property") if I do it before the replaceTrack(null) promise resolves. This does not happen in Chrome or Firefox and the spec says nothing about when transceiver.direction can be changed. It's supposed to be changed at any time. It just happens that its effective value (pc.currentDirection) takes an effective value later, may be after a proper SDP O/A, but IMHO it should never produce an exception.
In order to not mix different issues, I've open a new one to just report the issue when setting transceiver.direction = "inactive" (which is just ignored in Safari 12.1): https://bugs.webkit.org/show_bug.cgi?id=191260 So, if you developers wish, we can handle here just the original issue related to unusable transceiver.sender once pc.removeTrack(sender) is called (for which I see there is already a patch). I've also created a separate issue for the issue "Calling sender.replaceTrack() twice produces a new transceiver and its corresponding m= section": https://bugs.webkit.org/show_bug.cgi?id=191261 Comment on attachment 353842 [details] Patch Clearing flags on attachment: 353842 Committed r237916: <https://trac.webkit.org/changeset/237916> All reviewed patches have been landed. Closing bug. *** Bug 191698 has been marked as a duplicate of this bug. *** |