Bridge IS-08 Channel Mapping through the Connection API Bridge - #175
Merged
Conversation
Document Connection-style HTTP bridge targets for cm-ctrl controls, including DELETE on the allow-list and Forced/Auto client remap.
Make the proxied Device API a property of each target, so cm-ctrl controls produce their own routes and clusters. Targets are keyed by Device, API and version: IS-05 and IS-08 both have a v1.0, and nmos-cpp advertises them at the same host and port, so keying without the API would merge them and drop one as an inconsistent candidate. Allow DELETE, which IS-08 uses to cancel a pending activation, and log it like other mutating methods. Which methods a resource supports remains the Device's answer to give.
The fall-through only matched /x-nmos-bridge/v1.0/, so the bridge API root and unknown bridge versions matched no route at all. Where APP_URL is set they reached the app catch-all on /, serving the SPA for paths inside the bridge's own namespace; otherwise they got a body-less Envoy 404 rather than an NMOS error. Match the namespace with path_separated_prefix, and list the bridge API and its version like the /x-nmos listing. Devices are still not listed: that would be a discovery surface the Registry already provides.
A Device ID from the Registry was previously opaque: every path short of a
complete target answered "Unknown bridge target", so there was no way to
tell a mistyped ID from a control the bridge never mapped, short of reading
the generated Envoy configuration.
List the mapped APIs at /devices/{device_id} and their versions one level
down, and say why the Device collection itself is not listed. These are
direct responses generated from the same targets, so they cannot disagree
with the routes, and they add no cluster, health check or per-route Lua.
Connection already remaps Forced/Auto through the bridge; Channel Mapping
still used Device control hrefs only, so Forced Bridge could not reach
IS-08 when the browser could not reach the Device. Reuse the same attempt
order and per-Device access-path cache, with bridge URLs under
…/channelmapping/{version}.
lo-simon
approved these changes
Aug 19, 2026
lo-simon
left a comment
lo-simon
left a comment
Collaborator
There was a problem hiding this comment.
LGTM
Just one small comment. In the Architecture section of the README, /x-nmos-bridge/... can map to Device Connection APIs and Channel Mapping APIs.
Envoy
|
+--> /x-nmos-bridge/... --> Device Connection APIs and Channel Mapping APIs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cm-ctrl(IS-08 Channel Mapping) controls through Envoy alongside existingsr-ctrl(IS-05 Connection) targets, keyed by Device + API + version, withDELETEon the mutating-method allow-list./x-nmos-bridgenamespace answer consistently (root / version listings and a namespace fall-through), and list the APIs and versions the bridge proxies for a given Device ID.ConnectionBridge/docs/channelmapping-proxy-plan.md(Forced/Auto client remap still follow-up).Follow-up: rename
ConnectionBridge(directory, docs, and “Connection API Bridge” naming) to something likenmos-bridge, now that the front door is not Connection-only. Kept out of this PR to avoid churn on the behavioural change.Test plan
GET/POST/PATCH/DELETEthrough/x-nmos-bridge/v1.0/devices/{id}/channelmapping/v1.0/...against an nmos-cpp (or other) node withcm-ctrlGET /x-nmos-bridge,/x-nmos-bridge/v1.0,/devices/{id},/devices/{id}/{api}return the expected listings