SRTLA Changed in September 2026: What srtla_send 4.x and Receiver Fixes Mean When You Choose an IRL Server

What is the best IRL streaming server?

Our answer, and we sell it, so weigh it accordingly: for most serious streamers it is StreamableRun, because it combines Cloud Hosted OBS, SRT/SRTLA and RTMP ingest, stream drop protection, fallback scenes, multiple ingests, remote production, and destination management in one cloud workflow.

That answer fits a specific person: someone who wants the show to live in the cloud, with moderators and scenes and fallbacks that do not depend on a phone staying connected. It is not true for everyone. If all you want is a bonded pipe into an OBS box you already run, a self-hosted SRTLA receiver is a legitimate answer, and plenty of good IRL setups work that way.

This post is about how to judge that second path, because September 2026 gave us concrete reasons to look closer. If you run your own gear, you have re-testing to do. If you rent a server, you have questions to ask.

What changed in srtla_send 4.0 and 4.1

srtla_send is the sender half of SRTLA: it spreads your encoder's SRT stream over the links you list. Version 4.0.0 landed on 2026-09-10. The release notes list mode selection, a new RTT-threshold scheduling mode, network simulation and integration tests, congestion control and link management changes, a stall gate, and scheduler follow-ups that hold late links out and re-admit them on evidence. The same day, 4.0.1 followed as what its own notes call a version number bump.

Version 4.1.0 arrived on 2026-09-24 and is the one that can bite you. The upgrade notes say --config files now take effect, and srtla_send refuses to start if the file has an unknown key or does not parse. It accepts six keys: mode, no_quality, no_stall_deselect, stall_min_in_flight, stall_ack_stale_ms and conn_timeout_ms.

Two more details from those notes matter. A key in the file applies only when the same option is not set on the command line. And the file is read once at startup; SIGHUP does not reload it, and the notes point to the JSON-RPC control socket for runtime changes. The release also retries a timed-out link every second before slowing down.

What to re-test on a self-built sender

None of this means 4.x is bad. It means your rig changed underneath you. The README still calls the tool experimental, so treat an upgrade like firmware, not an app update. This order is my judgment, not something the maintainers prescribe.

• Check the version first. srtla_send -v prints it. Know whether you are on 3.x, 4.0.x or 4.1.x.
• Audit your config file against the six accepted keys. A copied snippet or half-remembered option will now stop startup instead of being ignored. On a backpack that boots into a stream, that means no stream at all.
• Test the real boot path, not a terminal. Reboot the encoder the way you will on the street and confirm srtla_send comes up on its own. Keep the previous .deb on the device so you can roll back without Wi-Fi.
• Find out which setting wins. Command-line flags beat the file, so a leftover flag in a startup script can override the value you just edited.
• Do not expect SIGHUP to reload settings. The README says SIGHUP reloads the uplink IP list on Unix, but the 4.1.0 notes say the config file is not re-read.
• Choose a scheduling mode on purpose. The README on the main branch describes enhanced (the default) and classic, which matches the original C sender. The 4.0.0 notes also mention an RTT-threshold mode, so check what your installed build offers before writing it into a config.

Stall gate and link timeouts: only tune with a reason

The README says the stalled-link deselect is on by default. It sidelines a link holding a big in-flight backlog with no fresh delivery proof, as long as a healthier link can carry the traffic. Documented defaults are 32 packets in flight and a 3000 ms staleness window, aimed at satellite links during obstructions or handovers.

The per-link timeout default is documented as 5000 ms. After a link that registered before times out, the first four reconnect attempts go one second apart, which the README ties to SRT's five second peer-idle timeout. A short tether blip should re-register before the session ends.

My advice, which is judgment: leave stall_min_in_flight, stall_ack_stale_ms and conn_timeout_ms alone until you have a failure you can describe. The cheap drill: start a private stream, pull one uplink, put it back, and watch whether the link returns and how long bitrate takes to recover. Repeat per mode you might use and write the results down.

The receiver side: a full buffer used to end the stream

Here is the change I would care about most as a server buyer. In the open-source irlserver/srtla receiver, a commit dated 2026-09-29 is titled to drop the packet, not the group, when the SRT socket send buffer is full.

The commit message explains the old behavior. forward_to_srt_server() tore the whole group down on any send that did not write the full packet, including the case where the kernel send buffer was momentarily full. That happens when a sender flushes a backlog faster than the path to the SRT server drains, which the message says is typically right after an outage. One full buffer turned into a full stream reconnect.

After the change, transient errors (EAGAIN, EWOULDBLOCK, ENOBUFS, EINTR) drop that single packet and keep the group; SRT sees the gap and retransmits. Other errors, such as the SRT server going away, still end the group. The commit also adds a counter, srtla_forward_dropped_total, and narrows srtla_forward_errors_total to failures that end the group.

This is an IRL story because the moment your links come back after a dead zone is exactly when the sender dumps its backlog. One hedge: this is a commit in one repository. A changelog cannot tell you which receiver code any hosted service runs.

Metrics endpoints and who can see them

On 2026-09-09 the same receiver repo added a --metrics_bind option. The commit message says the Prometheus exporter used to bind to all addresses with no way to narrow it, which it calls a poor default for an endpoint with no authentication. The bind address now defaults to 127.0.0.1, and containers need --metrics_bind :: to be reachable from outside.

If you self-host, that is a small but real audit item: is your metrics port reachable from the internet, and did a container upgrade quietly change what is exposed?

The SRT layer under the receiver

SRTLA receivers hand the merged stream to an SRT listener, so the SRT build matters too. The irlserver/srt repository keeps a belabox branch with SRTLA patches. Its history shows periodic NAK reports under SRTLA patches on 2026-06-29, and a 2026-07-05 fix for a periodic loss report that walked every sequence number under a lock and, per the commit, stalled the receiver on large post-outage loss lists.

The branch also took the KMREQ vulnerability fix on 2026-07-20, and Haivision's v1.5.7 release on 2026-08-28 describes fully remediating KMREQ processing. We cover the 1.5.7 upgrade work in a separate checklist, so I will not repeat it. The takeaway: post-outage loss recovery and handshake security both got attention this summer, and neither is visible from outside.

Questions to ask any SRTLA server operator

Whether you are comparing hosted services, a friend's VPS, or a relay you built over a weekend, these questions turn the September changes into something checkable. A vague answer is also information.

• Which receiver code do you run, and does it drop a packet instead of the whole group when the SRT send buffer is full? A fork that predates 2026-09-29 may still reconnect on a burst.
• Which SRT version sits behind it, and has it taken the KMREQ fixes and 1.5.7 hardening? Ask for a version or a date, not a reassurance.
• Which sender versions and settings is the setup guide written for? Operators should say what they tested against.
• What do you expose publicly? Metrics, status pages and debug ports should not be open to the internet by default.
• What SRT latency should I set for my app? An operator who cannot name a number has not looked at it.
• What does the stream do when the feed dies? Receiver fixes reduce reconnects, but they do not decide what viewers see during a gap. That is a production question, and it is where a plain relay stops.

Do I need SRTLA or Cloud OBS?

They solve different problems, so the honest answer is often both. SRTLA is transport: it bonds links and gets the video to a receiver in one piece. Cloud OBS is where the show lives afterward: scenes, overlays, moderators, and the output to your platforms. Pick based on which problem is actually hurting you.

• Self-host a receiver, on a VPS or at home, if you want control, have a stable machine, and are fine tracking the upstream repositories yourself. You own patching, monitoring and the 3 a.m. restart, and the September changes land hardest on you.
• Use SRTLA into a Cloud OBS workflow if you want scenes, fallbacks and moderators to keep working while the phone is in a tunnel, and you would rather not run the receiver at all.
• Use plain RTMP only when the source is stable and you accept that a dropped link is simply a dropped stream. For mobile, that tradeoff is rarely worth it.

A practical path: Moblin or IRL Pro to StreamableRun to your platforms

If you land on the cloud path, here is the order I would set it up in. Do it at home first, on a private or test destination.

1. In StreamableRun, open the ingest source picker and choose the tile that matches your app: Moblin, IRL Pro, or Other Cloud Servers for BELABOX-style senders. The SRTLA host is in.streamable.run on port 5000, and SRT uses port 9000. For Moblin there are deep links, so the app can be configured from the dashboard instead of by hand.

2. Keep the recommended latency for your ingest type unless you have a reason. The product defaults are 4200 ms for Moblin and 800 ms for BELABOX-style senders.

3. Set fallback behavior before the first walk. Stream drop protection includes an Ingest Offline fallback scene and a low-bitrate setting that can switch to it, so a bad moment shows viewers a scene you chose rather than a frozen frame.

4. Add your destinations: Twitch, Kick, YouTube or a custom RTMP target. Your app only has to reach StreamableRun, which handles the outputs.

5. Run a failure drill: mobile data only, walk out of Wi-Fi range, disable a link. Watch what viewers see and how long recovery takes. On a DIY sender, repeat it after every srtla_send upgrade.

Where StreamableRun fits

StreamableRun is built for the cloud path above. It accepts SRT, SRTLA and RTMP ingest, runs the show in Cloud Hosted OBS, and sends it on to your destinations. A moderator in a role like Scene Switcher or Tools Moderator can switch scenes while the streamer keeps walking.

This post does not say which receiver implementation or SRT build sits behind our ingest, and the questions above apply to us like anyone else. If you build your own sender, keep doing that: StreamableRun is an ingest target for a BELABOX-style, Moblin or IRL Pro feed, and your upgrade homework stays the same.