RTCRtpSender not checking media track state or identity constraints in constructor

[murillo128]

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.

[robin-raymond]

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

[aboba]

There is no mention of peerIdentity constraints in Media Capture and Streams:
http://w3c.github.io/mediacapture-main/#media-track-supported-constraints

Also, IncompatibleMediaStreamTrackError appears to have been removed from WebRTC 1.0:
http://w3c.github.io/webrtc-pc/

[murillo128]

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.

[robin-raymond]

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]

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]

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.

[murillo128]

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

[robin-raymond]

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

[murillo128]

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

I am fine to whatever 1.0 says

[elagerway]

Closing, this needs to be taken up in the WebRTC Working Group as per my recent message to the mail list:
https://lists.w3.org/Archives/Public/public-ortc/2016Apr/0165.html