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

Throw InvalidAccessError if removeTrack is called with invalid sender #844

Merged

Conversation

taylor-b
Copy link
Contributor

Fixes issue #727. "invalid sender" refers to one that was created by
another RTCPeerConnection. The working group agreed to this at TPAC
2016.

…der.

Fixes issue w3c#727. "invalid sender" refers to one that was created by
another RTCPeerConnection. The working group agreed to this at TPAC
2016.
@taylor-b
Copy link
Contributor Author

Note that since transceivers never go away, senders also never go away. Which means the check for "was this sender created by this peer connection?" simplifies to "is this sender in this peer connection's set of senders?"

@adam-be
Copy link
Member

adam-be commented Oct 6, 2016

LGTM. Good to get rid of the old language that assumed that senders get removed from the 'sender set'.

@alvestrand alvestrand merged commit b7373c2 into w3c:master Oct 6, 2016
taylor-b pushed a commit to taylor-b/webrtc-pc that referenced this pull request Oct 7, 2016
In PR w3c#844, the intent was to throw an exception when the sender wasn't created
by the connection on which the method was called. And the assumption was that
senders are never removed, so the algorithm can simply check if it's in the
connection's set of senders.

But something I didn't consider is that rollbacks are able to remove
transceivers (and thus senders). So more clarity is needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants