Jitsi meeting transcription

The bridge-based path starts at the videobridge, which already carries each participant's media. The bridge forwards each participant's Opus audio over a WebSocket to a transcription service. That service relays the audio to the speech provider you configured, which the Jitsi handbook lists as OpenAI, Deepgram, Google Gemini or xAI, and streams the results back into the conference. Before you design the network, confirm this path with your team, because each hop is a connection you must secure, monitor and document. The bridge is the sender in this design, so audio does not need to pass through a SIP gateway the way it does on the deprecated Jigasi path.

The reference transcription service is opus-transcriber-proxy, a Node.js application configured through environment variables. It listens on port 8080 and exposes a /transcribe WebSocket endpoint, which is the address the videobridge connects to. Provider credentials and options are set in the environment of that process, so they belong in your deployment tooling and secrets store, not in a shared configuration file. Confirm the exact variable names, defaults and transport settings against the Jitsi handbook transcription page and the proxy's own documentation for the version you deploy, since the handbook is the source for how the service is wired into the bridge.

The network consequences follow directly from that data path. The rule that matters most is between the videobridge host and the proxy host on the proxy's listening port, which is 8080 by default. Browser traffic does not change: participants still reach the web server on 80/TCP and 443/TCP and media on 10000/UDP, as the Debian and Ubuntu quick start describes. The proxy then makes outbound connections to the provider's API, so you need an egress rule for those destinations. Decide where the proxy runs, on the bridge host, on a separate virtual machine, or in a Docker network alongside the other containers. Co-location means fewer internal firewall rules. A separate host lets you restrict egress and scale transcription independently, but it adds a hop to monitor.

If you use a self-hosted model, the egress model changes. Enabling ENABLE_OPENAI_CUSTOM_PROVIDER lets the service use any OpenAI-compatible transcription API, including an in-house model, so the proxy's outbound traffic goes to your inference host instead of a public provider. That can keep audio inside your network, but it moves capacity planning, model quality and availability onto your team. Ask the vendor or model owner for the request format and expected concurrency, and test with a sample conference. Before go-live, draw each hop on one diagram, list every port and destination, confirm which outbound addresses your chosen provider needs, and record who owns each component.

The Jitsi handbook marks Jigasi transcription as deprecated, says it will be removed in a future release, and directs new deployments to the bridge-based transcription path. If your self-hosted Jitsi Meet still uses Jigasi for transcription, plan the move now, while the legacy setup still works and you have time to compare results. Treat the migration as a controlled change with a test phase, a cutover date and a rollback plan, not as a configuration tweak you make during an incident. The handbook's own wording on removal timing is the authority here, so check it again before you set your schedule.

Start with an inventory. In the official Docker setup, jigasi runs as its own container that acts as a SIP gateway, and the older transcription option is carried in that same container and configured through the .env file. List every transcription-related variable in your .env, the speech-to-text backend each one points to, the credentials and API keys it uses, and any configuration files or volume mounts attached to the jigasi container. Then record what the container does besides transcription. If you use SIP dial-in, that function has to survive the migration, so it must be documented separately. Finally, ask the people who use transcripts which outputs they rely on, such as language settings, speaker labels, export formats or stored transcript files. Confirm each feature against the current handbook, because variable names and defaults can change between releases.

Next, run both paths in a test environment that mirrors production as closely as you can. Keep Jigasi transcription on in one test copy and enable the bridge-based service, configured as described in the transcription guidance, in another. Use the same test meetings with the same participants, microphones, languages and accents, and compare the output side by side. Score word accuracy against a reference transcript that you write yourself, and also check latency, speaker attribution, punctuation, behavior during silence and the handling of overlapping speakers. Do not assume the two paths will match. Write down every difference, decide which ones matter to your users, and record which Jigasi features you need to confirm are supported on the new path before you commit to a cutover.

When the test results are acceptable, schedule a cutover window and change the transcription settings in .env on the production stack. Keep copies of the previous .env file and the container images so you can roll back quickly if the new path fails. Verify transcripts in a small pilot group before opening the change to all users. If the jigasi container still handles SIP dial-in, keep it running but disable its transcription setting, and confirm that dial-in still works after the change. Once the new path has run stably for a period you define in your own operations policy, remove the legacy transcription variables, delete the backend credentials for services you no longer use, rotate any shared keys, and update runbooks and monitoring so they no longer reference the old path.

The main decision is where meeting audio goes for transcription. In the bridge-based path, the videobridge forwards each participant's Opus audio over a WebSocket to a transcription service, which relays it to a speech-to-text provider and streams results back into the conference. The reference service, opus-transcriber-proxy, can send audio to OpenAI, Deepgram, Google Gemini or xAI. Those hosted options move recordings of your meetings to a third party outside your infrastructure. The alternative is to set ENABLE_OPENAI_CUSTOM_PROVIDER so the service calls an OpenAI-compatible transcription API that you run, such as an in-house self-hosted model. That keeps audio inside your boundary, but it moves model operation to your team.

Several drivers should be settled before anyone compares accuracy. First, confirm with legal and privacy counsel whether your contracts, data protection obligations or sector rules allow audio to leave your environment, and whether hosted providers may retain or use it for training under their terms. Second, check language coverage for the languages your staff and clients actually speak. Third, weigh the capacity a self-hosted model needs, which depends on the model you choose, the number of concurrent meetings and whether it runs on GPU or CPU; ask the model vendor for sizing guidance rather than assuming. Fourth, measure latency, since captions that trail the speaker by a long delay lose their value. Finally, decide who operates the model, including patching, monitoring, scaling and what happens to transcription when the endpoint is unavailable.

Accuracy has to be tested on your own meetings, not on vendor demonstrations. Record a set of internal meetings with consent, covering the accents of your staff, your product names, acronyms, client and project terms, and typical background noise. Run the same recordings through each candidate backend and compare the transcripts. Score word accuracy where you can, and have reviewers check how well the key terms and names are captured, since those are what readers search for later. Measure end-to-end delay from speech to caption on the same network path your users take. Store these test recordings under the same access and retention controls you would apply to live meeting audio.

Before committing to a self-hosted endpoint, confirm its API compatibility with the Jitsi handbook's transcription documentation. Check the request format, the endpoint path, how authentication is passed, the shape of the response and whether partial results are supported, because the bridge-based service expects a specific interaction pattern. Confirm which settings the proxy passes through to the endpoint and which it ignores. Do not choose the deprecated Jigasi transcription path for a new deployment, because the Jitsi handbook says it will be removed in a future release and that new deployments should use the bridge-based path. Ask for the compatibility check, the test results and the operating runbook in writing before you fix the backend.