Teradek Prism SRT Presets for Cloud OBS: Caller, Listener, and Recovery Runbook

The job is a repeatable preset, not an unexplained SRT URL

Teradek's current Prism documentation describes SRT stream modes with Caller, Listener, and Rendezvous connection types, plus host, port, stream ID, encryption, latency, and interface choices. That is enough flexibility to build a solid field contribution, but it is also enough flexibility to create a configuration nobody can recover when a show starts late.

Build a named preset for each real job: FIELD MAIN SRT, FIELD BACKUP SRT, or VENUE WIRED SRT. Record the destination role, connection type, network interface, target latency, video profile, audio plan, and fallback action. Do not put the passphrase or private endpoint in a broadly shared show sheet.

The encoder should contribute a stable feed into StreamableRun. Cloud Hosted OBS should handle scenes, viewer-facing fallback, destination routing, monitoring, and producer handoff. That division keeps a source transport setting from becoming the only place the whole show can be controlled.

Caller, Listener, and Rendezvous are routing decisions

In Caller mode, the Prism encoder initiates the connection to a remote host and port. This is often the easier mental model for a field contribution to a known cloud receiver: the mobile encoder pushes out to the published destination. It still requires correct firewall, port, authentication, and DNS assumptions.

In Listener mode, the encoder waits for a client to connect. It can be useful in designs where the receiver initiates the connection, but it is not automatically better for a mobile encoder behind changing carrier NAT. Test the actual network, not the diagram you wish the venue had.

Rendezvous has both endpoints connect and can be useful where each side has inbound restrictions, as Teradek documents. It is a specific network technique, not a generic retry switch. Use it only when the receiver and network design support it and the team can verify the handshake in rehearsal.

• Caller: field encoder reaches a known destination.
• Listener: encoder waits for a receiver to connect.
• Rendezvous: both endpoints initiate, for a deliberate compatible design.
• For every mode: verify host, port, Stream ID, encryption, and recovery owner.

Latency is a reliability budget

Prism documents latency in milliseconds and notes that higher values improve reliability on unstable networks while lower values reduce end-to-end delay. That is a tradeoff, not a universal recommendation. A crowded street, moving vehicle, or weak cellular location needs room for packet recovery; a controlled wired studio can operate with less buffer after testing.

Choose an initial latency from the actual route and then rehearse with movement, audio, and deliberate disruption. Watch whether the SRT contribution recovers, whether audio stays locked, and how long viewers see the delay after the Cloud OBS program and destination processing. The number on the encoder is only one part of total viewer latency.

Do not lower latency to make chat feel faster if the result is a contribution that tears or disconnects. If interaction needs a tighter loop, consider the complete production design: platform mode, contribution network, scene complexity, moderator workflow, and the show format.

Encryption, Stream ID, and interface selection

Enable SRT encryption when the receiving workflow supports it, then validate the matching passphrase through the actual StreamableRun ingest configuration. A mismatch should be diagnosed in a private test, not by changing security settings on a public show. Store sensitive values in the controlled configuration and state only the preset role in the runbook.

A Stream ID can identify or route a stream where the receiver requires one. Treat it as part of the connection contract: change it only with the receiver owner, document the expected value safely, and confirm the right source appears in the intended ingest. A valid SRT connection to the wrong route is still an operational failure.

Prism also lets the operator choose a network interface. On a device with multiple paths, do not assume Auto will make the production choice you intended. During rehearsal, identify the interface used, test a handoff or loss if relevant, and know whether the encoder reconnects to the desired route.

Build an encoder preset that a second operator can run

Use preset names that say what the route does. FIELD MAIN SRT TO CLOUD is more useful than Preset 3. Include the codec, resolution, frame rate, bitrate policy, audio configuration, and network interface in the associated runbook. Keep firmware and preset version notes nearby so a replacement unit can be configured deliberately.

Start with a conservative contribution profile and only increase complexity after it passes. A field source that stays available gives Cloud Hosted OBS something to produce. A very ambitious profile that disconnects creates work for every role at once: camera operator, encoder owner, producer, moderator, and destination monitor.

Keep one tested backup preset. It can use a lower bitrate, a different connection, or a separate physical source, but it must be rehearsed. A backup that exists only as a hopeful option in a menu is not a backup.

• Main preset with named destination role.
• Backup preset with a tested lower-risk path.
• Documented video, audio, latency, interface, and security settings.
• Private location for connection secrets.
• Known operator and escalation contact for the receiver side.

Cloud OBS scenes and destination control

Send the chosen Prism contribution into a named StreamableRun ingest. In Cloud Hosted OBS, prepare a main scene that contains that contribution, a backup scene tied to an independent ingest, a fallback scene, and a technical recovery scene. The producer should be able to take fallback without needing the field encoder's web interface.

Keep destinations such as Twitch, Kick, YouTube, or custom RTMP configured in the cloud operating layer. If an output needs attention, the producer can validate it while the encoder operator keeps the source stable. This avoids the dangerous habit of editing platform destinations on the field unit during a cellular problem.

During a producer handoff, identify the active Prism preset by role, the expected StreamableRun ingest, the Cloud OBS scene, the backup source, and the fallback trigger. The handoff is complete when the next operator can verify each layer without asking for a screenshot of an encoder menu.

Failure drills that reveal bad assumptions

Run a clean baseline first, then test a source restart, network interruption, wrong-preset scenario, and destination issue. For each drill, observe the Prism status, StreamableRun ingest, Cloud OBS program, and a normal viewer preview. Logging only the encoder state can hide a problem that viewers can already see.

On contribution loss, the producer takes fallback. The encoder operator checks network and preset state, then restores the main or backup contribution. The producer waits for stable picture and audio at the final destination before returning. This order gives the audience a coherent program while technical work happens behind it.

If encryption, Stream ID, or port changes are needed, make them in the controlled test window and rerun the whole route. A partial connection test is not enough because the source may connect yet still be routed to the wrong job or arrive without expected audio.

• Kill the source and verify fallback timing.
• Change or disable the intended network interface in rehearsal.
• Validate main and backup preset labels against the correct ingest.
• Verify destination preview after source restoration.
• Record the recovery duration and any operator confusion for the next revision.

Other resources and final decision

Use Teradek's current documentation for the device-specific controls and the SRT documentation for transport behavior. Promote a preset only when its routing, recovery, and handoff are repeatable. The right preset is the one that an operator can run, a producer can monitor, and a team can recover without exposing credentials or improvising network architecture.

Venue arrival checklist

Arrive early enough to validate the physical input, encoder power, network path, and receiving ingest before the show crew needs the camera. Confirm that the intended Prism preset is loaded, that its interface matches the available connection, and that the Cloud OBS scene receives the expected picture and audio.

Then walk the likely failure path. If a mobile route degrades, who changes interface or moves to the backup preset? If the camera loses HDMI, who takes fallback and who checks the capture chain? If the receiver rejects the connection, who verifies endpoint configuration? A clear answer prevents several people from changing unrelated controls at once.

After the event, preserve the passed preset and update only what the rehearsal or show proved. Do not overwrite a reliable baseline with experimental values just because a venue happened to have excellent service. A preset is useful when it carries operational knowledge into the next location.