Virtual Room combines WebRTC video conferencing, co-browsing, and live document collaboration in a browser. Because it relies on persistent connections and real-time media, it is more sensitive to restrictive corporate networks than standard e-signing. To ensure a smoother customer experience review the requirements below before hosts or participants join from a corporate network or VPN.
All of the following requirements are subject to change.
Firewall and proxy allowlist
All connections are outbound from the participant's browser. No inbound rules are needed.
To use OneSpan Notary you must whitelist the following URLs:
For additional information on these URLs, see the table below.
# | Destination | Protocol / Port | Purpose | Required |
|---|---|---|---|---|
1 | Your OneSpan Sign domain — the domain in the signing or transaction URL (e.g. apps.esignlive.com; varies by region and account) | HTTPS + WSS, TCP 443 | Signing ceremony UI, APIs | Always |
2 | Same domain as row 1, path /virtual-room/* | HTTPS + Server-Sent Events, TCP 443 | Virtual Room: room state, join/leave events, live captions | Always (VR) |
3 | *.opentok.com and *.tokbox.com (wildcards required — Vonage does not publish a fixed FQDN list) | HTTPS + WSS, TCP 443 | Vonage Video: session setup, in-call signaling, telemetry, media-over-WebSocket fallback | Always (VR) |
4 | Vonage media servers | UDP 3478 (STUN/TURN) + UDP 1025–65535 (SRTP, preferred); fallback TURN over TCP/TLS 443 | Audio and video media — see section 2 for tiered port options | Always (VR) |
5 | *.upscope.io (see note below if wildcards are not supported) | HTTPS + WSS, TCP 443 | Upscope co-browsing and shared document view | Always (VR) |
6 | cobrowsingapi.com | HTTPS, TCP 443 | Co-browsing viewer (iframe) | Always (VR) |
Row 2 is not a separate firewall rule. The Virtual Room service runs on the same OneSpan Sign domain and port as row 1. It is listed separately because it uses Server-Sent Events — a long-lived streaming response — which proxies must pass through without buffering.
Row 3 Vonage wildcards: Vonage does not provide a complete FQDN list, so wildcard rules are required. Accounts on Vonage's Unified environment also need *.vonage.com. For more detail, see the Vonage firewall and ports article. Customers who need IP-based allowlisting instead of domains must request the Enterprise Environment "Allowed IPs" add-on from Vonage — contact our Support Team to raise this.
Row 5 Upscope explicit hosts: If *.upscope.io is not possible, allow these hosts individually: js.upscope.io, code.upscope.io, assets-proxy.upscope.io, app cdn.upscope.io, api.upscope.io, data.upscope.io, and the regional endpoints data--us-east.upscope.io, data--us-west.upscope.io, data--eu-west.upscope.io, data--eu-central.upscope.io, data--sa-east.upscope.io, data--ap-southeast.upscope.io. Start with assets-proxy.upscope.io if co-browsing loads partially — URL-keyword filters often block it because the hostname contains "proxy".
If row 1 is restricted to specific URL paths, include /virtual-room/*, /graphql, and /transaction/* in addition to the signing pages.
WebRTC and media transport
Virtual Room uses Vonage Video in routed media mode — all streams pass through Vonage media servers; there is no direct peer-to-peer traffic between participants. The four protocols involved are WSS (signaling), REST/HTTPS (configuration and logging), SRTP (audio/video), and STUN/TURN (NAT traversal). All connections are outbound. No inbound rules or port forwarding are required.
Vonage defines three levels of firewall configuration:
Level | Ports to open (outbound) | Result |
|---|---|---|
Optimal | UDP 3478 (STUN/TURN) + UDP 1025–65535 (ICE/SRTP) + TCP 443 | Fastest setup, best quality |
Recommended minimum | UDP 3478 (STUN/TURN) + TCP 443 | Good quality — media still uses UDP via TURN |
Absolute minimum | TCP 443 only (WSS, HTTPS, TURN over TLS) | Functional, but slower setup and lower quality; sensitive to packet loss |
If TCP 443 to Vonage domains is also blocked or subject to TLS interception, video fails entirely with "could not connect to media" errors.
Recommendations for your IT department:
Open at least UDP 3478 (the recommended minimum). TCP-443-only is a last resort — TCP retransmission degrades real-time media, and quality drops on any network with packet loss.
The Vonage client always tries UDP first, even if UDP is blocked. UDP attempts in a network trace are expected and are not errors.
Do not apply TLS inspection (MITM decryption) to *.opentok.com, *.tokbox.com, or *.upscope.io. It breaks WebSocket upgrades and TURN-over-TLS. Add these domains to the inspection bypass list.
Do not disable WebRTC via browser group policy. Settings such as WebRtcUdpPortRange set to 0–0, or fleet-wide WebRTC-blocking extensions, will silently break Virtual Room video.
WebSocket and streaming connections (proxy / VPN)
Virtual Room requires three types of persistent connections. Proxies and VPNs must not interrupt them:
Connection type | Endpoint | What breaks if interrupted |
|---|---|---|
WebSocket (WSS) | Vonage signaling (*.media.prod.tokbox.com), Upscope, GraphQL subscriptions on the OneSpan Sign domain | Video join fails; co-browsing fails; document state stops updating |
Server-Sent Events (persistent HTTP stream) | /virtual-room/{id}/event on the OneSpan Sign domain, port 443 | Participants stop receiving room events: joins, recording status, captions, verification status, session expiry |
WebRTC media | Vonage media servers | Video and audio freeze or disconnect |
Proxy requirements:
Must support the Upgrade: websocket handshake (HTTP/1.1) on port 443.
Must not buffer streaming responses. Antivirus or DLP proxies that hold responses for scanning break Server-Sent Events — the client appears connected but receives no events.
Connection timeouts must support sessions of 30–90 minutes. Proxies with short idle timeouts (for example, 60 seconds or a 5-minute hard cap) cause repeated drops. Set a timeout of ≥ 4 hours — or no cap — for the domains in section 1.
NTLM/Kerberos re-authentication mid-connection can drop WebSockets. Exempt the section 1 domains if drops are observed.
The proxy must be transparent or explicitly configured in the browser or OS. Vonage SDKs do not support PAC files, and native (non-browser) SDKs do not support authenticating proxies. For highly restricted environments, Vonage offers a self-hosted IP Proxy and configurable TURN add-ons — contact our Support Team or Vonage account management.
VPN requirements:
Must pass WebSocket connections on port 443 to the OneSpan Sign domain and all domains in section 1.
Full-tunnel VPNs add latency and often push media onto the slower TCP fallback path. Split tunneling for *.tokbox.com and *.opentok.com is strongly recommended.
Bandwidth and performance
Recommended minimum: 3 Mbps up and down per participant (covers video, audio, co-browsing, and document sync).
Per video stream: approximately 300 kbps at low quality, up to 1.5+ Mbps at HD — in each direction. Sessions with multiple participants on camera require more downstream bandwidth.
Round-trip latency to the OneSpan Sign region should be under 150 ms. VPN hairpinning through a remote regional gateway degrades both video and co-browsing.
Packet loss above 3% degrades WebRTC quality regardless of bandwidth.
Endpoint and browser requirements
Use a current version of Chrome, Edge, Firefox, or Safari. Chromium-based browsers give the most consistent WebRTC results on corporate builds.
Camera and microphone access must be allowed at all three levels below. Corporate policy can block any one of them independently:
OS privacy settings (Windows camera/microphone privacy; macOS TCC permissions).
Browser group policy: VideoCaptureAllowed, AudioCaptureAllowed, and the per-site ...AllowedUrls variants on managed Chrome or Edge.
The per-site browser prompt — users must be able to click Allow.
Fleet-wide browser extensions that block WebRTC, scripts, or third-party frames (privacy or ad blockers) can break video and Upscope co-browsing.
Virtual machines and thin clients (Citrix, VDI) often lack reliable camera and microphone passthrough and add encoding latency. Physical endpoints are recommended for hosts and notaries.
Troubleshooting
Symptom | Likely cause |
|---|---|
Signing ceremony loads but Virtual Room never finishes loading | /virtual-room/* blocked by a path-filtering proxy, or SSE stream blocked or buffered |
Participants join but do not see state changes (joins, recording banner, verification status) | Proxy buffering or terminating the SSE stream (/virtual-room/{id}/event) |
"Connecting to video…" hangs or fails immediately | Vonage domains blocked (config.opentok.com, anvil.opentok.com, *.media.prod.tokbox.com) or TLS inspection breaking the WebSocket upgrade |
Video connects, then tiles go black or freeze, or audio only | UDP media blocked and the TCP/TLS 443 fallback also blocked or inspected |
Video works but quality is poor or drops repeatedly | UDP blocked (media running over TCP fallback), full-tunnel VPN, or proxy idle timeouts |
Live captions never appear | SSE stream blocked or buffered (captions use the same event channel as other room events) |
Co-browsing is blank or not syncing | *.upscope.io or cobrowsingapi.com blocked, or WSS to Upscope blocked |
Co-browsing loads partially (missing styles or images) | assets-proxy.upscope.io blocked — URL-keyword filters flag "proxy" in the hostname |
Works at home, fails in the office | Proxy or firewall restriction — check WebSocket support, SSE buffering, and TLS inspection first |
If an outage is suspected rather than a network block, check the relevant status page:
Vonage Status: https://vonageapi.statuspage.io/
Upscope: https://status.upscope.io/
Pre-session validation checklist
Complete these checks from inside the corporate network before the first live session.
[ ] OneSpan Sign domain reachable on port 443, including the Virtual Room path — for example, curl -s -o /dev/null -w '%{http_code}' https://<your-domain>/virtual-room/probe/existence returns any HTTP status code.
[ ] WebSocket upgrade succeeds through the proxy on port 443 (test against the OneSpan Sign domain or *.media.prod.tokbox.com).
[ ] *.upscope.io (including assets-proxy.upscope.io) and cobrowsingapi.com are reachable and excluded from TLS inspection.
[ ] *.opentok.com and *.tokbox.com reachable using wildcards; UDP 3478 open, or TURN over TCP 443 confirmed working.
[ ] Proxy does not buffer text/event-stream responses; idle timeout ≥ 4 hours for section 1 domains.
[ ] VPN passes WebSocket traffic on port 443; split tunneling configured for *.tokbox.com and *.opentok.com where possible.
[ ] Managed browser policy allows camera and microphone access for the OneSpan Sign domain.
[ ] At least 3 Mbps up and down per participant confirmed from the corporate network.
[ ] Test session completed with one host and one participant before the real session.
For help validating your network configuration, contact our Support Team.
Certificate-based signing
If the account uses the Personal Certificate Client (smart-card or certificate signing), the browser also opens WSS connections to *.esignlive.com on local-agent ports 26666, 31222, 32444, 44555, 47777, 48888. This is separate from Virtual Room and RON, but is listed here because it appears in the same application security policy and may come up in the same IT review.