Well, indeed this is a huge problem. Basically, when the
pc.onaddstream and/or the remoteStream.onaddtrack events fire, they
provide a MediaStream or MediaStreamTrack whose id does not exist in
the remote SDP at all. In fact, the lib fails:
[JitsiMeetJS.js] <getGlobalOnErrorHandler>: UnhandledError: null
Script: null Line: null Column: null StackTrace: Error: No SSRC lines
for streamId 4F1EC7D1-2FDA-4938-8989-B82483E581CA for remote track,
media type: audio
So I suggest the following to make this work:
- Add a stream.jitsiI_id and track.jitsi_id properties on remote
MediaStream and MediaStreamTrack instances generated by the ORTC shim.
- Such a jitsi_id value will point to the corresponding stream.id of
track.id signaled in the remote SDP.
- lib-jitsi-meet should always check those jitsi_id fields (or just
use the id if jitsi_id does not exist).
2017-05-09 1:30 GMT+02:00 Iñaki Baz Castillo <email@example.com>:
2017-05-09 0:51 GMT+02:00 Iñaki Baz Castillo <firstname.lastname@example.org>:
There is no way to manually create a MediaStream object with a given
id. Instead such a id is a read-only and internally generated
attribute. The ORTC API does not expose MediaStream objects at all,
but just MediaStreamTracks. So the shim manually creates MediaStream
When inspecting the remote SDP, both MediaStream.id and
MediaStreamTrack.id are signaled (msid and/or mslabel+label in a=ssrc
lines). However, I won't be able to replicate the remote
Is this a problem for the lib? Does the lib relies on remote
MediaStreams matching the id signaled in the remote SDP?
BTW: the same for remote MediaStreamTrack.id. In ORTC remote tracks
are created after calling RTCRtpReceiver.receive(), and they have a
random read-only id attribute.
I hope lib-jitsi.meet, just relies on SSRC values to associate tracks and users.
Iñaki Baz Castillo