Replace the engine, preserve the product
The new communications engine was integrated beneath established customer and interpreter workflows rather than forcing a rewrite of the complete healthcare language-access platform.
Media, Communications and Telehealth
LinguaCare - Healthcare Language-Access Communications Platform
A production healthcare communications platform combining a custom mediasoup SFU, WebRTC, SIP/PSTN/Webex interoperability, interpreter routing, and approximately 6 million communication minutes per month.
Healthcare communicationsWebRTC and SFUSIP and PSTNMedia gatewaysInterpreter workflows
The system
LinguaCare is an established healthcare language-access platform connecting patients, clinicians, and human interpreters through on-demand, scheduled, and joined-call workflows. The surrounding product already managed healthcare and interpreter operations; it needed a new communications engine capable of modern WebRTC media while continuing to interoperate with telephony and external conferencing environments.
OPTIME engineered a customer-specific real-time engine around a mediasoup-based SFU, a custom video client, application and workflow services, SIP infrastructure, PSTN connectivity, and an RTP-to-WebRTC gateway. Mediasoup supplied an important media-server foundation, but the delivered system also required routing, gateway, client, workflow, and platform integration work.
The platform has operated in production for years and processes approximately 6 million communication minutes per month. The public case describes communications engineering and operational scale without making clinical-outcome or healthcare-compliance claims.
Engineering relationship
Across an approximately four-year program, approximately six engineers replaced the existing video engine while preserving the customer’s surrounding application, established customer and interpreter workflows, and external communications interoperability.
OPTIME’s responsibility crossed C/C++ media and telecom components, TypeScript/Node.js application services, the custom client, mediasoup SFU behavior, Kamailio integration, custom SIP functions, the PJPROJECT/PJSIP gateway, call routing and forwarding, and production integration.
Engineering constraints
- Replace the real-time communications engine without replacing the surrounding healthcare language-access product.
- Support browser/application WebRTC alongside SIP, PSTN, and Webex communications environments.
- Bridge RTP media into the WebRTC SFU while keeping signaling and media responsibilities explicit.
- Route interpreters according to language, availability, scheduled work, and on-demand requests.
- Support three-party patient, clinician, and interpreter sessions plus interpreter entry into an existing call.
- Preserve call forwarding and established operational workflows at sustained production traffic.
- Generalize private healthcare data, customer integration, SIP routing, and platform topology in public material.
What OPTIME engineered
- A new customer-specific video and communications engine built on a custom mediasoup-based SFU.
- A custom video client and WebRTC integration for the existing healthcare application.
- C/C++ media, SIP, RTP, gateway, and performance-sensitive communications components.
- TypeScript and Node.js application integration, backend services, and interpreter workflow coordination.
- Kamailio-based SIP routing infrastructure plus customer-specific SIP functionality implemented in C++.
- A custom PJPROJECT/PJSIP-based RTP-to-WebRTC gateway implemented in C/C++.
- PSTN participation through the SIP and RTP gateway boundary.
- Webex interoperability using SIP for signaling and RTP through the custom gateway for media.
- Language-based interpreter selection, on-demand requests, scheduled interpreters, and call forwarding.
- Three-party patient, clinician, and interpreter sessions plus interpreter joining of existing calls.
- Production integration that preserved the surrounding product and established operational workflows.
Architecture
Patient, clinician, and interpreter applications
The custom client and surrounding healthcare application initiate language-access and multi-party communications workflows.
Interpreter workflow layer
Language selection, routing, on-demand requests, scheduled assignments, call forwarding, and join-existing-call behavior coordinate human interpreters.
WebRTC media path
Application participants exchange real-time media through the custom mediasoup-based SFU.
PSTN signaling boundary
Kamailio and customer-specific C++ SIP functionality connect telephony participants into the platform.
RTP-to-WebRTC gateway
A custom C/C++ gateway built on PJPROJECT/PJSIP translates external RTP media into the SFU’s WebRTC environment.
Webex signaling
Webex interoperability uses SIP at the signaling boundary without exposing private routing rules.
Webex media
RTP from the conferencing environment passes through the custom RTP/WebRTC gateway before reaching the SFU.
Three-party healthcare session
Patient, clinician, and interpreter media converge in the language-access workflow while the surrounding product retains its established operations.
Key engineering decisions
Use mediasoup as a foundation, not a finished solution
The SFU foundation was extended with a custom client, routing, workflow, gateway, SIP, PSTN, and Webex integration required by the customer’s operating model.
Separate signaling from media interoperability
Webex signaling uses SIP, while Webex RTP media passes through the custom PJPROJECT/PJSIP-based RTP-to-WebRTC gateway before entering the mediasoup SFU.
Keep the human interpreter central
Language selection, scheduling, routing, and call forwarding connect patients and clinicians with human interpreters; the case does not claim automated translation or interpreter replacement.
Production capability and scale
The new engine moved the platform onto a custom WebRTC/SFU foundation while preserving the surrounding healthcare product and connecting it to traditional telephony and Webex conferencing through explicit SIP, RTP, and gateway boundaries.
Interpreter workflows remained part of the product architecture: an interpreter can be selected by language, requested on demand, scheduled in advance, forwarded into the correct call path, or joined to an existing session.
Verified capability
OPTIME replaced the real-time communications engine inside an established healthcare language-access platform while preserving the surrounding product and operational workflows. The system combines WebRTC, SIP, PSTN, and Webex interoperability with language-based interpreter routing and multi-party healthcare communications.
Verified result
The resulting platform has operated in production for years and processes approximately 6 million communication minutes per month.
Verified metrics
Approximately 6 million minutes
Approximate real-time communication minutes processed by the production platform each month.
Technology & Engineering Role
- C / C++
- SIP, RTP, gateway, client, and performance-sensitive communications components.
- TypeScript / Node.js
- Application integration, backend services, and interpreter workflow coordination.
- mediasoup
- Foundation for the custom SFU and WebRTC media engine.
- WebRTC
- Real-time browser and application communications.
- Kamailio
- SIP routing and signaling infrastructure.
- Custom SIP implementation
- Customer-specific SIP behavior implemented by OPTIME in C++.
- PJPROJECT / PJSIP
- Foundation for the custom RTP-to-WebRTC gateway.
- RTP
- Media transport from telephony and external conferencing systems.
- SIP
- Call signaling and interoperability across external communications boundaries.
- PSTN
- Telephony participants entering the healthcare language-access workflow.
- Webex
- External conferencing interoperability through separate SIP signaling and RTP media paths.
- Custom routing and call forwarding
- Language selection, interpreter assignment, and participant routing.