EShare Deployment Guide

Network Requirements & Security Framework

Document Version: 2.1 | Security & Compliance Update: Q1 2026
Table of Contents

1. Introduction

This document provides essential network configuration guidelines and security information for deploying and managing the EShare solution within enterprise and educational IT environments. It is intended for network administrators, IT support staff, and system engineers responsible for network infrastructure, firewall management, and device connectivity. Adhering to these guidelines is crucial for ensuring optimal performance, reliability, and security of EShare services.

2. Bandwidth Requirements

Sufficient network bandwidth is paramount for a seamless EShare user experience. Bandwidth consumption varies based on the specific EShare feature in use.

2.1 Local Screen Mirroring (Client Device to EShare Receiver)

Description: Mirroring content from a user's laptop or mobile device directly to an EShare-enabled display (e.g., Interactive Flat Panel Display - IFPD) located on the same Local Area Network (LAN).

Peak Bitrate: Can potentially reach up to 30 Mbps per active mirroring session during high-motion content.

Average Bitrate: Typically fluctuates below the peak value depending on screen content complexity and changes.

Recommendations:
  • For maximum stability and performance, particularly in environments with high Wi-Fi density or potential interference, connect the EShare receiver (display/IFPD) via a wired Ethernet connection.
  • Connect client devices (laptops, mobile devices) using the 5GHz Wi-Fi band. This band generally offers higher throughput and is less susceptible to interference compared to the 2.4GHz band.
  • Provision approximately 30 Mbps of dedicated local network bandwidth capacity per concurrent screen mirroring session to reliably accommodate peak usage scenarios.

2.2 Multi-Screen Collaboration (TV Mirror / Display Group)

Description: Features enabling content distribution from one source device to multiple EShare-enabled displays simultaneously within the LAN.

Average Bitrate: Consumes approximately 4 Mbps per connected client device (e.g., pad, laptop) participating in the session.

Recommendation: Calculate the aggregate required local network bandwidth by multiplying the number of concurrently connected client devices by 4 Mbps.

Example: A classroom scenario with 40 client devices simultaneously using TV Mirror necessitates: 40 devices * 4 Mbps/device = 160 Mbps of total local network bandwidth capacity.

2.3 Cloud Cast (WebCast & Broadcast)

Description: Streaming content originating from an EShare device over the Internet to remote viewers (WebCast) or broadcasting to a mix of local and remote endpoints (Broadcast).

Average Bitrate: Requires approximately 4 Mbps per active stream (this applies to both the upload bandwidth from the source device and the download bandwidth for each remote viewer).

Recommendation: To ensure a fluid and uninterrupted streaming experience, allocate at least 5 Mbps of sustained Internet bandwidth (both upload at the source and download per remote viewer) for each concurrent Cloud Cast stream. This buffer helps accommodate typical Internet fluctuations and overhead.

3. Network Configuration

Proper network configuration, including firewall policies and port accessibility, is fundamental for EShare functionality.

3.1 Required Network Ports

Ensure the following ports are permitted through internal firewalls, Access Control Lists (ACLs), and any network segmentation policies to allow communication between EShare clients, receivers, and essential network services.

Network Segment Port(s) / Range Protocol Service / Protocol Description Used By Criticality & Notes
Local Network (LAN) 51010-51060, 8121, 57395, 8080, 52020-52030, 53000 TCP EShare Proprietary Communication EShare Clients/Receivers Core functionality
8600, 8700 TCP AirPlay Streaming Control AirPlay Required for Apple device mirroring
25123, 25124 TCP EShare Proprietary Communication EShare Clients/Receivers Core functionality
48689 UDP Device Discovery (EShare Specific) EShare Clients/Receivers Essential for EShare app discovery on LAN
5353 UDP Multicast DNS (mDNS / Bonjour) AirPlay, EShare Discovery Essential for discovery (Apple & EShare)
8008, 8009 TCP Google Cast Authentication/Control Google Cast Required for Google Cast support
7250 TCP Miracast Control Channel Miracast Required for Miracast mirroring
Internet Access (Outbound) 443 TCP HTTPS (TLS Encrypted Communication) WebCast, Broadcast Primary secure communication channel
10000-65535
(*.casts.app)		 UDP DTLS (for TURN Relay / WebRTC Media) WebCast, Broadcast Required for secure media via cloud relay
Note on UDP Ports: Proper configuration of mDNS reflectors/gateways might be necessary in segmented networks. The wide UDP range (10000-65535) for *.casts.app is typical for WebRTC dynamic port allocation for media.

3.2 Required Fully Qualified Domain Names (FQDNs)

Ensure that EShare clients and receivers requiring cloud connectivity can resolve and establish outbound connections to the following domains. These FQDNs must be permitted through firewalls, web content filters, and proxy servers:

*.eshare.app
*.casts.app

Purpose: Access to these domains is essential for Cloud Cast functionality (WebCast, Broadcast), license validation, software updates, and establishing secure media relay connections via TURN servers.

4. Security Architecture & Regulatory Compliance

EShare incorporates a multi-layered security framework designed to protect enterprise network boundaries, maintain data confidentiality, and comply with international privacy standards.

4.1 Secure Control Plane Communication

EShare Client Device EShare Cloud Infrastructure Control Plane TLS 1.2+ Encryption RSA/ECC 2048-bit AES 256-bit Data Encryption
  • All signaling and control data exchanged between EShare software components and backend cloud infrastructure is encrypted using Transport Layer Security (TLS 1.2 or higher) over TCP port 443.
  • Utilizes asymmetric cryptography (RSA/ECC 2048-bit) for authentication/handshake and strong symmetric algorithms (AES 256-bit) for payload encryption.

4.2 Secure Media Transport

EShare Endpoint A (Source) EShare Endpoint B (Destination) Direct P2P Connection (DTLS Encrypted) Using STUN for NAT Traversal TURN Server (Media Relay) DTLS Encrypted DTLS Encrypted Preferred P2P TURN Relay (Fallback)
  • For remote streaming scenarios (WebCast/Broadcast), EShare prioritizes establishing a direct peer-to-peer (P2P) connection facilitated by STUN.
  • When direct P2P connections cannot be established due to restrictive firewalls, traffic safely falls back to cloud TURN relays.
  • Media relayed through TURN servers is encapsulated via Datagram Transport Layer Security (DTLS).

4.3 End-to-End Media Encryption

Source Device SRTP Encryption Network (LAN/Internet) SRTP Encrypted Transport (Video & Audio Media Streams) Destination Device SRTP Decryption End-to-End Encryption - Decrypted Only at Destination Protects Video/Audio Content from Network Eavesdropping
  • The actual video and audio media streams transmitted during EShare sessions are protected with end-to-end encryption using the Secure Real-Time Transport Protocol (SRTP).
  • SRTP ensures media payload is encrypted directly at the source and decrypted exclusively at destination endpoints, preventing eavesdropping even across complex multi-hop networks.

4.4 Operational Architecture: Local vs. Cloud Services

To adhere to strict zero-trust enterprise security policies, EShare maintains strict architectural separation between localized media distribution and cloud-assisted control features:

Local Network Operation (Default Mode)

After initial license activation, all core screen casting, BYOM conferencing, and media sharing functionalities operate strictly within your Local Area Network (LAN/WLAN) via direct peer transmission.

Zero External Leakage: In standard operating mode, no presentation frames, audio samples, or video streams ever leave your internal network or pass through external cloud servers.
Cloud-Based Features (Opt-In / Explicitly Initiated)

External cloud server interactions are strictly isolated to licensing handshakes or when remote capabilities are explicitly triggered by an administrator or user:

  • Remote fleet administration via EShare Cloud Management.
  • Wide-area network (WAN) multi-screen broadcasting across separate subnets.
  • Public Internet Webcasting features.

4.5 Global Data Residency & Regional Compliance

To satisfy multinational corporate governance, data sovereignty, and strict regional privacy mandates (including EU GDPR, UK GDPR, and US CCPA/CPRA), EShare deploys decentralized, geographically isolated cloud backend nodes worldwide.

Deployment Region Data Center Location & Infrastructure Applicable Compliance Standards
Europe & UK
(EEA, UK, Switzerland)		 Frankfurt am Main, Germany (European Union)
Hosted in certified Tier-3 / ISO 27001 facilities. All telemetry and fleet configuration data remain within the EU boundary.
  • GDPR compliant (Full adherence to Art. 28 Data Processing Agreements).
  • No international data transfer to non-adequate third countries without Standard Contractual Clauses (SCCs).
North America
(United States & Canada)		 Northern Virginia / Oregon, USA
Dedicated cloud availability zones providing low-latency management channels.
  • Compliant with CCPA / CPRA privacy statutes.
  • Zero sale or monetization of enterprise or personal data.
Asia-Pacific & Global
(APAC, MEA, LATAM)		 Singapore / Tokyo / Sydney
Geographically routed nodes ensuring that client discovery and TURN relaying occur locally.
  • Compliant with statutory cross-border privacy acts (e.g., Singapore PDPA, Australian Privacy Principles).

4.6 Device Permissions & BYOM Governance

EShare adheres to the principle of least privilege. The application requests only OS-level permissions that are strictly necessary to deliver its presentation and collaborative conferencing services:

  • Local Network / Wi-Fi Access: Strictly utilized to discover nearby EShare receivers and establish local peer-to-peer transmission sockets.
  • Camera & Microphone Permissions (BYOM): Required exclusively during active BYOM (Bring Your Own Meeting) sessions to bridge the room's hardware peripherals to the user's conferencing software (e.g., Teams, Zoom). Media capture is ephemeral and never recorded or written to non-volatile disk.
  • Revocability: Permissions can be centrally managed or revoked at any time via host operating system settings (Windows, macOS, iOS, Android). Revoking non-essential permissions will only disable the associated peripheral bridge without compromising basic local mirroring.

5. Network Optimization Recommendations

Beyond the fundamental configuration, proactively optimizing the network can significantly enhance the EShare experience, especially in demanding environments.

5.1 High-Density Deployment Considerations

Environments like large classrooms, lecture halls, or conference centers with numerous devices require careful network planning:

Wi-Fi Design:
Prioritize 5GHz:
Mandate or strongly encourage client connections on the 5GHz band due to its higher channel availability and generally lower interference levels compared to 2.4GHz.
  • Channel Planning: Conduct thorough RF surveys and implement a static or adaptive channel plan that minimizes co-channel and adjacent-channel interference. Carefully consider the use of DFS channels based on environmental stability.
  • Transmit Power Control (TPC): Avoid setting AP transmit power to maximum. Optimize power levels to create appropriately sized coverage cells and reduce inter-AP interference.
  • Sufficient AP Density: Ensure enough Access Points are deployed to handle the client load without overloading individual APs.
  • Airtime Fairness: Enable Airtime Fairness features on the WLAN infrastructure to prevent legacy clients from degrading total throughput.
  • Band Steering: Implement band steering to direct dual-band clients toward 5GHz.
Wired Infrastructure:
Ethernet for Receivers:
Connect EShare receivers (IFPDs/Displays) via dedicated Ethernet ports for maximum stability and to offload the Wi-Fi network.
  • Switch Capacity: Ensure access layer switches have sufficient backplane capacity and non-blocking architecture. Gigabit Ethernet ports are recommended for receivers.
Multicast/Broadcast Optimization:
  • IGMP Snooping: Ensure IGMP Snooping is enabled across relevant VLANs to prevent mDNS discovery packets from flooding network ports.
  • mDNS Gateways: In segmented networks, deploy mDNS reflectors/gateways to enable discovery across subnets (UDP 5353).

5.2 Performance Monitoring

Regular monitoring provides insights into network health and helps proactively identify potential bottlenecks affecting EShare performance:

Key Network Metrics:
  • Bandwidth Utilization: Monitor switch ports connected to receivers, access points, and Internet uplinks.
  • Latency & Jitter: Track latency between clients and receivers (as well as to EShare cloud domains). Jitter should remain low for real-time video streaming.
  • Packet Loss: UDP-based media streaming (SRTP) requires minimal packet loss to maintain high visual fidelity.
Wi-Fi Specific Metrics:
  • Channel Utilization: Monitor airtime utilization. High percentages indicate spectrum congestion.
  • Client Signal Strength (RSSI) & SNR: Maintain strong RSSI/SNR levels to ensure client devices operate at high PHY data rates.
  • Retry Rates: Elevated retry rates typically indicate RF interference or weak signal boundaries.

5.3 Basic Troubleshooting Guidelines

When users report connectivity or streaming issues, follow this structured troubleshooting flow:

1. Verify Basic Connectivity
  • Client Device: Verify correct SSID, 5GHz band selection, and valid local IP address assignment.
  • Receiver Device: Confirm power, physical link lights on the Ethernet port, and valid IP assignment. Test ping reachability between subnets.
2. Check Discovery
  • Are client and receiver on the same VLAN? If not, verify that mDNS gateway/reflection is operational.
  • Ensure UDP ports 48689 and 5353 are permitted across subnet boundaries and local endpoint firewalls.
  • Try disabling the client device's software firewall temporarily for testing purposes.
3. Investigate Connection/Streaming Issues
  • Confirm required firewall ports (Section 3.1) are open for both internal sockets and outbound HTTPS/DTLS channels.
  • Verify reachability to *.eshare.app and *.casts.app (DNS resolution and HTTPS port 443 handshake).
4. Isolate the Issue
  • Connect the client device via a wired Ethernet adapter to determine whether issues stem from RF interference.
  • Test with another client device or against an alternate EShare display to isolate hardware-specific faults.
5. Technical Escalation

If issues persist, gather network traces, client logs, endpoint timestamps, and reach out to EShare Enterprise Technical Support.

Document Disclaimer

The network and security recommendations in this guide are based on typical enterprise deployment scenarios. Specific enterprise security postures, firewall architectures, and regulatory requirements may require customized configurations. Please consult EShare Enterprise Support for tailored network architecture reviews.