The Tieline system makes multiple individual routers behave like one larger router. An operator can request that a source on Router A reaches a destination on Router B without needing to know how the routers are connected or which intermediate routes are required.
Behind that request, the signal cannot jump directly between the routing matrices. The physical connection normally runs from a destination port on the first router to a source port on the next router. Completing the end-to-end route therefore requires a route on the first router, an available connection between the routers, and another route on the next router.
Buttons hides this complexity from the operator. It models the inter-router connections as Relations, limits their permitted use with Routing Rules, finds an allowed path, and reserves the shared connections used by that path.
Tielines are shared routing resources. A cross-router route is retained as a Route Request so Buttons can continue to account for the Relations it occupies. Projects group those retained routes so they can be found and released when a production is finished.
A routing domain is the set of ports that can route locally. In most installations, this is one router.
A Relation tells Buttons about the physical connection from a destination port on one router to a source port on another.
A Routing Rule identifies the edge sources, edge destinations, and Relations that may form a Tieline path.
A Route Request retains the selected cross-router route and its path through the Relations.
A Project groups retained routes for a production, event, room booking, or other period of use.
For example, a route from Replay A on Router A to PCR 2 Multiview on Router B may resolve as:
Replay A source→ Router A Tieline Out destination→ Relation→ Router B Tieline In source→ PCR 2 Multiview destination
The operator selects only Replay A → PCR 2 Multiview. Buttons uses the Relation to understand that the two routers are connected, then plans and executes the route required on each router.
The physical transit connection between each pair of routers.
The destination port that feeds each physical connection.
The source port that receives from each physical connection.
The edge sources and destinations allowed to use those connections.
How routes should be grouped and released through Projects.
Confirm the physical signal direction before creating Relations. Reversing the endpoints models a different path.
Warning
Taking or releasing a Tieline route can change several router destinations. Become familiar with the path and release behavior before deploying it in production.
A Relation represents the physical connection from a destination port on one router to a source port on another. It tells Buttons where a signal can cross between routers; it does not execute a route when it is created.
Open Routing → Relations.
Select Create Relation.
Enter a Relation Label that identifies both sides of the connection.
On the Destinations side, select the port that feeds the physical transit connection.
On the Sources side, select the port that receives the signal from that connection.
Confirm at least one essence mapping between the staged destination and source: Buttons proposes a pattern automatically when the two sides are compatible, and Create stays disabled until at least one mapping exists. Review the proposed mapping (or build one by hand) before continuing.
Leave Use for tielines on unless this Relation should carry port metadata without being eligible for Tieline routing: see below.
Review the staged pair.
Select Create.
Select several matching destination/source pairs to create several Relations in one operation. Buttons adds a number to the label for each generated Relation. Turn on Create Multiple when the dialog should remain open for another batch.
Repeat this for every independent physical transit path. Parallel cables or channels should be separate Relations because each can be occupied independently.
Every Relation has its own Use for tielines setting, on by default. A Relation with it turned off is ignored by Tieline path selection and hidden from the Tieline graphs: useful for a Relation that exists to carry port/essence metadata for other purposes without being a candidate route Buttons should ever pick. The Relations list shows this as a Tielines column (Yes/No), and it can be changed later from the Relation's own edit dialog.
The Active Signal currently reported at the transit input.
The retained Route Request using the Relation, or Available when none is assigned.
A Capacity Overview of the configured Relations.
A Relation can carry the same upstream source to more than one downstream destination while that source remains on the transit path. A competing source needs another allowed Relation or must wait until the occupied path is released.
Disabling a Relation prevents it from being selected for a new path. It does not describe or repair the physical connection itself.
A Relation is not automatically available to every route. At least one Routing Rule must associate permitted edge ports with the Relations they may use.
Open Routing → Routing Rules.
Select Create Rule.
Enter a Label, such as Router A replay to Router B PCR.
Open the new rule.
Add the edge Source Ports allowed to originate routes.
Add the edge Destination Ports allowed to receive those routes.
Add the Relations that may carry them: only Relations with Use for tielines on are offered here.
Leave Enabled on.
Add a Description when the operational boundary is not clear from the label.
Save the rule.
A Relation can appear in several rules. Buttons considers a Relation allowed for a source-to-destination route only when an enabled rule contains that source, destination, and Relation.
Routing Rules provide two separate controls for their Relation endpoints:
Hide ports removes the endpoints from manual routing interfaces while keeping them available to Tieline planning.
Protect ports rejects direct route requests to those endpoints so they can only be changed as part of a Tieline path.
Use these controls when operators should work with the edge source and destination rather than the intermediate transit ports. Leave them off while initially inspecting the configuration.
When a route is staged, Buttons builds a routing graph from the configured routing domains (normally the routers) along with enabled Relations, enabled Routing Rules, retained Route Requests, and current reservations.
Buttons then:
Checks whether the source and destination can route locally on the same router or routing domain.
If they are not, finds an allowed path through the configured Relations.
Excludes Relations that are unavailable, disallowed by the applicable rule, occupied by a competing source, or temporarily reserved by another routing operation.
Reuses an occupied Relation when the retained path already carries the same source and the remaining path is valid.
Produces the intermediate physical route requests required for the selected path.
Retains the cross-router Route Request so later planning can account for the occupied Relations.
Buttons searches for an eligible short path through the graph. Do not rely on one particular parallel Relation being chosen unless the Routing Rules restrict the available choice accordingly.
Review the source, destination, and intermediate path shown for the staged route.
If no path is shown, review the Relation, Routing Rule, endpoint availability, and current Route Requests before taking the route.
Select a Project when one should own the retained route.
Select Take.
Review the routing report and the resulting route state.
A route that stays within one routing domain (normally one router) does not claim a Relation. A cross-router route creates or updates a retained Route Request and may occupy one or more Relations.
Projects give retained routes an operational owner and make it possible to release a production's routes together.
Tip
Assign Tieline routes to Projects so technical staff can find and release all routes held for a production in one place.
Create or identify the production's Project.
Stage the Tieline route in Routing → Execute.
Review Paths.
Select the Project before selecting Take.
When the production finishes, inspect the Project and release the routes it holds.
An administrator can turn on Require project for tielines to reject Tieline routes that do not have a Project. See Group and release routes with Projects for creation, assignment, release, expiry, and archival guidance.
Use Routing → Relations for a transit-resource view:
Available means no retained Route Request currently uses the Relation.
A Route Request tag identifies the retained route using it.
Active Signal shows the currently reported source at the Relation endpoint.
Use Routing → Projects for a production view. It shows which retained routes belong together and whether they still need release.
Use Paths in Routing → Execute for a proposed-route view. It shows how the currently staged route is expected to cross the configured Relations.
These views answer different questions. An active signal on a transit port does not by itself identify which Project owns the retained route; inspect the Route Request or Project for that context.
If technical staff need to clear every retained route using a specific Relation:
Open Routing → Relations.
Right-click the Relation.
Select Release Route Requests.
Confirm the release.
Review the routing report if any route could not be released.
This acts on all retained Route Requests using the selected Relation. Prefer releasing through a Project when the goal is to clean up one production, because a Relation may be shared by routes with different operational owners.
Confirm that the source and destination ports exist and are available.
Confirm each Relation's destination-to-source direction and Enabled state.
Confirm an enabled Routing Rule contains the edge source, edge destination, and required Relations.
Inspect Paths for the first missing or blocked segment.
Inspect Relations for retained Route Requests from competing sources.
Confirm a Project is selected when Require project for tielines is enabled.
Confirm the physical transit connection and all routing devices remain controllable.
A route can have no valid path even when both edge endpoints are healthy. The missing part may be topology, policy, occupancy, Project context, or the physical transit connection.
