A meeting page can load, a moderator can appear authenticated, and two participants can still fail to exchange media. Treating all of those as one connectivity check makes Jitsi difficult to troubleshoot.

I keep the meeting stack separate from the CRM. The CRM generates a random room reference and stores the join information; Jitsi owns meeting access and media handling. The CRM does not need Jitsi administration credentials just to construct a room reference.

There are several independent paths

The web interface uses HTTPS. Authentication needs a working identity-provider flow and token verification. Conference control involves the Jitsi services. Audio and video need a usable media path, with TURN available for supported fallback scenarios.

A reverse proxy serving the web interface does not automatically solve UDP media connectivity. Likewise, opening a media port does not fix an incorrect token audience.

The service layout keeps Prosody, Jicofo, and bridge management endpoints internal, while publishing only the interfaces required for clients.

A resolver difference broke key verification

One concrete issue came from a same-host rootless deployment. The host could reach the identity provider's key endpoint, but Prosody could not reach it through the public server address.

A host-gateway mapping provided the intended local network route while retaining the public HTTPS hostname. That preserved certificate verification and the expected issuer identity.

However, a shell request inside a container was still not the complete test. Prosody's native resolver did not automatically use the hosts-file mapping. The deployment needed an explicit native resolver setting, loaded before the meeting configuration.

The lesson is specific and useful: test key retrieval through the process that verifies the token. A successful command-line HTTP request may use a different resolver path.

Room creation and guest admission need separate tests

Only authenticated hosts should be able to start rooms in this profile. Guests can wait in a lobby and join under the configured policy.

A random room identifier makes guessing less practical, but it is not a replacement for authorization. Room references can be forwarded, logged, or copied.

I also keep saving a CRM meeting separate from sending an invitation. Editing a description should not unexpectedly notify everyone or regenerate the room reference. Those are distinct side effects with different retry consequences.

TURN has its own operational boundary

The fallback service runs separately and uses short-lived credentials rather than permanent guest accounts. Its certificate must be readable by the rootless service without exposing the entire certificate-management directory.

The deployment includes a controlled certificate-copy and restart mechanism. That is another producer-to-consumer handoff that needs checking after renewal.

For acceptance, I want moderator login, denied guest room creation, lobby admission, and actual two-party audio/video tested independently. A test from a different network is especially valuable because two clients on one friendly network do not exercise the fallback path.