Biamp Tesira / Tesira Control

Network Ports & Requirements

Port(s)	Transport	Direction	Purpose	DSCP	Multicast	Config.
61451	TCP/UDP	Both	Primary Tesira software/device discovery and communication. Required between Tesira software / Biamp Canvas / SageVue-style tools and Tesira devices, and between devices that need the proprietary Tesira control plane. Do not confuse this with third-party `TTP` control.	—	—	No
22	TCP	Inbound	`SSH` access to the Tesira `TTP` server for secure third-party control of DSP objects or `SSH-to-Serial` Control Tunneling. Disabled by default and should be enabled only where the control design requires it.	—	—	Yes
23	TCP	Inbound	`Telnet` access to the Tesira `TTP` server for legacy third-party control. Disabled by default, unencrypted, and a poor production choice except where a legacy control stack leaves no better option. Requires real Telnet negotiation, not a generic raw TCP client.	—	—	Yes
232	Serial	Both	Native serial access to `TTP`, or serial-command-string output / serial tunnel endpoints depending on the Tesira configuration. No IP/firewall port exists; document connector, baud/framing, command terminators, authentication behavior in protected systems, and ownership of the serial path.	—	—	Yes
61452–61453	TCP	Both	Optional Tesira Control Tunneling support. Treat as a point-to-point serial-extension feature inside a Tesira system, not as the normal third-party `TTP` command port and not as a general traffic tunnel.	—	—	No
1–65535	TCP/UDP	Both	Optional user-defined `NCS` ports when Tesira initiates bidirectional command-string communication with non-Tesira network devices. Do not open the whole range; schedule only the specific remote and local ports configured in the Tesira file, including UDP local-port expectations where relevant.	—	—	Yes
12003	TCP/UDP	Both	Supplemental proprietary device discovery. Biamp's current article lists this in the all-system table and server-class tables; treat it as Tesira discovery/control-plane support, not as third-party `TTP`.	—	—	No
5353	Multicast	Both	mDNS device discovery — Tesira devices announce themselves on the local network using this standard, so Tesira software can automatically find them without needing to know their IP addresses.	—	224.0.0.251	Yes
5060	TCP/UDP	Both	SIP signalling — used only if Tesira is being used as a VoIP endpoint (e.g. connecting to a phone system for conferencing). Not required for standard audio processing.	—	—	Yes
5062	TCP/UDP	Both	SIP signalling — used only if Tesira is being used as a VoIP endpoint (e.g. connecting to a phone system for conferencing). Not required for standard audio processing.	—	—	Yes
5061	TCP	Both	Encrypted SIP signalling (TLS) — secure version of SIP call setup; used when the phone system requires encryption.	—	—	Yes
5063	TCP	Both	Encrypted SIP signalling (TLS) — secure version of SIP call setup; used when the phone system requires encryption.	—	—	Yes
4000–65535	UDP	Both	RTP/SRTP — the actual audio of VoIP calls passing through Tesira. Only required if Tesira is being used as a phone or conference bridge endpoint.	—	—	Yes
443	TCP	Outbound	HTTPS — used for software licence activation and communicating with Biamp's cloud servers. Required during initial setup and licence renewal.	—	—	No
2	Layer 2	Both	AVB audio transport and device discovery — used only when a Tesira unit has an AVB card fitted. AVB operates at a lower network layer than IP and has no port numbers — it cannot be filtered by an IP firewall.	—	—	No

AV500.io

Gotchas & IT Notes

• ⚠**TCP/UDP 61451 is critical for Tesira software/device communication** — device discovery and configuration communication from Tesira software runs through it. It is not the default answer for a Crestron/AMX/Q-SYS-style controller that needs `TTP`; that controller normally needs `SSH`, `Telnet`, or serial access.
• ⚠Tesira uses multicast in the `224.0.0.251-254` range for discovery. Biamp identifies `224.0.0.251` for mDNS hostname resolution, `224.0.0.252` for server-class peer discovery, `224.0.0.253` for server-to-remote discovery, and `224.0.0.254` for remote-to-server discovery. Register these multicast groups on switches where required.
• ⚠AVB transport (IEEE 1722) is **Layer 2 only** — no IP port numbers. Requires AVB-capable switches; cannot be filtered at Layer 3 firewall.
• ⚠Third-party `TTP` access is a session behavior, not just a firewall line item. `TTP` subscriptions are lost on disconnect/reboot and must be re-established by the controller; command strings should be validated against live `+OK` / `-ERR` responses, not assumed correct from a drawing note.
• ⚠If `SSH` or `Telnet` is refused, verify that the service is enabled in Tesira network settings before escalating to IT. Biamp documents both as disabled by default.
• ⚠If Tesira system security is enabled, `TTP` requires credentials; third-party automation that changes DSP object settings needs a user with at least `Controller` privileges. Coordinate this before security hardening or the room controller will stop working.
• ⚠If SageVue system control is enabled, treat it as a control-interface change, not just centralized monitoring. Biamp documents that it locks admin maintenance behind SageVue and password-protects `TTP`; the controller account and credential owner must be documented before hardening.
• ⚠`Telnet` support is not raw TCP. Biamp documents a Telnet negotiation/welcome-banner requirement, so drivers that only open a plain TCP socket can fail even when port `23` is reachable.
• ⚠Serial `TTP` also has security/session behavior in protected systems. Do not treat a serial path as automatically safe or stateless.
• ⚠`NCS` is a Tesira client-side integration block for outward communication with non-Tesira network devices. The correct firewall request is the exact configured destination/source behavior, not "open all user-defined ports."
• ⚠In `NCS` designs, prove the client/server role. Tesira's block initiates the network communication toward the configured target; if the third-party device also expects to initiate rather than listen, the design is wrong before the firewall is involved.
• ⚠`Control Tunneling` is point-to-point and narrow. It is useful for carrying serial control through the Tesira estate, but not a multi-client control fabric; `SSH-to-Serial` tunnel use must allow for one active SSH client session and re-authentication after disruptive device/network changes.
• ⚠Routed-subnet Tesira control requires configured server-class devices, hostname resolution, valid default gateways, and explicit distant-server entries. Expanders, remotes, and microphones remain same-subnet with their relevant host/proxy.
• ⚠On current multi-network Tesira room hardware, TTP may be reachable at multiple configured interface addresses depending on port mode. That is not permission to expose every interface broadly; pick the management/control interface intentionally and firewall the rest by role.
• ⚠SIP and RTP ports only required if Tesira is used as a VoIP endpoint.
• ⚠Do not enable Telnet (port 23) in production — it is unencrypted. Use SSH if remote CLI access is needed.
• ⚠Tesira devices should **not** be directly internet-facing — place behind firewall.