RTCRtpSender not checking media track state or identity constraints in constructor #468

murillo128 opened this Issue Apr 13, 2016 · 10 comments


None yet

4 participants


When an RTCRtpSender is created, the following error conditions should be checked (as in the setTrack and setTransport methods)

  • if track has peerIdentity constraints not matched by transport, then raise IncompatibleMediaStreamTrackError exception.
  • If track.readyState is "ended" then rasie an IncompatibleMediaStreamTrackError exception
  • if is called when transport.state or rtcpTransport.state is "closed", throw an InvalidStateError exception.
@murillo128 murillo128 changed the title from RTCRtpSender not checking media track state or identity constraints to RTCRtpSender not checking media track state or identity constraints in constructor Apr 13, 2016
@robin-raymond robin-raymond added the 1.1 label Apr 13, 2016

Correct, these same checks in the constructor need to happen as if it was done via setTrack.

aboba commented Apr 21, 2016

There is no mention of peerIdentity constraints in Media Capture and Streams:

Also, IncompatibleMediaStreamTrackError appears to have been removed from WebRTC 1.0:

@aboba aboba removed the to-do-next-draft label Apr 21, 2016

It is still there, check 10.4 http://w3c.github.io/webrtc-pc/#isolated-media-streams

WebRTC supports calling scenarios where media is sent to a specifically identified peer, without the contents of media streams being accessible to applications. This is enabled by use of the peerIdentity parameter to getUserMedia().

An application willingly relinquishes access to media by including a peerIdentity parameter in the MediaStreamConstraints. This attribute is set to a DOMString containing the identity of a specific peer.

The MediaStreamConstraints dictionary is expanded to include the peerIdentity parameter.


From webrtc 1.0:

A track could have contents that are inaccessible to the application. This can be due to being marked with a peerIdentity option or anything that would make a track CORS cross-origin. These tracks can be supplied to the addTrack method, and have an RTCRtpSender created for them, but content must not be transmitted, unless they are also marked with peerIdentity and they meet the requirements for sending (see isolated streams and RTCPeerConnection).

So no, it would not throw an exception. It just would not transmit.

aboba commented Apr 21, 2016

WebRTC 1.0 Section 5.1.2 says:

"All other tracks that are not accessible to the application must not be sent to the peer, with silence (audio), black frames (video) or equivalently absent content being sent in place of track content."

So yes, I think that is correct.

robin-raymond commented Apr 21, 2016 edited

My recommendation:

  • strip this peer identity stuff from the sender (receiver?)
  • add this to the peer identity section:

If the MediaStreamTrack has a peerIdentity constraint applied and this track is attached to an RTCRtpSender, then do not send media over the sender unless the attached RTCDtlsTransport has validated the same peerIdentity as the MediaStreamTrack's constraint.


I think it is always better to yield an error than fail silently.

Anyway, the same behavior shall be consistent across the three methods (constructor,setMediaTrack,setTransport).


@murillo128 convince 1.0 guys of this and we will follow their lead.


@robin-raymond I have enough trying to convince you ;)

I am fine to whatever 1.0 says

@aboba aboba added a commit that referenced this issue Apr 25, 2016
@aboba aboba setTrack() operation different from replaceTrack() in WebRTC 1.0
Related to Issue #468

Closing, this needs to be taken up in the WebRTC Working Group as per my recent message to the mail list:

@elagerway elagerway closed this Apr 26, 2016
@aboba aboba added a commit that referenced this issue Apr 29, 2016
@aboba aboba Identity checks and media stream constraints
Fix for Issue #468
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment