fix(multi-stream) Reject m-lines associated with removed sources.
We do not want the client to re-use the inactive transceivers that are associated with m-lines for removed remote tracks. Rejecting a m-line on source-remove clears it from the list of available transceivers.
feat(multi-stream-support) Handle SDP munging for multiple local/remote streams per ep. (#1868)
* feat(multi-stream-support) Handle SDP munging for multiple local/remote streams/ep.
A new SDPSimulcast class is added for handling SDP munging for local and remote descriptions to handle multiple streams for both local and remote endpoints. This new class will be used only for unified plan implentation. The sdp-simucast npm package will be used for plan-b and deprecated later when all the clients switch to unified plan.
* fix(build) fix building with TS code
Use the Babel preset for the webpack bundle since Babel 7 already
understands TS and ts-loader uses tsc instead, which we configure
differently.
* squash: Add unit test and address review comments.
Co-authored-by: Saúl Ibarra Corretgé <saghul@jitsi.org>
This is just the stepping stone towards the goal of eventually having
lib-jitsi-meet fully written in JS.
- introduce ts-loader for webpack
- webpack will continue generating the UMD bundle
- tsc will generate an ES6 module
- output all bundles to dist/
ref(JingleSession) Recycle m-lines by rejecting them on source removal.
* ref(JingleSession) Recycle m-lines by rejecting them on source removal.
By rejecting the m-lines on source removal (setting the port to 0 on the associated m-line), m-lines can be recycled for new sources instead of appending new ones.
* chore(deps) update sdp-interop@latest.
fix(JingleSessionPC): Do not try to re-use inactive mid for new remote ssrcs.
The direction was marked as 'inactive' only on Firefox as Safari had audio issues when an inactive mid is re-used. Chrome (in unified-plan) needs the direction of the mid in remote desc to be set to 'inactive' for a 'removetrack' to be fired on the associated media stream whenever a remote source is removed.
feat: Adds a method that finds the SSRC of a JitsiTrack (#1338)
Adds a JitsiConference.getSsrcByTrack() method that finds the SSRC of a JitsiTrack by its SSRC. This method is currently used to get (and display) the first audio/video SSRC in the GSM popover in Jitsi Meet.
Co-authored-by: George Politis <gp@jitsi.org>
This the second stage in our E2EE journey.
Instead of using a single pre-shared passphrase for deriving the key used for
E2EE, we now establish a secure E2EE communication channel amongst peers.
This channel is implemented using libolm, using XMPP groupchat or JVB channels
as the transport.
Once the secure E2EE channel has been established each participant will generate
a random 32 byte key and exchange it over this channel.
Keys are rotated (well, just re-created at the moment) when a participant joins
or leaves.