Hints and Tricks (ALTA in General)

Planning a deployment

Alta is distributed as a ready-to-run VMware/VirtualBox OVA, an AWS AMI, or a pre-configured ProLiant hardware appliance — there's no standalone Linux installer, and the software isn't supported when installed onto a customer-built VM or bare-metal server. If your environment has restrictions on which OS images are approved (a common issue in locked-down AWS accounts), the OVA route onto an approved VM is the usual fallback when the AMI can't be launched directly.

Whichever path you choose, treat it as the full appliance: don't add third-party endpoint security agents, don't apply ad hoc OS patches, and don't hand-edit configuration files outside the Alta web interface. All of these are unsupported and have caused real outages — from crashed REST services to broken network settings — that were entirely avoidable.

Undersized compute is one of the most common causes of "Alta is unstable" tickets, and it's entirely preventable. As a rule of thumb, budget around 2 CPU cores for the base OS and web services, plus roughly 1.5 cores per active channel (double that if a channel's stream exceeds 25 Mbps), and about 4 GB of RAM for the first channel plus 1 GB for each additional one. A single 1 Gbps network interface comfortably handles around 20 streams at up to 25 Mbps each — don't plan on sustaining much above 500 Mbps through it.

On cloud platforms, watch out for "burstable" instance types: they perform fine until burst credits run out, at which point throughput drops and packets start dropping. Size for your sustained bitrate, not the burst ceiling, and consult the current Alta TS / Alta 2110 scaling guide on the support portal for numbers specific to your channel count.

Alta's traffic naturally splits into three roles: outbound internet access (for licensing and iCap/cloud connectivity), local management (the web UI), and media/transport-stream traffic. You can run all three over one NIC or split them across several — but plan which role each interface plays before you start configuring, since Alta only supports a single default gateway at a time (more on that below).

Every Alta deployment ships with a documented default username and password for its web interface — the exact pair has varied across OVA/AMI releases over the years, so always check the setup guide that matches your current image rather than assuming last year's credentials still apply. Whatever it is, change it right after first login, and do it through the Alta web UI rather than by editing OS-level files directly.

Licensing, done right

Alta validates network-activated licenses by making an outbound HTTPS connection on port 443 to Ai-Media's licensing service. The classic gotcha: DNS resolves the hostname just fine, but the actual TCP/TLS connection is still blocked by a firewall, proxy, or security group — so the license check fails even though "ping" or "nslookup" looks healthy. If licensing won't validate, confirm the real HTTPS connection works end to end, not just that the name resolves.

The reverse is also worth knowing: a freshly activated network license can correctly show "0 installed licenses" in some UI views — that's expected for this license type, not a failure. Use the license manager's connectivity/validation check rather than that counter to confirm things are actually working.

A standard cloud-activated license depends on Alta being able to periodically reach the licensing service. If a unit loses internet access for long enough, the affected channel can stop — and on some builds it won't automatically resume once connectivity returns; it needs a manual restart. For workflows where continuous captioning is a hard requirement (regulatory obligations, live-to-air with no room for a gap), ask about an offline/permanent license file instead: it keeps the encoder running through an internet outage, and only optional cloud features are affected, not the core encoding.

A single license key can cover multiple concurrent channels or instances, and it isn't tied to any specific piece of hardware — you can run licensed channels across several VMs as long as you don't exceed the total the key allows. It's easy to lose track of this as a deployment grows: spinning up an extra test or staging instance under the same key silently consumes a seat, and if that pushes you over the limit, otherwise-healthy production channels can start failing licensing with no obvious cause. When you see a licensing failure with no recent config change, checking active-channel count against your licensed seat count is worth doing before anything else.

Firewalls & connectivity

Licensing and iCap/Lexi cloud connectivity are separate services with their own connectivity requirements — allowing outbound 443 to the licensing domain doesn't automatically cover iCap. Ai-Media publishes a networking and firewall requirements article specifically for this; pull the current version before locking down a new deployment's outbound rules, since the exact ports and destination ranges are maintained there rather than in general product documentation. In practice, most "it worked in the lab but not on the customer's network" tickets come down to one item on that list being missed — commonly an outbound UDP range, not just the TCP ports.

It's tempting to drop into a shell and edit network configuration files directly, especially for anyone comfortable with Linux — resist it. Alta's web-managed network configuration and the underlying OS files aren't designed to be edited interchangeably, and manual edits are a common cause of a network page that silently stops reflecting reality, or breaks NMOS/static binding entirely.

If a network configuration does get into a broken state, there's a recovery path: browse to <alta-ip-address>/admin, select only the network-related restore options, and run a system restore. This clears all network settings, which you then re-enter from scratch through the normal Network Configuration page — treat it as a clean slate, not a patch.

On a multi-NIC deployment, only one interface can hold the default gateway at a time, and that's the interface Alta will use to reach the internet — including the licensing and iCap services. If the gateway ends up assigned to your media/transport interface rather than your management or internet-facing one, licensing calls can fail even though everything else (including NMOS registration) looks correct. Decide up front which NIC owns internet-bound traffic, and make sure it — not just any interface with a routable IP — is the one carrying the default gateway and working DNS.

Keeping a stream stable

Alta's transport-stream handling expects a constant bitrate (CBR) input — a variable or bursty source is one of the most common root causes of buffer warnings, dropped output, and "out of sync" errors that otherwise look mysterious. If your upstream encoder can only produce VBR, converting it to CBR before it reaches Alta will resolve more issues than almost any setting on the Alta side.

Once the input is stable, set Alta's own output rate a couple of Mbps above the actual input bitrate rather than matching it exactly. An output rate set too close to (or below) the input rate is a frequent cause of buffer-full alarms and dropped frames, especially on longer-running channels.

If channel logs show something like a "send buffer runout" or a prompt to increase the target UDP buffer size, that's exactly what to do: the output/UDP buffer size defaults to a modest value, and it's a deliberately conservative starting point rather than a tuned setting. Increase it — doubling it is a reasonable first move — and then step back down in smaller increments once the stream is stable to find the smallest value that still holds. Larger GOP sizes and longer, higher-latency network paths both call for a larger buffer.

Alta's forward error correction (FEC) detection automatically treats the two ports immediately after an input port as FEC data for that same channel. If you run multiple independent channels with input ports spaced closely together (for example 5000, 5002, 5004), a later channel's stream can get misinterpreted as FEC traffic for an earlier one. Space multi-channel input ports at least five apart — 5000, 5005, 5010, and so on — to avoid this entirely.

SRT connections can run in caller mode (Alta initiates the connection) or listener mode (Alta waits for the far end to call in). Where either is workable, listener mode has generally proven the more resilient choice — caller-mode SRT has historically been more prone to reconnect issues after a gap in the input, sometimes requiring the channel itself to be restarted before the stream will re-establish. To set Alta up as a listener, use an address in the form srt://0.0.0.0:<port> and have the sending device call in to Alta's IP on that port.

Captions & audio

If the audio PID field is left blank, Alta will caption whichever audio track it happens to detect first — which, on a multi-track source, can easily be the wrong one (crowd noise instead of commentary, for instance). Set the audio PID explicitly for every channel, and when mapping several languages or audio programs, use the correct separator: a colon separates distinct programs that should each go to their own caption service, while a comma mixes the listed channels down into a single stream. Mixing up the two is a common reason a multi-language setup captions correctly with one language enabled but breaks once more are added.

Sharing one iCap username across multiple encoders or channels causes them to repeatedly force each other offline, since iCap treats a second login with the same credentials as a takeover. The fix is straightforward and permanent: create a distinct iCap username for every encoder instance, including geo-redundant or backup units. This applies just as much to third-party systems that integrate via the iCap SDK as it does to Alta itself.

Pop-on rendering waits until a full line is ready before displaying it, which reads cleanly but adds latency — and can make a caption line appear to "stall" if a speaker pauses mid-sentence, since the trailing word is held until enough new text arrives. Roll-up display shows text as it's generated, trading some visual polish for noticeably lower end-to-end latency. If a workflow is sensitive to caption delay, roll-up is usually the better default; if on-screen presentation matters more than speed, pop-on is the better fit.

Building in resilience

Alta doesn't support bonding two NICs together for hardware-level failover. The supported pattern is to run a primary and a secondary encoder on separate servers, both assigned to the same iCap access code. Failover to the secondary is triggered specifically by the primary losing its iCap connection — not by the primary simply losing its input source while it stays connected to iCap. If your primary keeps retrying a dead input feed without ever dropping from iCap, the secondary will never take over automatically; in that scenario, manually powering off the primary channel is what actually triggers the switch.

In an active-active or primary/secondary setup, both encoders consume a license seat the moment they're running — even if only one is actively processing captions at any given time. It's easy to size a license key for the number of "real" channels you need and forget to add seats for their standby counterparts, which then surfaces as an unexpected licensing failure only once the redundant pair is actually deployed. Note that this is separate from any usage-based captioning subscription, which is typically billed only for the one instance actually tied to the active access code.

Support & upkeep

Almost every support case ends up asking for the same three things, so gathering them up front consistently cuts a ticket's resolution time. First, set the affected channel's logging/verbosity level to its most detailed setting and reproduce the issue — the default logging level often omits exactly the detail needed to diagnose an intermittent problem. Second, generate a full system report from the Alta web UI's System/Report page with every option selected. Third, if the issue is stream-related, use the channel's built-in input capture feature to grab a couple of minutes of the raw incoming stream.

It also helps to note the specific channel or instance identifier (visible when you click into that channel) rather than only its friendly name, and the approximate timestamp of the issue — logs rotate, so the sooner a report is pulled after an incident, the more likely the relevant detail is still there.

Software updates are applied entirely through the Update page in the Alta web portal — no SSH access is needed. Some fixes and features depend on both the encoder component and the REST API/web component being on matching versions, so when a release note mentions both, install them together rather than one at a time. There's no supported in-place downgrade path, so treat rolling back a version as something to request from support rather than attempt independently.

Alta's underlying OS goes through periodic end-of-life cycles, and Ai-Media provides advance notice and free updated images when a migration is coming. The one detail worth planning around early: if your Alta runs on a physical hardware appliance rather than a VM, an OS rebuild generally can't be done in place — the unit needs to be shipped back for the rebuild, which takes real lead time and can carry shipping and engineering costs. Knowing which category your deployment falls into, and flagging it when you open a related ticket, is the fastest way to get an accurate timeline.