SRT Passphrase and Stream ID Checklist for IRL Producers

The short answer

SRT passphrases and stream IDs should be treated like production credentials, not random setup text. Use one named ingest per source, keep passphrases out of public notes, rotate them when devices or helpers change, and test reconnect behavior before a real IRL stream.

StreamableRun is useful here because the SRT or SRTLA source can land in a managed Cloud OBS workflow instead of turning into a pile of manually shared URLs. The field device contributes video. StreamableRun owns the ingest list, scenes, fallback, destinations, and producer controls.

The practical goal is boring: the right phone connects to the right input, the producer can tell which source is live, a leaked setting can be replaced quickly, and nobody has to debug a mystery stream ID while the public stream is waiting.

What SRT is actually protecting

SRT is a transport protocol for low-latency live video over imperfect networks. Haivision's SRT project describes SRT as secure, reliable transport that can encrypt media payloads, recover from packet loss, and adapt to changing network conditions. The SRT FAQ clarifies an important detail: encryption protects the payload, while control information remains in the clear, and applications still have to handle longer reconnects.

That means SRT security is real, but it is not automatic. A passphrase does not fix sloppy source naming, public screenshots of URLs, old credentials left on backup phones, or a producer who cannot tell whether the main source or backup source is connected. The operating layer matters as much as the protocol.

For IRL streamers, SRT often appears through Moblin, IRL Pro, hardware encoders, or local OBS. The best workflow is to keep the transport settings narrow and the production workflow clear: one source, one name, one purpose, one tested fallback path.

Use stream IDs as source labels

A stream ID is not only a technical field. In a real show, it is also the label that helps the receiving side tell sources apart. Haivision's SRT documentation describes Stream ID access control as a way for upstream applications to identify and differentiate streams going to the same address and port. For an IRL team, that maps directly to source ownership.

Use human-readable patterns. Name the main phone, backup phone, fixed camera, backpack encoder, guest feed, and test source differently. Do not call everything live or stream. When a producer sees the ingest list, they should know what they are looking at without opening a private spreadsheet.

Good stream IDs also make incident review easier. If the main iPhone dropped and the backup Android saved the show, the team should be able to see that in notes, logs, and source names. A good label saves time during the stream and teaches you something after it.

• main-phone-moblin for the main iPhone or iPad source.
• backup-phone-irlpro for the Android backup source.
• fixed-booth-obs for a laptop or booth camera source.
• guest-feed-srt for a remote guest or second streamer source.
• private-test only for rehearsals, never for the real show.

Separate passphrases by role

Do not reuse one passphrase across every source forever. It feels convenient until a helper leaves, a screenshot leaks, a device is sold, or a guest source needs temporary access. Use separate passphrases for permanent team sources, guest sources, and short-lived test sources.

A permanent source can have a stable credential, but it still needs rotation rules. Rotate when a device changes owner, when a producer leaves the team, when a public screenshot includes connection details, or when you move from rehearsal to a paid event. Guest sources should expire after the show. Test sources should be deleted after the test.

StreamableRun helps by keeping source setup inside a production surface instead of random chat messages. The rule is simple: the fewer places an ingest URL and passphrase appear, the easier it is to rotate when something changes.

• Permanent source passphrase: main phone, backup phone, hardware encoder.
• Guest passphrase: one show, one guest, then rotate or remove.
• Test passphrase: private rehearsal only, not reused for public streams.
• Emergency passphrase: available to a trusted producer if the main setup fails.
• Never paste active passphrases into public chat, stream titles, screenshots, or OBS source names.

Know what the app handles and what the server handles

Moblin currently lists support for RTMP, RTMPS, SRT, SRTLA, RIST, WHIP, H.264, HEVC, multiple cameras, Twitch chat, Kick integration, and upload statistics per active connection. IRL Pro lists SRTLA bonding over multiple connections, a free bonding service, on-the-fly bitrate adjustment, an improved auto bitrate algorithm, and Twitch and Kick chat overlays. Those features help the field side survive bad networks.

The server side still has to make the feed useful. It needs to identify the source, show the producer whether it is healthy, route it into the right scene, fall back when it drops, and send the produced output to Twitch, Kick, YouTube, or a custom RTMP destination. SRT and SRTLA help contribution. Cloud OBS handles production.

That split is why StreamableRun is the best default for serious IRL teams using SRT. The field app can focus on capture and transport. The cloud server can focus on operating the public stream.

Test reconnects, not just first connection

An SRT setup that connects once is not finished. The IRL problem is what happens after a tunnel, elevator, dead zone, app restart, battery swap, or phone thermal issue. The SRT FAQ says short network interruptions may re-establish automatically, while longer interruptions are up to the application to re-establish. That is the part to rehearse.

Run a controlled test. Start the main source into StreamableRun, verify Cloud OBS sees it, cut to the main scene, then briefly interrupt the source. Switch to fallback, wait for the source to return, confirm audio is stable, then cut back. Repeat with the backup source. The point is to teach the producer the order of operations while nothing is on the line.

Log the result in plain language. Did the app reconnect by itself? Did the stream ID stay the same? Did the producer see a clear source state? Did audio return late? Did fallback keep the public output alive? Those notes are more useful than saying SRT worked.

• Test first connection from each source.
• Test source interruption under thirty seconds.
• Test longer interruption that forces the app to reconnect.
• Test wrong passphrase and wrong stream ID so the team recognizes those failures.
• Test producer fallback and return-to-live timing.
• Test destination output after the source returns.

Troubleshoot by symptom

When SRT fails, do not randomly change every setting. Pick the symptom. No connection at all points to address, port, listener/caller mode, firewall, passphrase, or stream ID. Connection but no video points to codec, scene source, or sender output. Video with stutter points to latency, bandwidth, packet loss, encoder overload, or app bitrate behavior. Good Cloud OBS preview but bad platform output points to destination settings, not the SRT ingest.

Keep the producer checklist in that order. Field source first. Server ingest second. Cloud OBS scene third. Destination fourth. If you skip straight to Twitch or Kick when the SRT source never arrived, you waste time. If you blame SRT when the YouTube output bitrate is wrong, you also waste time.

StreamableRun makes the boundaries easier to see because the source, scene, fallback, and destinations are part of one operating workflow. That does not remove troubleshooting, but it gives the team a map.

• No connection: check URL, port, caller/listener mode, stream ID, passphrase, and firewall.
• Connected but black: check sender camera, codec, Cloud OBS source, and scene visibility.
• Stutter: check contribution bitrate, latency, packet loss, phone thermals, and network path.
• Audio missing: check app mic, external mic routing, scene audio source, and return timing.
• Platform bad: check destination bitrate, keyframe interval, codec support, and stream key.

Rotation checklist

Credential rotation sounds like enterprise busywork until a live stream depends on it. For IRL teams, passphrase hygiene is just stream-key hygiene with a different name. If a setting gives a device the ability to enter your production workflow, it deserves a lifecycle.

Rotate before paid events, after staffing changes, after public screenshots, after shared guest access, and after device loss. Keep a short changelog: date, source, reason, who updated the field device, who confirmed the test. Do not put the passphrase itself in the changelog.

Also delete old test sources. Dead ingests make the dashboard noisy and give people the false impression that more backup paths exist than actually work. A small clean source list beats a graveyard of old experiments.

• Rotate guest credentials after each guest show.
• Rotate source credentials when a phone, encoder, or laptop changes hands.
• Rotate after any screenshot or screen share that might show settings.
• Delete rehearsal-only sources when the rehearsal is over.
• Confirm the new credential with a private StreamableRun test before public use.

Other resources

These guides help connect SRT credential hygiene to the full StreamableRun IRL workflow.