EShare Deployment Guide

Network Requirements & Security Framework

Document Version: 2.0 | Last Updated: March 25, 2025
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) 80 TCP HTTP (Cloud Services) WebCast, Broadcast Initial connection, software updates
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

EShare incorporates multiple layers of security to protect communication and data integrity.

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 EShare's backend cloud infrastructure (required for features like Cloud Cast) is encrypted using Transport Layer Security (TLS), typically TLS 1.2 or higher, over TCP port 443.
  • This utilizes industry-standard cryptographic mechanisms, including RSA or ECC based asymmetric cryptography (e.g., 2048-bit keys) for authentication and key exchange, and strong symmetric algorithms (e.g., AES 256-bit) for encrypting the communication payload.

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) media connection between endpoints, facilitated by STUN (Session Traversal Utilities for NAT) for traversing NAT firewalls.
  • When a direct P2P connection cannot be established (due to symmetric NATs or restrictive firewalls), EShare utilizes its cloud relay service (TURN - Traversal Using Relays around NAT).
  • Media streams routed through TURN servers are encrypted using Datagram Transport Layer Security (DTLS), providing confidentiality and integrity for UDP-based media traffic.

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 (both local LAN mirroring and Cloud Cast, where applicable) are protected with end-to-end encryption using the Secure Real-Time Transport Protocol (SRTP).
  • SRTP ensures that media content is encrypted at the source and decrypted only at the intended destination endpoint(s), preventing eavesdropping even if network segments or intermediate relay servers are compromised.

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. Use predictive or physical surveys to determine optimal placement.
  • Airtime Fairness: Enable Airtime Fairness features on the WLAN infrastructure, if available, to prevent slower clients from disproportionately consuming available airtime.
  • Band Steering: Implement band steering to encourage dual-band capable clients to connect to the 5GHz band.
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. Verify uplink ports (to distribution/core layers) are not consistently saturated. Gigabit Ethernet ports are recommended for receivers.
Multicast/Broadcast Optimization:
  • IGMP Snooping: Ensure IGMP Snooping is enabled and properly configured on all relevant VLANs/switches to prevent multicast traffic (used by mDNS/Bonjour for discovery) from flooding unnecessary ports.
  • mDNS/Bonjour Gateways: In segmented networks (multiple VLANs/subnets), deploy mDNS reflectors or gateways if discovery across subnets is required. Ensure firewall rules permit mDNS traffic (UDP 5353) between the gateway and relevant subnets.

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 utilization on switch ports connected to EShare receivers, client-heavy APs, switch uplinks, and Internet gateways (especially for Cloud Cast). Look for sustained high utilization or frequent spikes exceeding capacity.
  • Latency & Jitter: Track network latency and jitter between typical client locations and EShare receivers, and to EShare cloud FQDNs for Cloud Cast. High or fluctuating values significantly degrade real-time media quality.
  • Packet Loss: Monitor for packet loss on relevant network paths. UDP-based media streaming (SRTP) is particularly sensitive to packet loss.
Wi-Fi Specific Metrics:
  • Channel Utilization / Airtime: Monitor how busy the Wi-Fi channels are. High utilization indicates congestion.
  • Interference Levels: Track RF interference (both Wi-Fi and non-Wi-Fi sources).
  • Client Signal Strength (RSSI) & SNR: Monitor client connection quality. Low RSSI or SNR leads to lower data rates and potential instability.
  • Retry Rates: High packet retry rates indicate poor connection quality or interference.

Tools: Utilize Network Management Systems (NMS), SNMP monitoring, NetFlow/sFlow analysis, WLAN controller dashboards, and occasional packet captures (e.g., using Wireshark) for detailed analysis.

5.3 Basic Troubleshooting Guidelines

When users report EShare issues (e.g., inability to connect, lag, poor video/audio quality), follow a structured approach:

1. Verify Basic Connectivity
  • Client Device: Is it connected to the correct Wi-Fi network (SSID)? Is it on the 5GHz band (recommended)? Check signal strength. Does it have a valid IP address in the expected subnet?
  • Receiver Device: Is it powered on? Is the Ethernet cable securely connected? Does it have a valid IP address? Can you ping the receiver's IP address from the client subnet (if network policy allows)?
2. Check Discovery
  • Are the client and receiver on the same VLAN/subnet? If not, is mDNS reflection/gateway properly configured and allowed through firewalls?
  • Verify UDP ports 48689 and 5353 (mDNS) are open between the client and receiver (check local firewalls on client devices and network firewalls).
  • Try disabling the client device's software firewall temporarily for testing purposes.
3. Investigate Connection/Streaming Issues
  • Firewall Rules: Double-check that all required ports (Section 3.1) are permitted through network firewalls for both LAN and Internet connections (if using Cloud Cast).
  • FQDN Resolution/Reachability: For Cloud Cast, verify the client and receiver can resolve and reach *.eshare.app and *.casts.app via DNS lookup and test connectivity (e.g., ping, traceroute, HTTPS connection test to port 443). Check proxy server and web filter configurations.
  • Bandwidth Saturation: Use monitoring tools (Section 5.2) to check if current network utilization (LAN or Internet) is exceeding the recommended capacity (Section 2) during the time of the issue.
  • Network Quality: Check monitoring tools for high latency, jitter, or packet loss on the path between client and receiver (or client/receiver and cloud for Cloud Cast).
4. Isolate the Issue
  • Wi-Fi vs Wired: If the client is on Wi-Fi, try connecting it via Ethernet if possible. Does the issue resolve?
  • Device Specific: Try connecting from a different client device. Does the issue persist?
  • Receiver Specific: Try connecting to a different EShare receiver if available. Does the issue follow the client or stay with the original receiver?
  • Software Updates: Ensure the EShare client application, receiver firmware, device operating systems, and network drivers are up-to-date.
5. Escalate

If basic troubleshooting doesn't resolve the issue, gather relevant information (devices involved, symptoms, timestamps, troubleshooting steps taken) and contact EShare technical support.

Document Disclaimer

The network and security recommendations in this guide are based on typical deployment scenarios. Each environment has unique requirements and constraints that may necessitate additional adjustments. EShare regularly updates its products and services, so specific port requirements and network behaviors may change. Please refer to the latest official documentation for the most accurate information.