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

Success & Failure Callbacks in RTCRtpSender.setTrack #148

aboba opened this issue Sep 3, 2014 · 4 comments

Success & Failure Callbacks in RTCRtpSender.setTrack #148

aboba opened this issue Sep 3, 2014 · 4 comments


Copy link

aboba commented Sep 3, 2014

Mozilla proposal for RTCRtpSender.replaceTrack method:

Difference from RTCRtpSender.setTrack is use of a success and failure callback.

Copy link
Contributor Author

aboba commented Sep 3, 2014

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Oct 14, 2014

Address questions about RTCRtpCodecCapability.preferredPayloadType, as noted in: Issue w3c#147
Address questions about RTCRtpSender.setTrack() error handling, as noted in: Issue w3c#148
Partially address 'automatic' use of scalable video coding (in RTCRtpReceiver.receive()) as noted in: Issue w3c#149
Renamed RTCIceListener to RTCIceGatherer as noted in: Issue w3c#150
Added text on multiplexing of STUN, TURN, DTLS and RTP/RTCP, as noted in: Issue w3c#151
Address issue with queueing of candidate events within the RTCIceGatherer, as noted in: Issue w3c#152
Clarify behavior of RTCRtpReceiver.getCapabilities(kind), as noted in: Issue w3c#153
@aboba aboba removed the 1.1 label Dec 11, 2014
Copy link
Contributor Author

aboba commented Apr 15, 2015

WebRTC 1.0 PR for replaceTrack:

Copy link
Contributor Author

aboba commented Apr 19, 2015

Proposal is to change setTrack to a Promise for consistency with WebRTC 1.0.

Copy link
Contributor Author

aboba commented Apr 20, 2015

Here is the proposed replacement text in Section 6.3.2:

Attempts to replace the track being sent with another track provided.

When the setTrack() method is invoked, the user agent must run the following steps:

Let p be a new promise.

Let withTrack be the argument to this method.

Run the following steps asynchronously:

If withTrack.kind differs from RTCRtpSender.track.kind or if withTrack has different peerIdentity constraints, then reject p with IncompatibleMediaStreamTrackError and abort these steps.

Set the RTCRtpSender.track attribute to withTrack, and have the sender seamlessly switch to transmitting withTrack in place of what it is sending. On the remote receiving end, the track maintains its existing grouping and id until the connection ends.
Parameter Type Nullable Optional Description
track MediaStreamTrack ✘ ✘
Return type: Promise

robin-raymond pushed a commit that referenced this issue May 7, 2015

- Clarified handling of incoming connectivity checks prior to calling iceTransport.start(), as noted in:

- Clarified handling of incoming DTLS packets, as noted in:

- Added RTCIceGatherer as an optional argument to the RTCIceTransport constructor, as noted in:

- Clarified handling of contradictory RTP/RTCP multiplexing settings, as noted in:

- Clarified error handling relating to RTCIceTransport, RTCDtlsTransport and RTCIceGatherer objects in the "closed" state, as noted in:

- Added component method and createAssociatedGatherer() method to the RTCIceGatherer object, as noted in:

- Added close() method to the RTCIceGatherer object as noted in:

- Clarified behavior of TCP candidate types, as noted in:

- Clarified behavior of iceGatherer.onlocalcandidate, as noted in:

- Updated terminology in Section 1.1 as noted in:

- Updated RTCDtlsTransportState definitions, as noted in:

- Updated RTCIceTransportState definitions, as noted in:
@aboba aboba closed this as completed May 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants