Calls and meetings deployment guide
Plan the WAN path for voice and video conferencing
A reliable meeting needs the local network, WAN links, application routes and endpoint to work together. Use the following workflow to select equipment and validate the complete call path.
A meeting or phone call through the protected WAN path
- Call participantsLAN, Wi-Fi or office phones
- Mushroom clientApplication routes and QoS
- WAN connectionsWired or embedded cellular
- Peered endpointCloud service or customer server
- Call serviceMeeting platform or SIP/PBX service
Choose the deployment
| Site | Equipment and mode | Setup focus |
|---|---|---|
| Office with multiple wired WANs | Truffle with a configured peered/application tunnel. | Select enough Ethernet WAN ports and confirm the relay/server and application policy. |
| Remote or mobile site | Portabella 4000i, 4000i 5G or 4000it. | Choose modem count, carrier plans, antenna placement and supported power/installation requirements. |
| Starlink plus cellular site | A satellite Ethernet handoff plus cellular WAN paths. | Follow the Starlink and cellular deployment guide, then configure the call traffic policy. |
Configure calls and meeting traffic
- Check the local network first. Confirm the phone or meeting device has a stable LAN/Wi-Fi path. Test the microphone, camera and meeting application separately from the WAN setup.
- Identify the application flows. SIP phone services use signalling and media flows such as SIP/RTP. Browser-based and other conferencing applications can use different flows. Use the application’s approved network requirements.
- Select the tunnel and route both directions. Configure the client and relay/server so the intended flows use the protected path. Check any cloud IP or PBX firewall requirements.
- Prioritize the intended traffic. Set QoS reservations/shapers for the codec, simultaneous calls and meeting bitrate. Consider the capacity left when a WAN path is unavailable.
- Check the application during WAN changes. Monitor media quality and reconnection at the participants’ devices, alongside WAN/tunnel counters.
Validate audio and video continuity
- Run a meeting with audio, camera and screen sharing as used in the real workflow. Record the device, application, firmware, WAN mix, relay and QoS policy.
- Test under competing uploads/downloads and observe audio gaps, frozen video and application reconnects.
- On a test network, disconnect or degrade each WAN in turn while the call remains active. Observe what participants actually hear and see.
- For SIP systems, check registration, inbound and outbound calling, media in both directions and the expected source IP/firewall behaviour.
- Record latency, jitter, loss and application interruptions with the measurement interval and test conditions. Repeat the expected failure/recovery cases before relying on the deployment.
Continuity depends on the configured application path, a reachable endpoint and enough surviving bandwidth. Adaptive WAN algorithms cannot correct a failed camera, local Wi-Fi outage, unavailable meeting service or total loss of WAN connectivity.
Should I use Streamer for a two-way video meeting?
Streamer is intended to transport already encoded live video to a server or CDN. For interactive calls and meetings, select a data bonding/application-aware tunnel configuration and verify the application’s two-way traffic and QoS requirements.
Do more modems automatically guarantee better calls?
Additional usable paths can provide more capacity and resilience. Coverage, shared infrastructure, routing, latency and the application policy still matter. Validate the connection mix and remaining capacity for the call workload.