SVSI (AMX / HARMAN Networked AV)

Network Ports & Requirements

Port(s)	Transport	Direction	Purpose	DSCP	Multicast	Config.
50001	UDP	Both	Native SVSI control traffic for the local Networked AV platform. Blocking or filtering this can prevent discovery/control/routing behavior expected by AMX tooling and controllers.	—	—	No
50001	TCP	Both	Native SVSI control sessions for local device control and routing workflows. Keep this inside the AV/control management boundary rather than exposing it broadly.	—	—	No
50002	TCP	Both	Native SVSI control sessions for local device control and routing workflows. Keep this inside the AV/control management boundary rather than exposing it broadly.	—	—	No
50002	Multicast	Both	Native SVSI video stream transport for local multicast-oriented branches. This is the primary payload that will flood a poor switch design.	—	—	No
50003	Multicast	Both	Native SVSI audio stream transport. AMX compatibility guidance notes audio can cross product branches differently from video, so audio routing must be traced separately.	—	—	No
50004	TCP	Both	Serial extension / pass-through associated with SVSI endpoint control workflows. Required only where serial transport is part of the design.	—	—	No
50006	TCP	Both	KVM transport/control path for SVSI products that support KVM. Required only where USB/KVM behavior is part of the workflow.	—	—	No
80	TCP	Inbound	Device web server / browser management. Restrict to AV management hosts or a management VLAN.	—	—	No
443	TCP	Inbound	Device HTTPS web server / secure browser management where enabled. The AMX pre-implementation guide lists HTTPS webserver paths in addition to plain HTTP.	—	—	No
22	TCP	Inbound	SSH / Telnet management access where enabled. Keep inside the AV management boundary and disable if the project security standard does not allow interactive shell access.	—	—	No
23	TCP	Inbound	SSH / Telnet management access where enabled. Keep inside the AV management boundary and disable if the project security standard does not allow interactive shell access.	—	—	No
20–21	TCP	Inbound	FTP/file-transfer path where enabled for legacy or maintenance workflows. Do not expose outside management hosts; prefer disabling if not required.	—	—	No
1319	Endpoint-dependent	Both	`ICSP` / AMX control path where a deployed SVSI workflow uses NetLinx/AMX control integration. Do not copy this onto HControl-only integrations automatically; confirm the exact endpoint/control-family guide.	—	—	No
4197	TCP	Inbound	`HControl` direct-control API for supported current AMX/HARMAN devices. Text-based, JSON-like command model used by AMX and third-party control systems.	—	—	No
50005	UDP	Both	`N-Command` control/status path for systems using the AMX Networked AV controller/management layer. Schedule only when that layer is present.	—	—	No
50006	UDP	Both	`N-Command` control/status path for systems using the AMX Networked AV controller/management layer. Schedule only when that layer is present.	—	—	No
50020	TCP	Inbound	Direct Control API path listed by AMX for Networked AV control/management workflows. Confirm exact API document, endpoint family, and authentication/security posture before permitting.	—	—	No
3001	TCP	Inbound	Panel Builder path for AMX Networked AV management/user-interface workflows. Required only where Panel Builder is deployed.	—	—	No
18888	UDP	Both	Transport-stream path for compressed-stream branches where transport-stream output/input is used. This is not part of the native low-latency multicast baseline.	—	—	No
8080–8081	TCP	Both	HTTP Live / HLS-oriented streaming path listed by HARMAN for SVSi. Use only for the chosen streaming profile and destination workflow.	—	—	No
8554	TCP	Both	`RTSP` control path listed by AMX for compressed-stream branches. Actual media and firewall behavior must be built from the configured streaming mode and destination.	—	—	No
50011	UDP	Both	`RTCP` path listed by AMX for compressed-stream branches. Pair with the actual `RTP`/`RTSP`/destination profile rather than assuming this is enough for third-party streaming.	—	—	No
6850	Endpoint-dependent	Both	HARMAN-documented SVSi `Signal` paths. Treat as endpoint/feature-specific until the exact product-family guide and enabled services are checked.	—	—	No
59700	Endpoint-dependent	Both	HARMAN-documented SVSi `Signal` paths. Treat as endpoint/feature-specific until the exact product-family guide and enabled services are checked.	—	—	No
52367	Endpoint-dependent	Both	HARMAN-documented RS-232 and IR paths for SVSi sideband control. These are separate from native media and should only be opened where sideband control is part of the design.	—	—	No
59401	Endpoint-dependent	Both	HARMAN-documented RS-232 and IR paths for SVSi sideband control. These are separate from native media and should only be opened where sideband control is part of the design.	—	—	No
60000	Endpoint-dependent	Both	`Dante AV-A` path listed by HARMAN for SVSi products supporting that branch. This does not imply ordinary SVSI endpoints use Dante AV; confirm transport and controller requirements from the submitted endpoint guide.	—	—	No
50201	Endpoint-dependent	Both	`Dante AV-H` path listed by HARMAN for SVSi products supporting that branch. Confirm actual Dante AV profile, transport, controller workflow, and Audinate tooling requirements.	—	—	No
319	Multicast	Both	`PTP` timing messages where `AES67` audio synchronization is used. Not every SVSI video workflow uses this timing plane.	—	224.0.1.129	No
320	Multicast	Both	`PTP` timing messages where `AES67` audio synchronization is used. Not every SVSI video workflow uses this timing plane.	—	224.0.1.129	No
5353	Multicast	Both	Local discovery may appear in mixed AV/control environments through mDNS-capable devices or companion software; confirm per endpoint and management tool rather than assuming all SVSI paths use it.	—	224.0.0.251	No

AV500.io

Gotchas & IT Notes

• ⚠Use managed gigabit switching as the starting point. AMX's current minimum-network guide treats managed switching, gigabit links, `IGMP` snooping, an `IGMP` querier, and correct leave behavior as baseline requirements for the local Networked AV stream families.
• ⚠Do not allow unregistered multicast to flood ordinary user ports. The design must define where multicast is permitted, where it is blocked, and where control-only ports sit.
• ⚠`Immediate Leave` / `Fast Leave` is not a cosmetic setting. AMX's current guidance says `Immediate Leave` is required for all N-Series devices, but it conflicts with daisy-chained multi-unit home runs inside the same `VLAN`; resolve that topology choice before installation.
• ⚠Uplink math must include querier behavior, not just intentional receiver destinations. AMX's current guide warns that `IGMPv2` designated-querier behavior can place encoder streams on uplinks between the source switch and the querier even when a remote decoder is not intentionally using the stream.
• ⚠Keep video, audio, and control traffic separated where practical. AMX's pre-implementation guidance recommends separate `VLANs` for those traffic classes on converged networks and says worst-case bandwidth should be calculated for the deployed stream family.
• ⚠Do not assume discovery/control follows enterprise routing. AMX's pre-implementation guidance says control software or control devices must have an address in the same subnet as the Networked AV devices. If centralized management crosses subnet boundaries, document the management appliance, routing/firewall path, and discovery/enrollment method explicitly.
• ⚠Do not put control systems on ports that receive unnecessary video multicast. AMX's pre-implementation guide explicitly calls out blocking `IGMP` reception on control-system-connected ports.
• ⚠Standard `10/100` links are hard failure points. AMX warns that one `100-BaseT` switch/router in the video pathway can degrade or block the signal.
• ⚠Jumbo frames are branch-specific. AMX's current minimum-network guide calls them out for some local stream families, with a recommended minimum `MTU` of `9000`; do not enable jumbo frames only on one switch and call the job commissioned.
• ⚠QoS exists as a tool, not a substitute for capacity. AMX's current guide says `DSCP` values can be configured if `QoS` is required, but capacity, multicast discipline, and stream-family selection still decide whether the system works.
• ⚠Routed multicast is a designed service, not a default consequence of VLAN routing. Where streams must cross subnets, AMX's current minimum-network guide points to `PIM-SM` and a configured rendezvous point; `PIM-SSM` depends on `IGMPv3` support on the selected branch, while dense-mode and bidirectional `PIM` are not recommended for this family.
• ⚠`TCN` flooding should be disabled on relevant N-Series VLAN ports where supported. AMX warns that topology-change flooding can interrupt streams during device adds/removals, so acceptance testing should include a controlled patch/reboot event rather than only static full-system playback.
• ⚠`H.26x` third-party streaming is a separate allowlist exercise. If the design targets Panopto, Wowza, YouTube, Facebook, a media server, or a custom `RTSP` / `RTMP` / `RTMPS` / `RTP` destination, document the exact profile, destination host, security model, and firewall path separately from the local SVSI multicast baseline.
• ⚠`HDCP`-protected content is not available to third-party viewers or ordinary software decoders. AMX says protected content is encrypted and the compatibility guide explicitly blocks protected-source streaming to third-party devices.
• ⚠Brownfield estates need software support review. Current `N-Able` release notes state that legacy `V-Series` is no longer supported starting with the 2023-09-03 release.
• ⚠Use `50002` for third-party endpoint control unless the submitted AMX documentation says otherwise. HARMAN's current support article says `50001` is generally used by `N-Able`, and each of the two control ports supports only one active connection. This is a real day-two fault source when a controller and management workstation fight for the same session.
• ⚠Treat HARMAN's AMX device-port list as a common-defaults inventory, not a universal allow-anywhere rule. Many services are optional, feature-specific, or disable-able; the design should explicitly say which of web/HTTPS, SSH/Telnet, FTP, `ICSP`, `HControl`, direct API, `N-Command`, sideband serial/IR, `AES67`, `Dante AV`, transport-stream, and HTTP Live are actually enabled.
• ⚠`HControl` can expose DSCP, multicast-address, multicast-allow/shutdown, discovery, and status paths on supported families. That is useful for commissioning and control, but it also means security review must cover what the control API can change, not merely whether `TCP 4197` opens.
• ⚠If secure command-port mode is enabled, do not keep testing only the clear-mode control ports. HARMAN's current security article says the unsecure command ports become non-responsive, regular control ports are incremented by `100`, the persistent secure connection requires SSL, and direct-API command framing changes because the command password is prepended. That is a control-system integration issue as much as a firewall issue.
• ⚠Stream encryption is not the same as `HDCP`, `HTTPS`, or `TLS` management. HARMAN's current security article says encrypted streams are not viewable in VLC, so acceptance must prove the selected decoders, monitoring tools, recorders, and software viewers still work in the intended security mode.
• ⚠On an existing shared network, stage encoder enablement instead of lighting every transmitter at once. AMX's pre-implementation guide explicitly warns that video packet volume can overwhelm a segment, `VLAN`, or device even when the network is nominally gigabit-capable.
• ⚠A valid firewall schedule for SVSI is feature-gated. The 2026 HARMAN port FAQ intentionally points back to the Pre-Implementation Guide rather than replacing it with a tiny static list; the submittal still has to state whether the project uses native local multicast, compressed third-party streaming, `AES67`, `Dante AV`, `HControl`, sideband serial/IR, KVM, management appliances/software, or web/SSH/FTP maintenance.
• ⚠Do not translate AMX's "standard IP hardware" language into a generic firewall-port request. The current AMX family page still frames SVSI as an AMX-managed product ecosystem with platform-specific management, security, audio, video, and control behavior; the port schedule follows the selected stream family and enabled services, not the marketing category.
• ⚠Include the day-two services in the network/security handoff. Current HARMAN SVSI support material makes syslog, secure web-page disable/enable, hotfix/maintenance-mode workflows, HControl-family documents, and switch-profile guidance live operational concerns. If those workflows are expected after handover, they need named source hosts, ports, credentials/certificates, logging destination, and maintenance-window ownership; otherwise they should be deliberately disabled or left out of the firewall rule set.
• ⚠Do not turn a switch-vendor recipe into a portable spec. HARMAN's current UniFi article reinforces the same design intent as the AMX minimum-network guide, but the accepted deliverable is feature/counter evidence: VLAN membership, jumbo frame state where needed, `IGMP` snooping and querier behavior, leave behavior, multicast group table, uplink utilization, error/discard counters, and endpoint receive behavior under worst-case routing.