Media, Communications and Telehealth

Relay - Multi-Tenant Communications and Collaboration Platform

A decentralized CPaaS/UCaaS platform with custom C/C++ TURN and SFU infrastructure, adaptive P2P/SFU routing, E2EE media, private edge deployment, SDKs, recording, composition, and collaboration.

ContextOPTIME-developed product
PeriodApproximately six-year product-development program
RelationshipOPTIME-developed product platform
Team footprintApproximately 20 engineers contributed across the broader product program.
WebRTCCPaaS and UCaaSDistributed mediaPrivate deploymentDeveloper platforms

The system

Relay began as a custom communications-platform-as-a-service foundation. OPTIME engineered the real-time communications stack itself-including custom TURN, SFU, signaling, WebRTC session behavior, client SDKs, APIs, and multi-tenant control services-rather than treating media delivery as an external black box.

The platform later expanded toward unified communications and collaboration. Messaging, contacts, scheduling, presence, organization and user management, recording, composition, live-stream output, and application integrations operate around the same communications foundation.

Its architecture separates centralized tenant, billing, dashboard, and orchestration functions from a distributed media plane. TURN servers, SFUs, recorders, composers, and other media nodes can run regionally, close to users, or inside customer-controlled infrastructure while remaining managed through central services.

Engineering relationship

OPTIME conceived Relay and developed the platform from scratch over an approximately six-year product program. Approximately 20 engineers contributed across the broader program; that figure describes cumulative participation, not a claim that 20 engineers worked simultaneously for the entire duration.

The work spans C/C++ media infrastructure, Rust and Go systems/backend components, TypeScript applications and SDKs, microservices, distributed deployment, security boundaries, product workflows, administration, and developer integration. RelayIQ is the AI and communications-intelligence layer built on this same product family.

Engineering constraints

  • Choose direct peer media or server-routed media according to room requirements without forcing every call through centralized infrastructure.
  • Maintain multi-tenant organization, user, billing, and service coordination separately from customer media processing.
  • Place media nodes near users or in customer-controlled environments while retaining manageable infrastructure registration and health.
  • Protect communications content end to end while authenticating distributed infrastructure nodes to central services.
  • Record participant media as separate tracks and compose requested layouts as a distinct downstream operation.
  • Provide client and server integration surfaces across web, mobile, native, and backend environments.
  • Evolve from CPaaS foundations toward UCaaS collaboration without overstating the platform’s current pilot maturity.

What OPTIME engineered

  • A custom TURN server and custom SFU implemented in C/C++ for connectivity and performance-sensitive media routing.
  • Custom signaling and WebRTC session control, including topology selection between P2P and SFU paths.
  • A centralized multi-tenant control plane for organizations, users, billing, dashboard functions, orchestration, and infrastructure management.
  • A distributed media plane containing TURN, SFU, recording, composition, and related media-processing nodes.
  • Regional, enterprise-owned, and smaller private media-node deployment patterns managed from central services.
  • End-to-end encrypted communications content and mTLS authentication between distributed nodes and central infrastructure.
  • Separate participant-track recording plus layout-driven composition for recordings and live output.
  • External live-stream destinations for composed output, including YouTube, Facebook, and Instagram integrations.
  • Messaging, contacts, scheduling, presence, organization management, user management, and collaboration workflows.
  • TypeScript, iOS, Android, and native C++ client SDKs plus a REST API for server-side integration.
  • Microservice-based platform components implemented across C, C++, Rust, TypeScript, and Go.

Architecture

  1. Applications and SDKs

    TypeScript, iOS, Android, and native C++ integrations connect users, devices, and customer applications to Relay.

  2. Central control plane

    Organizations, users, billing, dashboard functions, orchestration, and infrastructure registration remain centrally coordinated.

  3. Session requirements

    Participant count, recording needs, and server-side media-processing requirements determine the appropriate room topology.

  4. P2P or SFU media path

    Suitable rooms use direct peer media; rooms requiring centralized routing or processing use the custom C/C++ SFU.

  5. Distributed connectivity and media nodes

    Custom TURN, SFU, recorder, composer, and processing nodes can run regionally or in customer-controlled infrastructure.

  6. Separate-track recording

    The SFU supplies individual participant media tracks to the recorder for archival and downstream processing.

  7. Layout-based composition

    Selected tracks enter the composer, which produces the requested multi-participant layout for recording or live output.

  8. External live-stream integrations

    Composed output can be delivered to YouTube, Facebook, or Instagram without implying a commercial partnership.

  9. Security boundary

    E2EE protects communications content, while mTLS authenticates distributed infrastructure nodes to central services.

  10. Collaboration and product services

    Messaging, contacts, scheduling, presence, organization/user management, APIs, and administration complete the UCaaS layer.

Key engineering decisions

Select P2P or SFU according to room requirements

Rooms can use direct peer-to-peer media when centralized processing is unnecessary and use SFU routing when participant count, recording, or other requirements need a server-side path. This avoids unnecessary relay traffic and infrastructure consumption in suitable scenarios.

Separate control plane from media plane

Central services coordinate tenants, billing, users, and infrastructure without requiring access to unencrypted customer media. Media processing can remain geographically close to users or inside customer-controlled infrastructure.

Keep recording and composition independent

Participant tracks are recorded separately. A composer later combines selected tracks into a requested layout, supporting different archival and live-output needs without collapsing every workflow into the SFU.

Own the media-routing infrastructure

Custom C/C++ TURN and SFU components give OPTIME responsibility for connectivity, routing, recording-capable sessions, deployment placement, and performance-sensitive behavior down to the media layer.

Product evolution

Relay evolved at a high level from a custom CPaaS foundation through custom TURN, SFU, and signaling; adaptive P2P/SFU topology; SDKs and APIs; recording and composition; messaging, contacts, scheduling, and presence; organization and user management; decentralized private media deployment; and broader UCaaS capabilities.

RelayIQ extends the same platform family with real-time communications intelligence. Relay demonstrates the communications system underneath it; RelayIQ demonstrates the private AI processing architecture operating alongside that system.

Current capability

Relay is currently in pilot. It provides a customer-deployable communications foundation spanning custom media infrastructure, flexible room topology, multi-tenancy, collaboration, recording, composition, SDKs/APIs, and distributed media deployment without implying broad production adoption.

Verified result

OPTIME delivered an integrated CPaaS-to-UCaaS platform in which central administration can coordinate organizations and infrastructure while communications media remains protected and can be processed close to users or inside customer-controlled environments.

Technology & Engineering Role

C / C++
Custom TURN, custom SFU, and performance-sensitive media components.
Rust
Systems and backend components in the distributed platform.
TypeScript
Platform services, web/client integration, and SDKs.
Go
Backend and microservice infrastructure.
WebRTC
Real-time audio and video transport.
P2P
Direct media topology for rooms that do not need centralized routing or processing.
Custom SFU
Multi-party routing, recording-capable sessions, and centralized media paths.
Custom TURN
Connectivity through restrictive NAT and firewall environments.
Custom signaling
Session control, room state, and media-topology management.
E2EE
Protection of communications content across supported media paths.
mTLS
Machine authentication between distributed infrastructure nodes and central services.
REST API
Server-side platform and customer-system integration.
iOS / Android / TypeScript / C++ SDKs
Client-side integration across mobile, web, and native applications.
Recorder
Preservation of separate participant media tracks.
Composer
Requested multi-participant layouts for recordings and live-stream output.

Related engineering

CONTACT US

Tell us about your project, and let’s create something together

Austin, Texas

Distributed engineering teams across North America, Europe, the Caucasus, and Latin America.

[email protected]

We use the information you submit to respond to your inquiry and process it through the service providers required to operate this form.