Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replaceTrack(null): Allowed? #947

Closed
aboba opened this issue Nov 15, 2016 · 4 comments
Closed

replaceTrack(null): Allowed? #947

aboba opened this issue Nov 15, 2016 · 4 comments

Comments

@aboba
Copy link
Contributor

aboba commented Nov 15, 2016

Currently, the argument to replaceTrack() cannot be null. Since sender.track can be null in other methods (e.g. addTransceiver), why should it not be possible to replace an existing track with null (and cause the sender to stop sending)?

@alvestrand
Copy link
Contributor

See also #943

@aboba
Copy link
Contributor Author

aboba commented Nov 25, 2016

Some preliminary thoughts:

"Attempts to replace the track being sent with another track provided (or with a null track), without renegotiation.

To avoid track identifiers changing on the remote receiving end when a track is replaced, the sender must retain the original track identifier and stream associations and use these in subsequent negotiations.

When the replaceTrack method is invoked, the user agent must run the following steps:

Let sender be the RTCRtpSender object on which replaceTrack is invoked.
Let tranceiver be the RTCRtpTransceiver object associated with sender.
Let connection be the RTCPeerConnection object that created sender.

If transceiver.stopped is true, return a promise rejected with an InvalidStateError.

Let withTrack be the argument to this method.

If withTrack is non-null and withTrack.kind differs from the transceiver kind of transceiver, return a promise rejected with a TypeError.

If transceiver is not yet associated with a media description [JSEP] (section 3.4.1.), then set sender's track attribute to withTrack, and return a promise resolved with undefined.

Let p be a new promise.

Run the following steps in parallel:

Determine if negotiation is needed to replace the sender's existing track with withTrack. Negotiation is not needed if withTrack is null or if the sender's existing track is ended (which appears as though the track was muted). Ignore which MediaStream the track resides in and the id attribute of the track in this determination. If negotiation is needed, then reject p with InvalidModificationError and abort these steps.

If withTrack is null, have the sender stop sending, without negotiating. Otherwise, have the sender switch seamlessly to transmitting withTrack instead of the sender's existing track, without negotiating.

Queue a task that sets sender's track attribute to withTrack, and resolves p with undefined.

Return p."

@aboba
Copy link
Contributor Author

aboba commented Nov 25, 2016

@taylor-b Thoughts on the above?

@taylor-b
Copy link
Contributor

That sounds good to me.

aboba added a commit that referenced this issue Nov 30, 2016
@aboba aboba closed this as completed Dec 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants