Techex TxCore Integration

Techex TxCore Integration

Minimum hi Version: v2.7.5

Overview

The TxCore integration enumerates MWEdge Nodes and their configured Sources and outputs through the TxCore REST API. It makes those resources available to hi compressed-routing workflows and polls TxCore for additions, updates, and removals. TxCore and MWEdge remain responsible for SRT transport and stream configuration. TxCore was formerly named MWCore, and Techex now calls MWEdges TXEdges. The TxCore API keeps the MWEdge name. hi adds each MWEdge as a Node of the TxCore Node type, named after the MWEdge.

Network Requirements

• Connection Model: hi initiates REST requests to the active TxCore base URL.

• Multicast / Unicast: Control traffic is unicast. Media transport remains managed by TxCore and MWEdge.

• VLAN / IGMP: Follow the TxCore and media-network design.

• Bandwidth: Control-plane traffic only.

• IP Version: Determined by the configured TxCore URLs and deployment.

• Firewall: Permit outbound HTTP(S) from hi to every configured primary or redundant TxCore URL.

Standards Conformance

Operator Workflow

• UI Surface in hi: Routing Matrix and Inventory

• Resources Controlled: TxCore Core Integration Nodes, MWEdge Nodes, configured Sources, configured outputs, and compressed streams

• Routing Semantics: hi updates the settings of an existing Source to apply a requested compressed route.

• State Updates: hi polls the MWEdge collection and compares it with the current inventory in hi.

• Instances: Create one TxCore Core Integration Node for each TxCore instance. Several Nodes can exist in one system.

Connection Details

Required Configuration

Device-Side Setup

Follow Techex TxCore Integration Configuration for the device-side and hi-side configuration steps.

Supported Features

Known Limitations

• State changes are detected through REST polling rather than real-time event delivery. hi requests the MWEdge list continuously, with a fixed pause of 100 ms between requests. The interval cannot be configured.

• Validate permissions and endpoint availability for every configured TxCore address.

• hi moves to the next redundant host, in the order entered, only when the connection to the active URL fails at the network level. TLS, HTTP, and timeout errors do not cause failover. After two failures, hi marks the Node as disconnected and tries to sign in to the current URL every second.

• hi signs in again about every 9 minutes.

• hi validates the TLS certificate of an HTTPS URL. The hi server must trust the certificate of each TxCore URL.

• SRT connection parameters and media behavior remain configured in TxCore and MWEdge.

• Each MWEdge keeps its own configuration and continues to operate when its TxCore is unreachable. Existing streams continue, but hi applies routes only through a reachable TxCore URL.

What's Not Supported

• Encoder or decoder codec-profile authoring that is not represented by the supported Source and output models.

• TxCore cloud-account, product-license, or platform administration.

• Creating or deleting Sources, and creating, changing, or deleting outputs.

• Creating, changing, or deleting TxCore streams and channels. The TxCore REST API provides these operations, and hi does not use them.

• TxCore telemetry, such as bit rates, missing packets, and ETR 290 data. TxCore sends telemetry over a separate connection with client-certificate authentication, on port 7834 by default.

• SAML, Microsoft Entra ID, or two-factor sign-in. TxCore offers these sign-in options. hi signs in with a login name and password and cannot complete a second factor.

Trademarks