Minimum access
Start with device-initiated HTTPS to approved Dhruv and media destinations, plus site address, DNS and time services.
FAQ & Quick Help
Implementation help / Version 1.1
Network setup. Live streaming. Site-ready evidence.
A practical Dhruv What / Why / How / Prove It guide for customer IT teams, network engineers, installers and administrators: approve the core profile, then add only the services selected for the installation.
Real stream path
Separate encoder ingest from screen playback. Record the actual transport, roles, ports and endpoint owner.
Commission before acceptance
Validate certificates, enrolment, content, recovery, isolation and the agreed live-stream flow with retained evidence.
Guide downloads / verified references
Use the network guide and installation guide with the site-specific approval record.
PDF
Download the PDF guide
The supplied v1.1 visual reference, including port matrices, commissioning and handover forms.
DownloadWord
Download the editable Word companion
Editable text companion for completing approved site-specific values, notes and handover fields.
DownloadPDF
Download the Installation Guide
Dhruv Installation Guide v1.0: prepare, connect, install, enrol, publish, test and hand over.
Download01 / Select the right profile
There is no “open all Dhruv ports” rule.
Approve the core signage profile first. Add an optional profile only when its selected device, service, region and implementation details are recorded for the relevant site.
Important: A protocol default is not a deployment instruction. Codec, DRM, firmware, application capability and authorisation must also pass.
Profile A
Standard signage
Use when players download assigned content and report to Dhruv.
Approved HTTPS destinations on TCP 443, plus the selected site DNS, NTP and DHCP services.
Profile B
HTTPS live playback
Use when the selected device or application plays an approved HLS or DASH service.
TCP 443 to manifests, media segments, redirects and required key or licence services.
Profile C
Contribution / low latency
Use when an encoder, gateway or decoder is configured for RTMP, RTSP, RTP or SRT.
Only the configured ingest, receiver, control and media ports—not a broad protocol range.
Profile D
LAN IPTV multicast
Use when a headend distributes channels to multiple local receivers.
Assigned multicast groups and UDP ports, with an IGMP-aware switching and routing design.
Profile E
WebRTC
Use only where the selected application actually implements WebRTC.
Configured signalling, STUN/TURN, relay and media routes—confirmed against the deployed service.
Profile F
Amino management
Use only when H200 provisioning uses Amino Orchestrate or Resolve.
The separate, current vendor destination matrix for the selected region and service.
Profile G
Remote support
Use only where a separately approved support service is installed.
Named support servers and tightly scoped management rules with audit and expiry controls.
02 / One screen first
Prepare. Connect. Install. Enrol. Prove it works.
Use an approved pilot screen on the final site network before a wider rollout. A functioning display view, accepted request or uploaded package does not alone establish a commissioned device.
Release boundary: use only the authorised platform-specific package, release record and delivery method. Do not substitute a generic Android package, guessed installer address, shared credential or unapproved decoder.
1. Prepare and verify
Record approved display, model, firmware, location, orientation and network readiness. Check the approved package identity, digest and signer before installation.
2. Enrol and publish
Bind one physical device to one logical record through the authorised protected flow. Publish a compatible pilot asset to the exact screen and observe the actual result.
3. Recover and hand over
Test application/device restart, approved recovery and selected outage behaviour. Record non-secret evidence, visible open items, owners and support/rollback flows.
02 / Core network
Record the site before equipment arrives.
Capture ownership, exact device model and build, VLAN/subnet, address service, DNS, NTP, FQDNs, certificates, media origin, selected stream transport and support owner. Use the final site network—not a guest network or installer hotspot—for acceptance.
Baseline site firewall matrix
Destination ports only. Keep stateful return traffic and narrow each source/destination rule.
| Initiator → destination | Protocol / port | Restriction |
|---|---|---|
| Players → approved Player service | TCP 443 | Exact approved host; core HTTPS profile. |
| Admin clients → approved CMS service | TCP 443 | Restrict administration to the site policy. |
| Players / clients → approved media origins | TCP 443 | Only the hosts needed by assigned content. |
| Devices / servers → approved DNS resolvers | UDP and TCP 53 | Use approved resolvers, not unrestricted internet DNS. |
| Devices / servers → approved time servers | UDP 123 | Where NTP is used; validate time and timezone. |
| DHCPv4 client ↔ server / relay | UDP 68 ↔ 67 | Local address service, not a WAN port-forward. |
| Approved management source → VPN / bastion | Configured transport | Separate approved design; no assumed universal VPN port. |
Do not expose: unsolicited internet-to-player traffic, ADB, database, development, display-control or remote-desktop ports. Apply equivalent policy to IPv4 and IPv6.
03 / Live streaming
Choose the transport from the actual end-to-end path.
Contribution and distribution are separate. An encoder can send SRT or RTMPS to an ingest service while screens receive HLS over HTTPS. The CMS should not be assumed to relay, transcode or store live video because it holds the stream URL.
Record the complete stream record: source, destination, transport, codec, resolution, frame rate, peak bitrate, audio, DRM, latency, authentication, source restriction and failover behaviour.
HLS / DASH
TCP 443 or the configured playback port
Player to playback origin; include manifests, segments, redirects and required keys.
RTMP / RTMPS
Configured ingest port; RTMP commonly TCP 1935
Encoder to ingest listener only; do not expose it to every screen.
RTSP / RTP
RTSP control plus the negotiated or configured media route
Record endpoint roles and the actual UDP range or TCP interleaving path.
SRT
Configured UDP port
Record caller/listener role, NAT mapping, encryption policy and stream ID; 9000 is only an example.
Multicast IPTV
Assigned multicast group and UDP destination port
Headend to joined LAN receivers; IGMP is separate membership control.
WebRTC / TURN
Configured signalling, relay and media routes
Defaults are not a deployment rule; test direct and forced-relay paths.
04 / Devices, endpoints and hosting
Keep public edges, private services and device identity distinct.
The guide separates browser administration, device enrolment, player content delivery, heartbeat, status and authorised publishing flows. A source flow is not proof that the same flow exists on every gateway or deployed revision.
Dhruv service boundary
Use approved CMS and Player HTTPS origins. Device enrolment, credentials, manifest, asset delivery and heartbeat stay authorised and scoped to the relevant tenant, site and device.
- Do not treat a 200 HTML SPA fallback as a successful API test.
- Do not use a shared fleet credential or paste production tokens into shared diagnostic examples.
- Keep browser-only perimeter authentication separate from machine device and media flows.
Hosted edge and private services
External clients should reach the approved HTTPS edge. Dashboard, Core API, database and optional controller services should remain private and only communicate across the documented internal path.
- Expose TCP 443 only at the intended public edge; TCP 80 is conditional for certificate/redirect design.
- Restrict SSH through an approved VPN or bastion with key-based access and no public password login.
- Review Docker publication, host firewall and provider firewall together; bind diagnostics to loopback where justified.
Amino and display control
Amino H200 and local panel-control paths are conditional. Confirm actual model, firmware, region, service and current vendor matrix before adding any dedicated management connection.
TLS, proxy and identity
Use stable approved FQDNs, valid hostname-matching certificates and device-trusted chains. Do not fix proxy, certificate or access problems by disabling validation or forwarding credentials across hosts.
06 / Commissioning and handover
Commission the installation, not merely the port.
A network reachability test does not prove a device, application, stream or user workflow has passed. Record whether an outcome was requested, acknowledged and physically observed; retain non-secret evidence, owner and rollback reference for each selected condition.
Acceptance layers stay separate: engineering checks, live deployment, physical device/content tests and customer acceptance each require their own evidence. Use the browser tracker to organise readiness—not to replace the formal site record or sign-off.
Interactive commissioning tracker
Track evidence as the site is proved.
Only mark a step complete after retained evidence exists. Not applicable items still need a reason and owner in the project handover record.
Browser-only progress: the selected check marks are stored locally in this browser only. No evidence files, site details, device identifiers, customer data or operational data are sent to Dhruv by this tracker.
Quick page finder
Go directly to the relevant implementation record.
The full guide is organised for handover conversations: find the relevant section, populate the site-specific value and retain the final approval record.
Guide page 5
Destination hostname register
Start allow-list planning with CMS, Player and media-host roles.
Guide page 6
Dhruv API endpoints
Confirm authorised administration, enrolment, content and heartbeat route boundaries.
Guide page 7
Baseline firewall requirements
Approve core player, CMS, media, DNS, time and address-service paths.
Guide page 8
Hosted server and private service ports
Keep the public HTTPS edge separate from dashboard, API and database services.
Guide page 9
Live-streaming port matrix
Choose the actual transport and record source, destination, direction and configured ports.
Guide page 13
Amino H200 setup and cloud ports
Apply only the selected vendor profile and region after confirmation.
Guide page 19
Commissioning checklist
Retain evidence for inventory, TLS, enrolment, playback, recovery and isolation.
Guide page 21
Firewall request and handover form
Capture the final site-specific rule register, approval and rollback evidence.
Implementation FAQs
Clear scope. Safe approval.
This guide records implementation boundaries. It does not certify a live deployment, grant a provider licence, confirm a screen model, or replace the final site tests.
Prepare the site-specific record
Use the guide to turn a broad technical request into a controlled implementation plan.
Share the selected profiles, device estate, site network constraints and planned stream path before requesting a final firewall or commissioning approval.