Skip to content

Jackal for video call signalling over SCION

mmalesev edited this page Nov 1, 2021 · 2 revisions

The end goal for this project is using jackal for signalling in a group video call over SCION. This document summarizes the progress so far, suggests next steps, as well as lessons learned.

Progress

The current version of netsec-ethz/jackal suppports server-to-server communication over SCION using QUIC. It also supports RAINS as a name resolution protocol. The scion test in CircleCI tests this functionality.

Once the Multi-user chat (MUC) pull request has been merged, it will also support groupchats. The steps required to finish the merge are listed below. The groupchat test in CircleCI tests this functionality.

It is important to note that the original jackal project has gone through the complete service rewrite, and this fork is no longer compatible with it. Therefore, any changes here cannot be merged there, and vice versa.

Short term next steps

MUC merge

The first next step would be to merge the Groupchat PR. The two things needed for this are updating the scion/scionlab version used in the project, and doing the code review. Updating the scion/scionlab version also requires updating the scion integration test, which is currently failing.

Locked groupchat room by default

The MUC extension specification requires every new room to be locked by default. Only upon the room owner configuring it, it becomes unlocked. However, since profanity is the xmpp client used in the integration tests, and room unlocking doesn't work there, the rooms are currently unlocked immediately. This needs to be updated once the profanity fixes this issue, or we decide to use a different client in the tests.

MUC integration test improvement

Currently, integration tests use profanity as the xmpp client. This is limiting since some functionality, (e.g. sending a message to everyone in the group) cannot be automated. It would be useful to write a small mock client that sends custom XMLs to the server, so that any client behavior can be mimicked in the tests.

Long term next steps

Client-to-server over SCION

In order to have end-to-end signalling over SCION, jackal needs to support client-to-server communication over SCION/QUIC. This should be straightforward, since c2s communication is very similar to s2s. However, it requires a client that supports XMPP and SCION, and this does not exist at the moment.

Switching to the rewritten jackal

The original jackal project has been completely rewritten and seems to be in active development at the moment. If this continues, it might be worth it to implement SCION/QUIC for that version of the project. However, it is not clear how helpful the current progress in this repository would be in this transition.

Lessons learned

  • The main XMPP client during the jackal development has been Psi. Profanity and Gajim have also been used.
  • For generating valid self-signed certificates for the server I suggest either following this post or using generateSelfSignedCertificate function from util/tls.
  • Jingle and Muji extensions are both needed to do groupchat signalling over XMPP. However, both of those are client-side protocols, so jackal should just forward them to the clients as regular XML stanzas. Therefore, no additional work on jackal is needed to support them.
  • In the configuration YAML file, setting storage type to memory allows you to use local memory for storage. This way you do not have to set up a MySQL or PostgreSQL database in order to run jackal.
  • The last golang version that jackal works with is 1.14.
  • If you are trying to understand XEP-0045 for the first time, estimate it to take you quite a bit of time, it is convoluted.