Repository navigation
Only offer the SRT directions the Strom instance supports #628
Description
Problem
The studio always offers every SRT direction for sources and outputs (Listener, Caller, and with the SRT relay work also Via relay), whether or not that direction can work on the Strom the production runs on.
For example, an operator can pick Listener on a Strom in Kubernetes, where a port bound inside the pod cannot be reached from outside. They get an address nobody can dial, and nothing says why.
The studio should offer only what works.
Where the knowledge lives: Strom
Whether a direction works depends on how Strom is deployed, so Strom is the one that knows. Open Live should ask it rather than keep its own configuration. This is the same principle as the SRT relay: Strom knows where the relay is and its public address, and Open Live reads them from Strom.
Strom side: Eyevinn/strom#1257. It covers:
STROM_INBOUND_REACHABLE, defaulttrue: can a port Strom binds locally be reached from outside. It is set tofalsein Kubernetes and Docker NAT setups.STROM_PORTS: when set, listeners are meant to use only those ports.STROM_SRT_RELAY: an SRT relay is available.- An endpoint that reports the result, e.g.
srt: { listener, caller, relay }plus the ports.
The port broker / port reservation flow is legacy and planned for removal, so it is not used as the signal.
Proposal (Open Live)
- Read Strom's capabilities in the same way as the relay status: cached, refreshed in the background, never blocking a request. Expose the effective SRT directions in
server-info. - Studio: offer only the directions Strom supports. Show Listener only when
srt.listeneris true, and, when Strom reports a port list, offer a port from that list. Show Via relay only whensrt.relayis true. Caller is always available. - Backend: reject creating, or patching to, a direction Strom positively reports as unsupported, with a clear 4xx. When Strom's status is unknown or unreachable, accept and say so in the
connectreason. Then the API matches the UI. - Existing sources and outputs in an unsupported direction stay listed and still activate. Only new choices are restricted, and the edit dialog does not offer the unsupported direction.
- Older Strom without the endpoint: keep today's behaviour and offer everything.
Test cases
- Strom with
STROM_INBOUND_REACHABLE=falseand a relay: the studio offers Caller and Via relay, and creating a listener via the API is refused. - Strom with the defaults (or an older Strom): behaviour is unchanged.
- Strom with
STROM_PORTS: the listener port choice comes from those ports. - An existing listener source on a Strom that later reports
srt.listener: false: it is still listed and still activates.
Activity
[-]Only offer the SRT directions that work in this deployment (hide Listener without a port broker)[/-][+]Only offer the SRT directions the Strom instance supports[/+]docs(specs): add spec and ADR-014 for offering only the SRT direction…
birme commentedon Nov 11, 2026
daily-backlog-pr, 2026-11-11. Phase 1 (architect) classified this as cross-service (open-live backend + open-live-studio, with upstream Eyevinn/strom#1257) and needs-spec. The Phase 1 spec,
docs/specs/srt-direction-capabilities.md+ ADR-014, was written in #630. Phase 1.5 (team-lead) reviewed it, resolved all open questions, and merged it.Kept in Backlog, blocked on #629. Per the spec's sequencing decision (resolution 11), backend implementation starts only after #629 (SRT relay, a draft by @srperens, gated on strom#1258 and open-live-studio#259) is merged to main. It must not be stacked on the draft branch. The studio part follows open-live-studio#259. The Open Live side does not wait on strom#1257: until that ships, every Strom reads as
unsupportedand behaviour is unchanged. Once #629 merges, the next triage moves this to Ready.birme commentedon Nov 12, 2026
daily-backlog-pr Phase 1 (architect), 2026-11-12 ~17:20Z: still blocked, kept in Backlog. Classification: cross-service. None of the blockers changed state since the 2026-11-11T17:25Z triage. The #629 stack did get new commits today.
f3e1e58f(three resolver fixes pushed today). It is not merged to main.srt+relay://,GET /api/srt-relay) is open and ready for review, with no review yet.unsupported.What unblocks it: #629 merges to main, which first needs strom#1258 merged. Per resolution 11 of the #630 spec approval, backend work then starts from main, not stacked on the #629 branch.
Note for the implementer: the spec on main still has the earlier sequencing wording (§8 item 11, "or rebases onto it"; §2 "starts from #629's branch state") and still says
Status: Draft. The approved resolutions 11–14 are in the team-lead approval on #630. Fold them into the spec in the first implementation PR, together with flipping ADR-014 to Accepted.birme commentedon Nov 13, 2026
daily-backlog-pr Phase 1 (architect), 2026-11-13: still blocked, kept in Backlog. Classification: cross-service. Nothing has changed since the 2026-11-12 ~17:20Z triage: no new commits, reviews or state changes on any blocker. The last activity on any of them was 2026-11-12T15:56Z.
f3e1e58f, with no reviews. It is not merged to main.srt+relay://,GET /api/srt-relay) is open and ready for review at head1bad8450, still with no review.cb936612.unsupported.What unblocks it: #629 merges to main, which first needs strom#1258 reviewed and merged. That review is the current bottleneck. Per resolution 11 of the #630 spec approval, backend work then starts from main, not stacked on the #629 branch.
Note for the implementer (unchanged):
docs/specs/srt-direction-capabilities.mdon main still saysStatus: Draftand still has the earlier sequencing wording (§8 item 11, §2). Fold approved resolutions 11–14 from the #630 team-lead approval into the spec in the first implementation PR, and flip ADR-014 to Accepted in the same PR.feat(srt)!: read Strom's capabilities; named SRT relays; report SRT m…
docs(specs): note how Strom's capabilities API landed for #628
birme commentedon Nov 13, 2026
daily-backlog-pr Phase 1 (architect), 2026-11-13 ~12:20Z: kept in Backlog. Do not move it to Ready. Classification: cross-service. The blockers changed since 08:18Z, but none of them has merged.
f554d143, and its body now says "Also covers Only offer the SRT directions the Strom instance supports #628". Commit3251e31cadds the backend part of this issue:services/strom-capabilities.tspolls StromGET /api/capabilities, andserver-info.srt.modes/relaysreplacesrtRelay.fe6179d5, and it greys out Listener whenmodes.listeneris false and adds a relay picker. Its body says it has not been checked in a browser yet.1bad8450with no review. It looks superseded: feat(srt): SRT relay addresses with a sticky id (srt+relay://) #629 says Strom replacedGET /api/srt-relaywithGET /api/capabilities. feat(srt): SRT relay addresses with a sticky id (srt+relay://) #629 and fix(db): add findTrusted opt-out so literal operator selectors bypass the Mango guard #259 now depend on the Strom branchesfeat/capabilities(86ef6012) andfeat/srt-relay-v2(b55d485e), and neither branch has a PR yet.connect.warningand does not refuse them. There is nosrt-direction-unsupported422. Commitf554d143adds a dated amendment saying so to the spec and to ADR-014, which is still not marked Accepted. Resolutions 11–14 of the Spec: offer only the SRT directions Strom supports (#628) #630 approval asked for refusal and for one implementation PR after feat(srt): SRT relay addresses with a sticky id (srt+relay://) #629. The reviewer of feat(srt): SRT relay addresses with a sticky id (srt+relay://) #629 should confirm thatteam-leadsigns off on the amendment.What unblocks it: the Strom
feat/capabilitiesandfeat/srt-relay-v2branches get PRs and merge. Then #629 and #259 leave draft, are reviewed, and merge. Once they merge, close this issue; no separate implementation is needed.birme commentedon Nov 13, 2026
daily-backlog-pr Phase 1 (architect), 2026-11-13 ~15:30Z: kept in Backlog. Classification: cross-service. The Strom side is now unblocked, but the drafts that cover this issue are still drafts.
feat/capabilities,GET /api/capabilities) and #1262 (feat/srt-relay-v2) merged at about 15:13Z. #1258 and #1257 are closed. Release 0.8.2 (strom#1264) is open but not merged, so v0.8.1 is still the latest release.f4105d75and open-live-studio#259 is a draft atc3a1cbd9. CI is green on both and neither has a review. Both bodies still say the Strom branches "have no PR numbers yet", so they need updating.Status: Draftand ADR-014 is stillProposed.What unblocks it: #629 and #259 leave draft, are reviewed (with
team-leadsigning off on the spec amendment), and merge. Then close this issue; no separate implementation is needed.birme commentedon Nov 13, 2026
daily-backlog-pr Phase 1 (architect), 2026-11-13: moved to Ready. Classification: cross-service, plain path, no new spec needed.
docs/specs/srt-direction-capabilities.md+ ADR-014) was approved by team-lead and merged on 2026-11-11.GET /api/capabilities) and #1262 merged, and v0.8.2 was released at 2026-11-13T15:52Z.f4105d75) and open-live-studio#259 (c3a1cbd9). Both left draft at 15:24Z, CI is green and neither has a review yet. The previous triage said they were still drafts, which was wrong.For Phase 2/3: no new implementation. Review #629 first, then #259, and merge them together. Before merge, team-lead must sign off on the warn-instead-of-422 amendment in #629 (commit
f554d143), which departs from resolutions 11-14 of the #630 approval. The spec header should also be updated: Status Implemented, Strom dependency 0.8.2, and the stale strom#1258 draft references dropped. ADR-014 should be set to Accepted. Close this issue once both PRs have merged.docs(specs): mark the superseded #628 spec passages inline
feat(srt): SRT relay addresses with a sticky id (srt+relay://) (#629)
birme commentedon Nov 13, 2026
Done: backend #629 merged,
server-info.srtverified on openlivedev (state ok, modes listener/caller/rendezvous, one relay), then Eyevinn/open-live-studio#259 merged, per the team-lead merge order. Closed by daily-backlog-pr Phase 3.