RTCRtpSender.setTransport may raise a IncompatibleMediaStreamTrackError due to identity check

[murillo128]

The RTCRtpSender needs to ensure that the transport identity matches the media track requested identity.

This is only done currently when changing the track:

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

but it is not checked when the transport is changed.

When the transport is changed, the transport identity has to be checked against the media track constraints and if not matching, either raise an IncompatibleMediaStreamTrackError or return a promise and reject it.

[robin-raymond]

@murillo128 which transport is changed?

[murillo128]

For example, auser has two transports (tA and tB) with two different peers(A and B), each one with a different identity, and does a gUM with A identity constraint.

Then he creates a sender with the track and transport tA. If then he does sender.setTransport(tB), transport tB doesn't match the identity constraint off the track

[robin-raymond]

@murillo128 Ah, I see, yes, setTransport() vs setTrack(), one mapping has exception, the other does not.

Yes, this issue is valid and needs a fix.

I'm also thinking this is another reason these might need to need Promises result because I'm not convinced this kind of check can always be done synchronously. It might not even be possible as an exception.

[murillo128]

I also think all sender methods should return a promise.
El 14/4/2016 22:23, "Robin Raymond" notifications@github.com escribió:

@murillo128 https://github.com/murillo128 Ah, I see, yes, setTransport()
vs setTrack(), one mapping has exception, the other does not.

Yes, this issue is valid and needs a fix.

I'm also thinking this is another reason these might need to need Promises
result because I'm not convinced this kind of check can always be done
synchronously. It might not even be possible as an exception.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#467 (comment)

[robin-raymond]

I also think all sender methods should return a promise.

@murillo128 I'm not sure of "all" but certainly there is an issue outstanding on the RTCRtpSender.send() returning a promise and your issue above suggests setTransport() needs to be a promise result. If you feel other APIs require promises too then you should file issues on each and explain why it is required. Issues are easier to get resolved if they stay as focused as possible.

[robin-raymond]

$related #468

This peerIdentity stuff has been removed from 1.0 and changed to "do not send". No more exception, nor promise related issues.

[robin-raymond]

Currently a 1.0 compatibility issue, need to strip errors/promise resolution issues for peerIdentity, we need to fix, and we will follow lead of webrtc 1.0 on this one. They currently say "don't transmit" so that's what we will do too.

[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