Scope and the result to aim for
This is an audio-only gateway workflow for an existing private Jitsi deployment. Docker examples were source-reviewed against stable-11248-2, commit 74d3e6e, on 30 October 2026. Compose configuration was checked with dummy values; no SIP registration, provider, telephone call or real meeting was tested. It is not a turnkey recipe for every carrier. [S1][S2]
First aim for one authorized SIP call reaching one intended test meeting with audio in both directions. Add public-number and per-room PIN routing only after that smaller path is understood. The older 2017 announcement is historical service context, not proof that its public numbers or offers remain available. SIP video gateways are another implementation and are outside this audio guide. [S3]
1. Decide what the caller will use
| Requirement | What must exist before the test |
|---|---|
| A SIP device or softphone calls your configured account | An authorized SIP account, provider/PBX routing and the Jigasi gateway. [S1] |
| An ordinary phone dials a public number | A telephony service routes that number to the SIP path; check country access and charges with the provider. [S1][S3] |
| Callers enter a code to select different rooms | Your routing service must map the code to the correct conference; browser invitation details must describe that same service. [S2][S4] |
These are different jobs. A UI phone number is not evidence that a provider routes calls into your server. A SIP account is not automatically a purchased telephone number.
For the first test, use this simplified route:
Authorized SIP caller -> provider / PBX -> Jigasi -> intended Jitsi meetingThis is our conceptual map, not a complete network trace. Provider signaling and media requirements vary. [S1]
2. Prepare a matching deployment
Why: the gateway’s Compose file, image, generated configuration and core services must agree.
Do: start from the working Docker installation and identify its release. For this recipe, use docker-compose.yml and jigasi.yml from the same stable-11248-2 release. Preserve your current project name, environment file and any additional Compose overrides. Existing installations on another release should use the upgrade procedure first rather than mix files. [S2]
Check: ordinary browser meetings already work, including the bridge path. Keep a backup of the current environment and configuration. The existing CONFIG directory must include the gateway input directory prepared by the Docker installation.
The commands below assume you are in that release directory and normally use the default project name. Add your existing project/options consistently if your deployment differs. The jigasi.yml override selects SIP mode and publishes its configured UDP media range, defaulting to 20000 through 20050. Check the actual provider, host and cloud network requirements; publishing a range in Compose does not prove end-to-end reachability. [S2]
3. Configure the SIP account and gateway identity
The following is an illustrative environment block, not real credentials. It assumes a provider that explicitly supports SIP over TLS on port 5061. Replace every placeholder and use the port/transport your authorized provider requires. Provider TLS settings do not establish encryption across every call leg. [S2]
JIGASI_SIP_URI=user@sip.example.com
JIGASI_SIP_PASSWORD=REPLACE_WITH_PROVIDER_PASSWORD
JIGASI_SIP_SERVER=sip.example.com
JIGASI_SIP_PORT=5061
JIGASI_SIP_TRANSPORT=TLS
JIGASI_SIP_DEFAULT_ROOM=example-audio-room
JIGASI_XMPP_PASSWORD=REUSE_EXISTING_GENERATED_JIGASI_PASSWORDexample-audio-room is a fictional room used only to explain a fixed fallback. Join your own authorized test room and configure its expected routing. The SIP template accepts the provider account fields; the default-room property is emitted only when configured. Provider-supplied conference headers or routing can change the destination. [S1][S2]
JIGASI_XMPP_PASSWORD is the gateway’s internal Jitsi identity secret, not the SIP account password. Reuse the matching generated value already stored in your installation. On an existing deployment, rerunning the release’s password-generation script replaces several service passwords, so it is not an appropriate shortcut for adding one gateway. A fresh installation generates its service passwords during setup. [S2]
Check: the source-reviewed gateway startup requires a nonempty XMPP password. Its generated configuration is under /run/jigasi/config, built from input under /config. Use the environment and supported input files for persistent changes rather than edit generated files. [S2]
4. Validate the merged configuration, then start it
Why: catching a Compose error before recreating services separates a local configuration problem from a provider connection problem.
From your matching release directory, after replacing placeholders:
docker compose -f docker-compose.yml -f jigasi.yml config --quietCheck: configuration parsing succeeds. This verifies the merged definition only; it does not validate passwords, registration or calls. Avoid sharing a fully expanded configuration because it can include secrets. [S2][S5]
During an agreed maintenance window, start the combined stack so core services can receive their gateway-related configuration as well:
docker compose -f docker-compose.yml -f jigasi.yml up -d
docker compose -f docker-compose.yml -f jigasi.yml ps
docker compose -f docker-compose.yml -f jigasi.yml logs --tail=80 jigasiThese are deployment actions for your own server, not commands to run against an unrelated service. up can recreate affected containers. Use the same file set for later operations. Container startup is not a successful phone call. [S2][S5]
5. Verify registration, routing and audio separately
- Account: inspect gateway logs and the provider/PBX registration view. Resolve rejected credentials or transport mismatch before testing room audio. Keep account identifiers and secrets out of shared logs. [S1][S2]
- Destination: join the authorized browser test meeting, then place a permitted SIP test call through the provider/PBX route you arranged. Confirm arrival in that meeting, not just a connected call status. The room-header and default-room mechanisms need to match your routing. [S1][S2]
- Two-way audio: have consenting participants speak in turn. Record whether the phone side hears the browser and the browser hears the caller. Investigate provider media/NAT and the Jitsi media path when signaling works but reception does not.
- Departure: hang up and verify that the participant leaves. Repeat the specific route that your real callers need. Do not infer that all regional numbers, authentication modes or networks work from one test.
This sequence is a recommended acceptance test, not a report of a call completed for this article. Use the one-way audio owner for the Jitsi side of reception problems; provider-specific failures still need the provider’s diagnostics.
6. Add invitation numbers and conference-code mapping
The reviewed web configuration supports DIALIN_NUMBERS_URL and CONFCODE_URL for invitation information and conference mapping. Supplying a URL does not create the backend service or route a carrier call. Use endpoints owned by, or explicitly supported for, your telephony deployment. Test that the displayed number and code reach the correct private meeting. [S4]
This guide deliberately stops short of inventing a carrier-independent PIN service. A fixed-room SIP test is not a completed multi-room public-number product. A room password is also a different access mechanism. Verify how lobbies and authentication apply to your gateway before offering the route to users. [S1][S4]
Failure checks and rollback
| Observation | Next check |
|---|---|
| Gateway exits before connecting | Required XMPP secret, matching release/input and startup logs. [S2] |
| SIP account is rejected | Provider account, server, port and transport; ask the provider for its registration result. [S1][S2] |
| Call reaches another room | Provider room headers, default-room configuration and mapper agreement. [S1][S2][S4] |
| Caller arrives but one direction is silent | Separate provider media/NAT and Jitsi media checks; keep signaling evidence separate. |
| Invitation contains no usable number | Confirm the actual telephony service and number/code endpoints, not merely gateway startup. [S4] |
To pause the added gateway while investigating, use the same project/options and file set:
docker compose -f docker-compose.yml -f jigasi.yml stop jigasiThis stops gateway service and affects phone participation. Restore previous configuration deliberately if needed; do not delete core-service volumes to diagnose a SIP problem. [S5]
Debian/Ubuntu packages and maintenance
The package-based path uses host services and /etc/jitsi/jigasi/sip-communicator.properties, rather than Docker’s generated /run file. Follow the official Jigasi package instructions and secure-domain guidance for your release. Do not paste Docker environment names into a Java properties file and expect the package service to interpret them. [S1]
- [S1] Official Jigasi documentation, checked 30 October 2026: SIP gateway, conference selection and package configuration.
- [S2] Docker stable-11248-2 gateway Compose, SIP template, base template, startup configuration and password generator.
- [S3] Official 2017 telephony announcement and 2024 SIP video article: historical context and distinct gateway scope, not current provider availability.
- [S4] Pinned web configuration template, dial-in/out section.
- [S5] Docker Compose config, up and stop command references.
Recheck after release/template, gateway authentication, provider routing or numbering changes. Open questions include your provider’s route, accepted transport, admission policy, PIN service and actual two-way reception. No public-service number, telephone charge or universal compatibility is promised.