Jigasi lets a SIP phone join a Jitsi Meet conference as a participant

Jigasi is a connector, and the documentation says so bluntly

The design decision that prevents a lot of confusion is stated in one line in the how it works section. Jigasi registers as a SIP client and can be called or be used by Jitsi Meet to make outgoing calls, and it is NOT a SIP server. It is just a connector that allows SIP servers and B2BUAs to connect to Jitsi Meet. The mechanism it supplies is listed explicitly: Jigasi handles the XMPP signaling, ICE, DTLS/SRTP termination and multiple-SSRC handling for them. That list is the technical substance of the project. Bridging a phone call into a video conference means translating between a signalling system with no media of its own and a conference that is built around a media bridge, and the four items named are the four hard parts of that translation. The people who need it are Jitsi Meet operators whose users include people dialling in from a desk phone or a softphone, and whose meeting records need to be searchable.

Outgoing calls start from the invite dialog, incoming calls need a room header

The two call directions work differently, and the documentation treats them as separate sections. For an outgoing call, Jigasi has to be configured and started as described in the install section, and then the telephone participant is invited from the invite dialog in the Participants pane of the Jitsi Meet application, which is described as dial-out. For an incoming call, Jigasi registers on your SIP server with some identity and accepts calls, and when it is called it expects to find a Jitsi-Conference-Room header in the invite with the name of the Jitsi Meet conference the call is to be patched through to. If no header is present it joins the room specified under the org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME config property, and the documentation notes that this is changed by editing the sipcommunciator.properties file. The example makes the mapping concrete, since a received SIP INVITE with the room header [email protected] causes Jigasi to join the conference https://meet.example.com/room1234, assuming the domain is meet.example.com.

Building from source is a clone, a Maven build and an unzip

The install path has six numbered steps and the first three are mechanical. You clone the source, build it, and extract the archive.

 git clone https://github.com/jitsi/jigasi.git

 cd jigasi
 mvn install -Dassembly.skipAssembly=false

 cd target/
 unzip jigasi-{os-version}-{version}.zip

The Maven flag is what makes the assembly happen, since the default build skips it. The archive is chosen for the target system, and the documentation names three options, jigasi-linux-x64-{version}.zip, jigasi-linux-x86-{version}.zip and jigasi-macosx-{version}.zip. The repository layout backs up the packaging story, with a debian directory for distribution packages, a jigasi-home directory holding the configuration, a script directory, a lib directory for bundled dependencies and a pom.xml at the root. The documentation also points at the quick install instructions in the jitsi-meet repository for anyone who would rather not build from source, which is the route most operators will take.

The XMPP side needs a muc component and two admin accounts

Steps four and six of the install are the ones that require you to understand your XMPP server, and Prosody is what the documentation uses as the example. You configure a muc component on the XMPP server that will be used for the brewery rooms, and for Prosody that means editing the main config file or the appropriate file under the conf.d directory and appending a block.

Component "internal.auth.meet.example.com" "muc"
    storage = "memory"
    modules_enabled = {
      "ping";
    }
    admins = { "[email protected]", "[email protected]" }
    muc_room_locking = false
    muc_room_default_public_jids = true 

The admins line is the point of the whole block, since both the focus user and the jigasi user are listed as admins of that internal component. You then register Jigasi on the XMPP server for the control room, the brewery, with prosodyctl register jigasi auth.meet.example.com topsecret, and you put the base64 encoded form of that password into the sip-communicator.properties file in place of the JIGASI_XMPP_PASSWORD_BASE64 tag. The SIP account is configured in the same file, with the JIGASI_SIPUSER tag replaced by a SIP username such as [email protected] and a base64 encoded password in place of JIGASI_SIPPWD.

Two boolean properties decide whether Jigasi dials or transcribes

The switch between the two roles is unusually simple, and it is worth understanding before you configure anything else. By default the properties org.jitsi.jigasi.ENABLE_TRANSCRIPTION=false and org.jitsi.jigasi.ENABLE_SIP=true in the jigasi-home/sip-communicator.properties file enable SIP and disable transcription, and to change this you simply set the desired property to true or false. The same file carries the credentials, since that is where the SIP username, the SIP password and the XMPP account details live. Starting the process is then a matter of running the script in the extracted directory, at which point the documentation says Jigasi registers to the XMPP server and connects to the brewery room. The single-file configuration model is a real convenience for an operator, and also a real limitation, since a deployment with several SIP trunks, several transcription providers and multiple Jitsi domains needs more than what one properties file expresses.

Transcription mode needs a hidden domain and a separate account

Running Jigasi as a transcriber rather than a gateway takes extra steps, and the reason is that a transcriber has to appear to the meeting as a participant with its own identity. You need to log in with a specific domain that is set as hidden in the jitsi-meet config, and in the Prosody config that means a VirtualHost block.

VirtualHost "recorder.meet.example.com"
  modules_enabled = {
    "ping";
  }
  authentication = "internal_hashed"

After restarting Prosody you create the transcriber account with prosodyctl register transcriber recorder.yourdomain.com jigasirecorderexamplepass. Then in the meet.example.com-config.js file you set the hidden domain and enable transcription.

config.hiddenDomain = "recorder.meet.example.com";
config.transcription = { enabled: true };

And in the Jigasi properties file you flip the roles and point the account at the recorder domain.

org.jitsi.jigasi.ENABLE_SIP=false
org.jitsi.jigasi.ENABLE_TRANSCRIPTION=true
org.jitsi.jigasi.xmpp.acc.USER_ID=transcriber@recorder.meet.example.com
org.jitsi.jigasi.xmpp.acc.PASS=jigasirecorderexamplepass
org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false
org.jitsi.jigasi.xmpp.acc.ALLOW_NON_SECURE=true

The ALLOW_NON_SECURE line is the one to look at closely, since it permits a non-secure XMPP connection for that account.

Transcription output lands as subtitles or as chat text

How the transcript reaches the meeting is decided by the format Jigasi sends. The documentation says it is possible to use Jigasi as a provider of nearly real-time transcription as well as translation while a conference is ongoing, and to serve a complete transcription after the conference is over, and that this is triggered by using the Subtitles button from the menu in jitsi-meet. If the results are sent as JSON, Jitsi Meet provides subtitles in the video, while plain text is posted in the chat. Jigasi will also provide a link to where the final, complete transcript will be served when it enters the room, if that is configured. The supported providers are listed as Google Cloud speech-to-text API, a Vosk speech recognition server, a custom flavor of Whisper and Oracle Cloud AI Speech, and for the Google path the documentation requires the Google Cloud SDK on the machine running Jigasi, installed with the Cloud apt repository and then gcloud init followed by gcloud auth application-default login, which produces the application default credentials file.

Where Jigasi is the wrong choice

The first wrong case is a team that has not already deployed Jitsi Meet, because every step of the install assumes a Prosody server with internal components, a brewery room, a focus account and an authenticated Jigasi account, and reproducing that environment is a larger project than the gateway itself. The second wrong case is a deployment that needs Jigasi to be a SIP server for other clients to register against, which the documentation rules out in as many words. The third is a meeting where the transcript must not leave the infrastructure, because the transcriber sends the audio of all participants in the room to an external speech-to-text service, and a self-hosted provider such as the Vosk server or the Whisper flavor is a different configuration exercise rather than a toggle. The fourth is a media topology that needs transcoding rather than termination, since the DTLS/SRTP termination Jigasi handles is a different job from codec translation between a SIP endpoint and a video conference, and the difference will surface as a call that connects but does not carry media well. The fifth is a team that wants SIP on a Jitsi deployment as a one-off, since the configuration cost is fixed and the benefit scales with the number of telephone participants.

Editorial conclusion

Jitsi Meet operators who need a dial-in participant in a conference, or live and post-conference subtitles, are the people Jigasi is for, and the fact that the same process can be switched between SIP mode and transcription mode with two properties is what makes it worth learning. It is the wrong tool for a team that has not already deployed Jitsi, since the configuration steps assume a Prosody server with internal components, a brewery room and an authenticated XMPP account, and it is the wrong tool for anyone expecting Jigasi to be a SIP server, because the documentation is explicit that it is not. Check three things before you deploy it: that your XMPP server can host the internal muc component with the focus and jigasi accounts as admins, that the transcription provider you choose accepts the audio of every participant, since the transcriber sends the audio of all participants in the room to an external speech-to-text service, and that you are comfortable with the ALLOW_NON_SECURE account setting the documentation requires for the transcriber login. The licence is Apache-2.0, the last push was on 2026-09-22, and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. jitsi/jigasi on GitHub
3. License: Apache-2.0
4. README