Network requirements

YumKiosk kiosks are always-online devices. They need a steady internet connection to load the menu, maintain a WebSocket to the cloud, run live video to the agent, and run payments. None of this is demanding by modern standards, but a few gotchas can trip up operators who haven't set up a dedicated Wi-Fi network for kiosks. This page covers everything you need to tell your IT person (or yourself).

#Bandwidth

Per kiosk:

• Idle (attract screen): around 2 KB/s down, essentially nothing.
• In-session (live video): 500 Kbps down and 500 Kbps up sustained, with bursts up to 1.5 Mbps during high-motion frames. This is a conservative estimate for Agora's 360p-to-720p adaptive streams.
• Payment processing: negligible on top of the session baseline.

For a single-location restaurant with 2 kiosks running simultaneously, plan for at least 3 Mbps symmetric minimum. For a 5-kiosk deployment running peak hours, plan for at least 10 Mbps symmetric. Most modern business broadband easily handles this.

#Ports

Kiosks communicate outbound only — you don't need to open any inbound ports. Outbound requirements:

• 443/TCP (HTTPS) to api.yumkiosk.com, agent.yumkiosk.com, kiosk.yumkiosk.com, and docs.yumkiosk.com.
• 443/TCP (WSS) to agent.yumkiosk.com/ws/ for the WebSocket connection (falls back to long-polling if blocked).
• UDP in the 49152–65535 range to Agora's media servers. This is how the live video actually flows. If UDP is blocked, Agora falls back to TCP over port 443, but quality degrades.
• 443/TCP to *.agora.io and *.stripe.com.

No VPN, no tunnels, no proxies. If you're on a captive portal Wi-Fi that requires a login page, the kiosk can't get past it — configure your network to bypass the captive portal for the kiosk's MAC address.

#Wi-Fi configuration

A few best practices for restaurant Wi-Fi:

1. Dedicated SSID for kiosks, separate from customer Wi-Fi. This prevents accidental rate limiting or deep-packet inspection that breaks WebRTC.
2. 5 GHz preferred — less crowded than 2.4 GHz in most restaurants, lower latency.
3. Static or reserved IPs for each kiosk tablet, so you can identify them on the network and apply firewall rules.
4. QoS: mark YumKiosk traffic as high-priority so it doesn't get starved by a busy customer Wi-Fi.
5. WPA2 or WPA3 — don't run an open network.

If you have multiple locations, use the same SSID name at every store so tablets can be swapped between stores without reconfiguration.

#Captive portals and firewalls

Shared-tenant locations (malls, food courts, airports) often have captive portals or corporate firewalls that block WebRTC. Common symptoms:

• Session accepts but video never connects ("Connecting..." forever)
• Kiosk drops offline every few minutes
• WebSocket keeps reconnecting

If you see this, ask the IT contact at the location to allowlist *.yumkiosk.com and *.agora.io and open UDP 49152–65535 outbound. If that's not possible, YumKiosk can use TCP-only media (at reduced quality) as a fallback — contact support and we'll enable it for your kiosks.

#Offline behavior

If the internet goes down mid-session, the kiosk shows a "Connection lost, please wait..." screen. If connectivity returns within 10 seconds, the session resumes seamlessly. If not, the session aborts and the kiosk returns to the attract screen. Either way, no order is silently lost — the customer sees a clear error.

On the attract screen, offline kiosks show a small "Unable to reach server, please check Wi-Fi" banner and pause the order button until connectivity returns.

#Monitoring

Every kiosk reports its health to the owner panel via a heartbeat every 30 seconds. Under Operations → Kiosks, you can see each kiosk's current status, last-seen timestamp, and a 24-hour uptime graph. Kiosks that go offline for more than 2 minutes trigger an alert email to the business manager.