Robotweax SRT 0.3.0 is released. Compared with 0.2.9, it gives integrators a choice of crypto provider on supported platforms, more information and policy control when accepting peers, better visibility into Connection Groups, and fixes for transport behavior under particular timing and recovery conditions.
Robotweax SRT is an independent implementation of Secure Reliable Transport. The 0.3.0 number identifies the Robotweax project, not a new SRT protocol version: its compatible public SRT API and srt_getversion() remain at 1.5.7. The shared-library ABI, however, advances from 0.2 to 0.3. Applications and dependencies using the library must be rebuilt.
A second crypto provider, with OpenSSL still the default
On Linux and macOS, version 0.3.0 can use Mbed TLS 3.6.7+ in supported 3.6.x configurations as an alternative to OpenSSL. The release covers static and shared library consumers and includes cross-provider interoperability checks for AES-CTR and AES-GCM. OpenSSL remains the default provider; selecting Mbed TLS does not change the normal compatible wire profile by itself.
Windows SDK installers are available separately for OpenSSL and the experimental Microsoft BCrypt backend. The provider choice is explicit, not a claim that every backend or build combination has identical qualification.
More context when deciding whether to admit a peer
Applications can now read bounded peer-handshake metadata during admission and after a connection has been established. This helps a listener make decisions using information that was previously harder to inspect. The metadata is self-reported by the peer: an implementation label or other reported value is not authenticated identity and must not be treated as proof of who is connecting.
For path labels and Standby RTT, the new extension policies are OFF, REQUIRED, and—on listeners only—IF_OFFERED. That last option lets one listener serve ordinary peers as well as peers that offer the extension. An application can therefore select its admission policy explicitly rather than assuming every peer supports the same optional features. These policies do not make path labels an authentication mechanism or Standby RTT a measure of DATA-path health.
Connection Groups: fewer false rejections, clearer counters
The release corrects false group rejections across bonded listeners. It also allows a new attempt to recover when an earlier connection attempt left an unconfirmed association with a peer group. These are targeted connection-establishment fixes, not a promise that every group topology behaves identically to the reference implementation.
Group statistics now aggregate retransmitted packets and bytes across members. Contributions remain accounted for when a member departs and its final send work drains, making the group-level counters more useful when paths change over time.
Reliability fixes in File, Control and runtime paths
File/Stream and Control/Message connections now preserve negotiated retransmission marking. With a positive SRTO_LOSSMAXTTL setting, adaptive reorder handling can learn from packets arriving out of order and defer loss reports as intended. File mode also retains its window/RTT startup fallback before receiver-rate feedback is available, avoiding an unnecessarily slow start when acknowledgements are sparse.
Other hardening addresses cleanup initiated from callbacks, rejects acknowledgements for DATA that has not yet been submitted, bounds peer credit and Sensor gap-expiry work, and fixes listener setup races and duplicate admission handling. Test tooling also handles descendants of remote interoperability processes more safely and improves asynchronous readiness and installed-documentation checks.
Experimental features remain opt-in
Two additions are included for evaluation, disabled by default:
- ACP1 runtime control authentication uses directional keys and bounded replay tracking for supported ordinary sockets, Broadcast/Backup groups, Rendezvous and Group Rendezvous. It requires a build gate and explicit opt-in at both endpoints. Independent cryptographic review remains outstanding; ACP1 is not a supported security profile or an ordinary Haivision-compatible mode.
- Peer implementation identity exposes optional, bounded, self-reported labels. It does not change compatibility-version or capability negotiation, and a label is not an authenticated identity.
Upgrading and evaluating 0.3.0
The ABI transition to 0.3 requires applications and dependencies to be rebuilt, including consumers of internal C++ headers. The compatible SRT API remains at 1.5.7, and OpenSSL/AES-CTR remains the default compatible profile. The release provides separate Windows SDK installers and checksums.
As with earlier versions, assess the library against your own peers, network conditions and operating requirements. Comparative CPU, memory and throughput regression thresholds were not qualified for this release; the changes above should not be read as a general performance claim. ACP1 also still requires independent review before it could be relied on as a security profile.
Download Robotweax SRT 0.3.0 · Read the release notes · Review the qualification record