Digital Signage Network Requirements: An IT Handoff Checklist
Plan player connectivity, firewall requirements, content transfers, and recovery. Use the IT handoff worksheet before a digital signage rollout.
Cover illustration: a conceptual scene, not a Gemdragon model or completed customer installation.
Digital signage network requirements should identify how the player gets online, which services it must reach, what content is downloaded or streamed, and who owns recovery. There is no universal firewall list or bandwidth number for every CMS. Obtain the chosen software provider's current requirements, test them on the intended site network, and retain a record of publishing, playback, timekeeping, and recovery before installing the wider fleet.
Draw the boundary around the actual player
Start by naming the device that connects to the network. An external media player and a display's management interface can have different addresses and responsibilities. An integrated player still needs an identified operating system, application, and network arrangement.
Record the player model, operating system, CMS build, wired or wireless connection, and site owner. Include any external data source used by the content. A working video file does not demonstrate access to an internal dashboard or an authenticated web page.
Use this worksheet with the site's IT team. The purpose is to collect the requirements that apply to the selected system, not to prescribe new firewall access from a generic article.
Prepare the network handoff table
| Item | Information to collect | Acceptance evidence |
|---|---|---|
| Addressing | DHCP or approved static configuration; device identifier | Correct address and network assignment |
| Connectivity | Ethernet or Wi-Fi requirements; authentication method | Connection survives the intended restart sequence |
| Name resolution | Approved DNS arrangement | Required hostnames resolve from the player network |
| Time | Approved time source, time zone, and scheduling owner | Scheduled content appears at the intended local time |
| Cloud services | Current domains, ports, direction, and purpose from the CMS provider | Enrollment, publishing, and updates work |
| Live content | Destination, authentication, refresh, and expiry behavior | Current content displays without exposing credentials |
| Remote support | Approved access method, permissions, and owner | Authorized support can perform the agreed task |
| Outage | Cached-content policy and reconnection behavior | Observed result recorded for each tested failure |
Keep account secrets in the approved credential system. The handoff table needs an owner and reference, not a shared password printed into a site pack.
Why is “internet access” an incomplete requirement?
A player may reach one service while another required connection is blocked. Yodeck's restricted-network documentation lists separate destinations and purposes for its own platform, with required and optional entries. Its list is a useful example of the detail to request. Do not copy it as the firewall requirements for another CMS or for all Gemdragon displays.
Ask IT to check the actual installation network, including any proxy, captive portal, certificate handling, or wireless authentication requirement. Do not approve a deployment solely because it worked on a phone hotspot during a demonstration.
An internal dashboard introduces a separate access decision. Confirm whether the player can reach the source and how it receives authorized data. Prefer a signage-specific presentation with only the information intended for that screen. Our security handoff guide covers ownership of access and administration.
Estimate content-transfer bandwidth from real files
Separate downloaded media from continuously streamed content. For downloaded media, estimate the data to distribute and the available transfer window. For streaming, use the actual stream requirements and concurrent devices. Add headroom for normal site use and confirm the result with a pilot.
The following is a simplified arithmetic example, not a Gemdragon requirement or measured result. Suppose a fictional site must deliver a 500 MB content package to each of 10 players within one hour, with no shared cache or multicast saving. The transferred total is 5,000 MB. Using decimal units, 5,000 × 8 ÷ 3,600 is about 11.1 Mb/s of average payload throughput.
That result excludes protocol overhead, retries, other network traffic, and any extra CMS data. It is not a recommended minimum connection speed. Shared caching, staggered downloads, or a different package size can change the requirement. Measure the installed workflow and agree an appropriate margin with IT.
Test the opening day, not just enrollment
Run these checks with a representative player on the intended network:
- Enroll the correct device into the correct account or group.
- Publish a known package and verify the picture on the physical screen.
- Make a scheduled change and confirm the local time and expiry behavior.
- Test any live page or data source with its intended access method.
- Run an approved network-interruption test and record which content continues.
- Restart while disconnected if that behavior is part of the project requirement.
- Restore connectivity and verify synchronization and removal of stale content.
- Confirm the permitted monitoring and support workflow.
Our offline playback test script provides a more detailed outage check. Being online in the portal and showing the correct picture are separate observations; retain both.
What should be signed off before rollout?
The site owner should have the device inventory, approved requirements, test results, escalation contacts, and a change process. Name who updates the network document when the CMS changes its service destinations. Identify who can approve a player update and how a failed update will be handled.
Frequently asked questions
Can Wi-Fi be used for digital signage?
Evaluate it against the site's coverage, authentication, reliability, and content-transfer needs. Test at the actual screen location, including inside the proposed enclosure. Do not treat an Ethernet socket or Wi-Fi logo as proof of successful deployment.
Do cloud-managed screens always require continuous streaming?
No single assumption fits every platform. Distinguish media downloads, cached playback, streamed material, and live data. Ask the CMS provider and test the chosen content types.
Which ports should IT open for digital signage?
Use the current requirements supplied for the selected CMS, player, and services. Have IT review the destination domains, connection direction, and authentication; this guide does not supply a universal firewall rule.
How do I estimate content-transfer bandwidth?
Start with the actual update package size, number of players, and permitted download window. Treat that arithmetic as a planning estimate, then test delivery on the installation network with other traffic present.
What should an outage test include?
Check the displayed content when connectivity is lost, any live-data behavior, restart recovery, and reconnection. Record the chosen software build and content types because their fallback behavior may differ.
Request a configuration and network review
Share the site network constraints, proposed CMS, device quantity, content types, orientation, and intended display format. Ask Gemdragon for the hardware information needed to coordinate a sample with the software and IT owners. Start with Integration and CMS Compatibility and the CMS validation guide.
Discuss your deployment requirements
This checklist does not certify a network, authorize firewall changes, or establish compatibility for an untested configuration. Further project references are in Resources.
