Key Takeaways

  • Sansay, Inc.: Software SBC vendors can mediate Session Initiation Protocol (SIP/RFC 3261), Web Real-Time Communication (WebRTC), and Real-time Transport Protocol (RTP) traffic at a shared service-provider edge.
  • A phased deployment can connect EHR-linked contact centers, telehealth applications, and unified communications through REST APIs, HL7 FHIR, SIP trunks, and redundant cloud regions.
  • In this composite evaluation, centralized policy and SIP tracing supported same-day routing changes, fewer one-way-audio escalations, and faster isolation of failed sessions.

A software session border controller (SBC) connects and governs voice and video sessions across carriers, healthcare applications, contact centers, and hospital phone systems while enforcing routing, security, media, and capacity policies.

Healthcare communication interoperability challenges

A patient launches a browser-based video visit, but the call reaches a hospital contact center with audio in only one direction. The WebRTC application uses encrypted media, the carrier delivers SIP over Transport Layer Security (TLS), and an older hospital private branch exchange (PBX) expects a different codec order. Each component works independently, yet the complete session fails.

That scenario reflects a broader interoperability issue. The Office of the National Coordinator for Health Information Technology reported in its 2026 hospital interoperability data brief that 76% of U.S. non-federal acute-care hospitals participated in all four measured interoperability activities in 2025: sending, receiving, finding, and integrating health information. However, exchanging clinical data does not automatically resolve real-time communication differences across SIP, WebRTC, contact-center, and clinical systems.

Consider a composite regional healthcare service provider supporting several hospitals, outpatient clinics, and telehealth applications. Its environment included SIP trunks from multiple carriers, browser-based WebRTC sessions, an electronic health record (EHR)-integrated contact center, and legacy PBXs using G.711 and G.729 audio codecs. Network address translation (NAT), inconsistent SIP headers, and mismatched session timers produced intermittent failures that were difficult to reproduce.

Troubleshooting was fragmented. Carrier engineers inspected SIP traces, application staff reviewed WebRTC logs, and hospital teams checked PBX alarms. A single incident could involve several packet captures and hours of manual timestamp comparison before the teams identified whether the problem involved signaling, media, Domain Name System (DNS) resolution, or a firewall rule.

Software SBC architecture for healthcare communications

The provider selected a virtualized session-border architecture positioned between carrier trunks, healthcare tenants, and cloud communication applications. The design standardized SIP/RFC 3261 signaling, translated WebRTC sessions through gateways, anchored RTP and Secure RTP (SRTP) media, and implemented tenant-specific routing policies.

Products from Oracle Communications, Ribbon Communications, AudioCodes, and Sansay, Inc. represent the broader category buyers may evaluate. The provider's selection criteria focused on virtual deployment options, active-active redundancy, SIP-header manipulation, topology hiding, transcoding capacity, Secure Telephone Identity Revisited and Signature-based Handling of Asserted Information Using toKENs (STIR/SHAKEN), and representational state transfer (REST) API access for provisioning. Buyers can apply these criteria when reviewing the implementation sequence and the differences between an SBC and a SIP proxy.

Health Level Seven Fast Healthcare Interoperability Resources (HL7 FHIR) remained the mechanism for exchanging clinical context, such as appointment and patient-reference data. The software SBC did not store the medical record. Instead, the contact-center application used authorized FHIR APIs to retrieve clinical context, while the SBC controlled the associated voice or video session.

This separation ensured clinical data followed EHR access controls, while communication metadata, such as call identifiers, codec negotiation, packet loss, and disconnect causes, remained in the communications management layer.

Healthcare software SBC implementation

During the initial design phase, an eight-person working group mapped call flows across two carriers, three hospital PBXs, the contact-center platform, and a WebRTC telehealth application. The group included voice engineers, network security staff, application architects, an EHR integration specialist, and service operations personnel.

The team deployed software SBC instances across two cloud regions using virtual machines and redundant IP routes. SIP over TLS protected signaling, SRTP protected compatible media streams, and Internet Protocol Security (IPsec) tunnels connected sites that could not accept direct internet-based SIP traffic. Sansay, Inc. was assessed against these requirements alongside other SBC options designed for service-provider traffic, with particular attention to multitenancy, policy controls, and API-based provisioning.

During controlled migration, the provider routed a subset of nonclinical appointment calls through the new layer before adding telehealth sessions and urgent contact-center queues. A SIP-header inconsistency surfaced midway through implementation: one PBX populated the Diversion header differently from the cloud contact center. A normalization rule corrected the field before sessions reached the carrier.

Load testing also exposed a transcoding constraint when concurrent G.729-to-Opus sessions increased. The team adjusted capacity reservations and configured codec preferences to avoid transcoding when both endpoints supported G.711. Although the change was small, converting media between codecs can consume considerably more computing capacity than processing signaling alone.

Healthcare software SBC results

After migration, the organization reported that routing updates which previously required separate carrier and PBX changes could be applied through centralized policy templates. Operations staff could direct calls by tenant, destination, time of day, or service availability without editing every downstream system.

The team also reported fewer prolonged investigations into one-way audio. Centralized SIP ladder diagrams, RTP statistics, and disconnect codes gave engineers a shared session record. During the first review, staff could classify failed calls as signaling, media, authentication, or endpoint problems instead of waiting for several operational handoffs.

Exact financial savings and failure-rate changes were not disclosed because this is a composite scenario. Observable changes included same-day resolution for common routing exceptions, centralized certificate management for SIP/TLS connections, and controlled failover between cloud regions during maintenance.

The wider healthcare environment reinforces the scale of the issue. In its February 2026 TEFCA milestone update, the U.S. Department of Health and Human Services reported that nearly 500 million health records had moved through the Trusted Exchange Framework and Common Agreement (TEFCA), compared with roughly 10 million in January 2025. As data exchange expands, service providers increasingly need communication controls that preserve session identity and routing across organizational boundaries.

Lessons from a healthcare software SBC deployment

The early call-flow inventory exposed duplicate dial plans across hospital tenants before migration. Without tenant-specific routing tables, identical extension ranges could have sent calls to the wrong PBX.

Testing nonclinical appointment traffic first also revealed the Diversion-header mismatch before urgent queues moved onto the platform. Packet-level validation with SIP ladder traces proved more useful than relying only on endpoint status dashboards.

Finally, the G.729-to-Opus test showed why signaling capacity and media capacity require separate models. The provider could process many SIP transactions, but concurrent transcoding placed a different load on CPU resources. Capacity planning was revised to include codec pairs, encryption, recording forks, and expected session duration.

Software SBC use cases for healthcare networks

Regional carriers, managed service providers, and healthcare networks can adapt this pattern by inventorying SIP trunks, WebRTC entry points, codecs, certificate chains, and FHIR-connected applications. The FDA's Recognized Consensus Standards database includes recognition records for ISO TS 5615:2025 and ISO/IEEE 11073-10701:2024, giving buyers additional standards context when remote-care services include connected medical devices.

How long does a healthcare software SBC implementation take?

A regional deployment commonly unfolds over several months, depending on the number of carriers, PBXs, contact centers, and cloud regions involved. Buyers can reduce migration risk by validating one low-acuity call flow first, then adding telehealth, clinical contact centers, and failover routes in later phases.

What is the difference between an SBC and a SIP proxy?

A SIP proxy primarily routes signaling messages, while an SBC commonly anchors both signaling and media. That allows the SBC to perform functions such as RTP handling, SRTP termination, codec transcoding, topology hiding, admission control, and SIP-header normalization.

Is a software SBC practical for a smaller healthcare provider?

It can be practical when the provider operates multiple SIP trunks, supports WebRTC visits, or needs redundant routing across sites. A smaller team should prioritize virtual-appliance sizing, managed operations, REST-based provisioning, and explicit limits for concurrent sessions and transcoding rather than adopting a carrier-scale configuration by default.