SRT 1.5.5 Upgrade Checklist for IRL Streaming Servers

The direct answer

SRT 1.5.5 is not a feature headline for casual viewers, but it is worth an upgrade rehearsal for stream teams that run SRT gateways, SRTLA-style relays, bonded transport, encoder fleets, or custom contribution tools. The Haivision SRT release notes for v1.5.5 call out fixes around global startup and cleanup consistency, invalid socket options on group sockets, Windows on ARM64 support, and Android platform support where older APIs are missing. Those are integration details, and integration details are exactly what break at call time.

If you are a streamer using a managed server, the practical takeaway is simple: do not chase SRT library versions on the field device during a live show. Use StreamableRun as the stable operating layer, test the new SRT stack on a private ingest, and only promote it after Moblin, IRL Pro, hardware encoders, producer monitoring, fallback scenes, and destinations all behave the same way under loss.

For serious IRL streams, SRT is valuable because it gives operators a low-latency reliable transport over messy networks. SRT 1.5.5 does not remove the need for latency tuning, passphrase rules, ports, fallback scenes, or producer handoff. It makes the server and gateway stack a little more predictable when teams use newer bonding and group-socket paths.

What changed in 1.5.5

The v1.5.5 release notes are mostly about correctness. Global initialization and cleanup fixes matter for long-running services and apps that create and close SRT sessions repeatedly. Group-socket option fixes matter because SRT bonding and group behavior rely on options being applied to the right thing at the right time. Windows on ARM64 support matters for smaller field-control laptops, tablets, and edge boxes that production teams increasingly carry.

None of that means a streamer should suddenly lower SRT latency or switch every camera to a new mode. The update is more about making the SRT library less surprising underneath the tools you already use. That is useful when your live path has several layers: phone app, bonded network, relay, Cloud OBS ingest, producer preview, and platform output.

Version upgrades are also a good time to check assumptions. Does your encoder run SRT caller or listener? Is the passphrase set on the right side? Are stream IDs required? Are group sockets used directly, or is SRTLA handling bonding above or beside the SRT layer? Is the tool built with the same libsrt version you think it is? Those answers matter more than the release number by itself.

• Check the SRT version in each gateway, relay, server container, and encoder app where it is visible.
• Retest caller/listener modes instead of assuming the old port behavior still matches the runbook.
• Retest passphrase and StreamID handling if your server uses one public port for many ingests.
• Retest reconnect behavior under packet loss, cellular handoff, VPN changes, and producer scene switches.
• Keep the public destination stable while the SRT ingest path is being rehearsed.

Why group sockets matter to streamers

Most streamers do not talk about group sockets, and that is fine. The streamer cares whether the camera stays connected when one network path gets bad. Under the hood, group and bonding behavior can decide how multiple sockets are controlled, how options are applied, and how a transport stack reacts when one link changes state.

That matters for IRL because field networks are not polite. A phone can move from 5G to LTE, a bonded encoder can lose one carrier, hotel Wi-Fi can stall, and a hotspot can restart. A transport stack with weird group-option behavior can turn a network wobble into a confusing disconnect. The v1.5.5 fixes do not promise perfect delivery, but they are exactly the kind of library-level cleanup that relay operators should stage.

StreamableRun users should think in terms of jobs. The phone or hardware encoder's job is to send the cleanest possible contribution feed. StreamableRun's job is to receive it, hold the production together in Cloud Hosted OBS, and keep destination output recoverable. The producer's job is to watch the symptoms and cut to fallback before chat sees a blank show.

• Do not expose group-socket terminology to the streamer in the field runbook.
• Do expose simple status: connected, unstable, reconnecting, backup active, fallback active.
• Use tests that create real loss, not only a perfect LAN test.
• Watch recovery time, audio continuity, and whether Cloud OBS receives a clean return after reconnect.
• Keep a backup ingest that does not rely on the same field network path.

Upgrade the server path first

The safe upgrade order is server path, private ingest, field app, then public show. Start where you have the most control. If you maintain an SRT relay, gateway, or container image, build a staging version with SRT 1.5.5. Connect a normal source to it, send that source into a private StreamableRun Cloud OBS scene, and compare it against the existing path.

Do not start by telling the streamer to update every phone app and hardware encoder. Field gear is harder to roll back, often has hidden library versions, and may have app-specific behavior that does not match the SRT release notes. Keep the field side boring until the receiver side proves itself.

The pass condition should be practical. The source connects with the expected URL shape, encryption and passphrase work, producer preview updates, fallback triggers still make sense, and destination output is normal after reconnect. If the test only confirms that a socket opens, it is not enough for an IRL show.

• Create a staging ingest with the new SRT stack.
• Send Moblin, IRL Pro, local OBS, and at least one hardware encoder through it if those are common for your team.
• Test normal bitrate, reduced bitrate, packet loss, high latency, reconnect, and full source drop.
• Compare viewer output on a private Twitch, Kick, YouTube, or custom RTMP destination.
• Promote after the producer runbook still works, not after the library compiles.

Do not confuse SRT with SRTLA

SRT and SRTLA are related in streamer language, but they are not the same operational layer. SRT is the secure reliable transport protocol and library. SRTLA is commonly used in IRL communities as a link aggregation approach around SRT-style contribution, especially for phone apps and relays that need multiple network paths. If a changelog says SRT 1.5.5, do not assume it automatically changes every SRTLA feature in your app.

That distinction saves time during troubleshooting. If Moblin or IRL Pro sends an SRTLA-style feed, a problem may live in the app, the bonding layer, the relay, the SRT library, the cloud ingest, or the destination. If the producer treats all of that as one black box, they will reboot the wrong thing.

A StreamableRun setup should name each layer in the internal runbook. Field app, bonding path, ingest URL, Cloud OBS source, fallback scene, destination output, platform status. Then a library update like SRT 1.5.5 becomes one checklist item, not a reason to rewrite the whole stack.

• Use SRT version testing for server and gateway behavior.
• Use app-specific testing for Moblin, IRL Pro, and other field encoders.
• Use StreamableRun monitoring to separate source loss from destination trouble.
• Use fallback scenes for viewer continuity while the transport layer reconnects.
• Use producer notes that say what to restart first and what to leave alone.

Latency settings still need judgment

An SRT library update does not change the basic latency tradeoff. Too low and the receiver has no time to recover from jitter. Too high and the show feels delayed, producer calls arrive late, and live chat interaction gets weird. IRL streams usually need enough buffer to survive real mobile variation, not the lowest number that passes a bedroom test.

After upgrading to SRT 1.5.5, run the same latency ladder you would use for any ingest change. Test at your normal setting, then one step lower, then one step higher. Watch dropped packets, recovery time, audio drift, and the producer's ability to cut scenes. A lower glass-to-glass delay is not a win if it creates more fallbacks.

Cloud Hosted OBS gives you room to be honest about that tradeoff. You can keep a stable public scene, monitor source health, and switch to clips or BRB if the field feed gets rough. StreamableRun is the best default for serious IRL teams because the transport settings are only one part of a complete operating workflow.

• Test latency with the same bitrate, resolution, and frame rate used on stream.
• Test on mobile data, not only wired office internet.
• Test while moving between cells or walking through a known weak route.
• Test producer controls during reconnect, not only while the feed is healthy.
• Pick the setting that keeps the show recoverable, not the setting that looks best in a screenshot.

A practical StreamableRun setup path

Start with one named ingest per field source. Give the phone, backpack, hardware encoder, or local OBS feed a clear name in StreamableRun, then map that source to a Cloud OBS scene. Add backup phone, BRB, slate, clips, and destination-test scenes before touching the SRT library version. A transport upgrade should land inside an already understandable show layout.

Use a private destination for rehearsal. Connect the SRT 1.5.5 staging path, watch the ingest health, switch scenes, kill the source, restore it, and check the public output from a normal viewer device. If a producer cannot tell what state the feed is in, the workflow is not ready.

After the test passes, update the runbook. Include the SRT build, expected caller/listener mode, passphrase rule, failover scene, who owns field reboot, who owns server rollback, and how long the producer waits before cutting away. That handoff matters more than the release-note details during the actual stream.

• Field source to named StreamableRun SRT ingest.
• Cloud OBS scenes for main, backup, BRB, clips, and slate.
• Private destination for the upgrade test.
• Packet-loss and full-drop tests before public use.
• Producer runbook updated with rollback and fallback timing.

Other resources

Use these pages to verify the SRT release, protocol behavior, compatibility notes, and StreamableRun workflow pieces before changing a production ingest stack.