Bug 191202 – sender.replaceTrack() fails with InvalidStateError if the transceiver.direction is "inactive"

• Component: WebRTC
• Status: RESOLVED FIXED

[Iñaki Baz]

Scenario:

* A peerconnection with a sending track (no receiving tracks).

transceiver = pc.addTransceiver(track, { direction: 'sendonly' });

* Later I remove the track:

pc.removeTrack(transceiver.sender);

* When calling pc.createOffer() it generates a m= section with a=inactive (it was a=sendonly before, so it makes sense). The remote SDP answer has also a=inactive as per spec (but it does NOT have port=0 in the m line).

* Later I want to reuse the same transceiver (which is NOT stopped, this is: transceiver.stopped is false) for sending a new track:

const promise = transceiver.sender.replaceTrack(newTrack);

* However, promise is rejected with "InvalidStateError: The object is in an invalid state." which IMHO doesnot make any sense. What does "invalid state" mean for a RtpSender? Yes, `pc.removeTrack(transceiver.sender)` was called before this, but it should not mean that the transceiver becomes unusable for sending new media. It's not stopped, it's just inactive. I should be able to set a new sending track.

NOTE: This works fine in Chrome 72.

[Iñaki Baz]

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.

[Iñaki Baz]

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.

[youenn fablet]

(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()

[youenn fablet]

Created attachment 353842 [details]
Patch

[Iñaki Baz]

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.

[Iñaki Baz]

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ñaki Baz]

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

[WebKit Commit Bot]

Comment on attachment 353842 [details]
Patch

Clearing flags on attachment: 353842

Committed r237916: <https://trac.webkit.org/changeset/237916>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/45866014>

[youenn fablet]

*** Bug 191698 has been marked as a duplicate of this bug. ***