Will Self-Hosted Collaboration Software Support Voice and Video Calls? A Network Readiness Checklist

Start with the calls your team actually needs

“Supports calls” is not a complete deployment requirement. Before comparing hosting options, define who will call whom, which clients they will use, and where those people will connect from. A team whose members share one office network may face different constraints from one with external guests and users on home or mobile connections.

Also confirm which capabilities matter. Voice, video, screen sharing, and calls with external participants may have different support or configuration requirements. [Mattermost’s Calls deployment guide](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) describes Calls as a self-hosted feature for audio calling and screen sharing. That capability description alone does not establish that every client or user network will work in your environment.

• List the required call features, participant types, and client types, such as browser or native application.
• Include the networks people will use: office, home, mobile, and any guest or partner networks.
• Decide what failure is acceptable. For example, is a fallback to audio sufficient if video cannot connect?

Separate web access, signaling, and media

A useful first step is to read the application’s current official deployment documentation and map its requirements into distinct paths. The web interface is what users load; signaling is the exchange used to establish or manage a call; media is the audio and video traffic. The application documentation may describe these paths separately, or use different terminology.

Being able to sign in through a browser confirms web access, not necessarily that call setup or two-way media will work. Record the documented requirements for each path rather than assuming that a working website proves calling readiness.

[Nextcloud’s description of Talk](https://nextcloud.com/blog/nextcloud-talk-open-source-online-video-conferencing-software/) identifies it as open-source online video conferencing software supporting chats, calls, webinars, and broadcasting. That capability description is useful for identifying the product’s scope, but it does not by itself specify the network setup needed for your users.

• Find the vendor’s deployment documentation for the exact application and deployment model you plan to use.
• Note the documented requirements for the web interface, call signaling, and media separately.
• Check whether requirements differ by client, feature, or deployment component; do not fill gaps with assumptions.

Check protocols, ports, firewalls, NAT, and relays

Use the official documentation to make a network-change list. Record the protocols and ports it specifies, whether connections need to be allowed inbound, outbound, or both, and which systems or endpoints are involved. Do not copy a generic port list from another collaboration product: requirements can differ, and the available product descriptions do not establish specific port or firewall values.

Look for the documented behavior when participants are behind NAT or restrictive firewalls. In particular, verify whether direct media connections are expected to work, whether a TURN relay is supported or required in some circumstances, and who operates that relay. If the documentation does not answer these questions, treat them as open deployment questions and ask the application vendor or hosting provider before rollout.

A relay can be a dependency rather than an optional detail. Establish whether it must be deployed, reachable, configured in the application, or maintained separately; confirm those points from the product’s documentation rather than assuming. The [Mattermost Calls deployment guide](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) is a primary-source starting point for Mattermost, but the available capability information does not establish specific port, NAT, or relay requirements.

• Create a table of documented protocol, port, direction, destination, and purpose.
• Ask network administrators to verify that the required traffic is permitted on relevant office and remote networks.
• Confirm the documented NAT traversal and TURN behavior, including relay ownership and operational responsibility.
• Mark any undocumented requirement as unverified; do not treat a successful login as evidence that media traffic is permitted.

Verify TLS, domains, and reverse-proxy assumptions

Check how the application expects its public domain, TLS termination, and any reverse proxy to be configured. Identify which component handles each connection and whether the official documentation gives additional requirements for calls beyond the web interface. Do not assume that a particular proxy or TLS setup is supported for every call feature unless the application documentation says so.

A valid HTTPS page is not a complete call-path test. It can establish that the web endpoint is reachable while leaving signaling or media requirements untested. If your architecture places a proxy in front of the application, compare the documented call architecture with the actual routing and certificate setup, and resolve any ambiguity before inviting users to rely on calls.

[Airbip’s product information](https://airbip.com) describes automated routing and TLS certificates through Traefik and Let’s Encrypt, and support for an Airbip subdomain or a compatible custom domain. Those capabilities describe the web-hosting setup; they do not, by themselves, establish that a particular application’s calling features or media paths are supported in every network.

• Confirm the required public domain and TLS behavior in the application’s deployment documentation.
• Map the documented architecture to your actual proxy, DNS, and certificate arrangement.
• Ask the relevant provider or vendor to clarify any call-specific proxy or TLS requirements that are not documented.

Test with representative users, not just the server team

Once you have implemented the documented configuration, test from the networks your users will actually use. A test from the same office or server environment may miss restrictions present on home, mobile, guest, or partner networks. Include at least one restrictive network if those users are part of the intended audience.

Use a repeatable checklist: can participants start and join a call, hear one another in both directions, see video if required, and share the required content? Then test what happens when a connection is interrupted and restored. Where the application exposes whether a relay is being used, record that result; do not assume relay behavior from call quality alone.

A passing test establishes that the tested setup worked for the tested users and networks at that time. It cannot guarantee that every participant’s network, device, or later network change will behave identically. The product descriptions cited above do not prescribe a representative network-test procedure, so treat this checklist as general deployment guidance rather than a product guarantee.

• Test each required client type and the call features the team plans to use.
• Test participants on office, home, mobile, and other relevant networks, including restrictive environments where available.
• Record call setup, two-way audio, video, screen sharing if needed, reconnection, and documented relay behavior.
• Keep the date, client type, network context, and outcome so you can compare results after changes.

Choose a deployment model against verified requirements

Compare hosting options only after you have the application’s documented requirements and know which network controls you can obtain. Consider whether you can configure the required firewall rules, operate or obtain any required relay service, and investigate failures across users’ varied networks.

A managed application deployment can handle parts of the infrastructure around an application, but it does not automatically establish support for every calling feature or network path. [Airbip’s product information](https://airbip.com) describes application instances running as Docker workloads on its cloud servers, along with service lifecycle management, DNS checks, and configurable daily, weekly, and monthly backups. Evaluate those capabilities alongside—not instead of—the call-specific requirements confirmed from the application’s documentation.

If your team cannot provide a required network control or relay, or cannot support the variation in users’ networks, another deployment model or a service designed for the use case may be a better fit. Make that choice based on the verified requirements, not on the presence of a call button or a successful web login.

• Match every documented requirement to an owner: your team, the hosting provider, or the application vendor.
• Confirm any relay and network-control dependencies before committing to a deployment.
• Choose another model if a required capability or operational responsibility cannot be met.

Document ownership and retest after changes

Keep a concise record of the architecture, documented protocols and ports, DNS and TLS arrangement, proxy configuration, relay dependencies, and who owns each change. Include a troubleshooting route so users know where to report failures and administrators can distinguish web-access problems from call setup or media problems.

Plan to repeat representative tests after changes to the application, hosting arrangement, proxy, firewall, relay, or user network. A documented, repeatable check is more useful than treating one successful meeting as a permanent guarantee.

• Record the source documentation and date checked, along with any unanswered questions.
• Name owners for firewall changes, relay operation, application configuration, and user support.
• Retest after material infrastructure or network changes and update the record.