The way enterprises communicate has changed forever. But not every organisation is ready to hand that communication over to the cloud — and they shouldn't have to.

In an era where remote and hybrid work has become the new normal, video conferencing is no longer a convenience — it is a critical business infrastructure. Yet for industries where data sovereignty, regulatory compliance, and operational security are non-negotiable, generic cloud-based platforms simply fall short. What these sectors need is a fully on-premise, secure video conferencing solution that doesn't compromise on performance, flexibility, or control.

That solution is Samvyo — a highly customizable, fully made in India video conferencing platform purpose-built for enterprises in regulated and mission-critical industries.

This blog explores what makes Samvyo different, how it serves specific industry needs, and why organisations — especially government departments — are choosing on-premise video conferencing as the future of secure communication.

What Is Samvyo? A Platform Built for Enterprise Demands

Samvyo is an enterprise-grade, real-time communication platform developed by Samvyo Technologies, a CentEdge company. Unlike traditional video conferencing tools that route your data through third-party cloud servers across geographies, Samvyo is designed to run entirely within your organisation's infrastructure — on-premise, on your terms.

Being a fully made in India video conferencing solution, Samvyo is developed with a deep understanding of the compliance landscapes, data governance requirements, and technological challenges unique to Indian enterprises and government bodies. It is not an adaptation of a foreign product — it is an Indian-first, enterprise-first platform.

Core Feature Set at a Glance

Samvyo delivers a comprehensive suite of features designed to support seamless, secure, and scalable communication:

High-Definition Video & Audio — Crystal-clear, low-latency video conferencing powered by WebRTC, supporting HD and adaptive stream quality based on network conditions.

End-to-End Encryption (E2EE) — All communication channels are encrypted end-to-end, ensuring that conversations remain private from the moment they leave the sender to the moment they reach the receiver.

Screen Sharing & Collaboration Tools — Real-time screen sharing, virtual whiteboards, and in-meeting file sharing to keep teams productive and connected.

AI-Powered Transcription & Analytics — Integrated speech-to-text and meeting analytics capabilities that help organisations capture, review, and act on conversations efficiently.

Custom Recording & Storage — Meetings can be recorded and stored on infrastructure of your choosing — on-premise, private cloud, or hybrid — giving you full control over sensitive data.

Scalable Multi-Party Meetings — Support for large-scale meetings and webinars, making it suitable for everything from one-on-one check-ins to company-wide town halls.

Network Resilience & Quality Monitoring — Built-in call quality monitoring, congestion recovery, and network diagnostics to ensure reliable communication even in challenging network environments.

For the architecture behind these guarantees, see what actually runs behind enterprise-grade video. These features are not bolted on as extras — they are foundational to the Samvyo platform, designed to meet the demands of industries where reliability and security are paramount.

Industry Use Cases: Tailored for the Sectors That Cannot Afford to Compromise

Banking, Financial Services & Insurance (BFSI)

The BFSI sector handles some of the most sensitive data in the economy — customer financial records, transaction histories, loan documentation, and audit trails. Any communication platform used within this industry must meet stringent data protection and regulatory compliance requirements.

Samvyo enables BFSI organisations to conduct board meetings, client consultations, inter-branch communications, and compliance reviews — all within a secure, on-premise environment. With end-to-end encryption, custom recording storage, and full audit-ready logging, Samvyo ensures that every conversation is not only secure but also traceable and compliant with regulations like RBI guidelines and SEBI directives.

Healthcare

In healthcare, communication failures can have life-or-death consequences. From telemedicine consultations to inter-department coordination in hospitals, the need for reliable, secure, and HIPAA-aligned (or equivalent) communication infrastructure is critical.

Samvyo supports healthcare institutions by providing a secure video conferencing environment for doctor-patient consultations, multi-specialist case discussions, and administrative coordination — without the risk of patient data being stored on unsecured external servers. AI-powered transcription further aids in maintaining accurate consultation records, reducing the burden on medical professionals while improving care continuity.

Automotive

The automotive industry is rapidly evolving — from traditional manufacturing to electric vehicles, autonomous driving, and connected car technologies. Collaboration across R&D teams, suppliers, and manufacturing units demands a communication platform that is fast, secure, and deeply integrated into the workflow.

Samvyo supports automotive enterprises by enabling real-time collaboration between design, engineering, and production teams across geographies. With high-definition video and low latency, technical discussions — from prototype reviews to supply chain coordination — happen with the clarity and speed that this fast-moving industry demands. On-premise deployment also ensures that proprietary design and engineering data never leaves the organisation's controlled environment.

Safety & Security

For organisations operating in the safety and security domain — whether it is smart surveillance, emergency response coordination, or critical infrastructure monitoring — communication must be instantaneous, secure, and immune to external interference.

Samvyo's on-premise architecture makes it an ideal fit for safety and security operations centres. Whether it is coordinating a response team during an emergency, conducting inter-agency briefings, or facilitating real-time situational awareness meetings, Samvyo ensures that sensitive operational communications stay within a closed, controlled network. The platform's resilient networking capabilities and quality monitoring features further guarantee that communication remains uninterrupted when it matters most.

Manufacturing

Modern manufacturing is defined by precision, efficiency, and tight coordination between production floors, quality teams, supply chains, and leadership. Communication gaps in this environment can lead to costly downtime, quality issues, and delayed deliverables.

Samvyo enables manufacturing enterprises to bridge these gaps with seamless video conferencing that works reliably across factory floors, corporate offices, and remote supplier locations. From daily stand-ups on the production line to cross-facility quality reviews and vendor negotiations, Samvyo provides a secure and stable communication channel that keeps operations running smoothly — without dependence on public internet infrastructure.

On-Premise Video Conferencing for Government: Full Control, Full Security

Government departments — at the central, state, and local levels — are among the most demanding users of secure communication technology. Policy discussions, inter-agency coordination, defence briefings, and citizen-facing operations all require communication platforms that meet the highest standards of data sovereignty and security. For these organisations, the cloud is often not an option. What they need is complete control.

Samvyo's on-premise deployment model was designed with exactly this need in mind. Here is why government departments are choosing Samvyo as their secure communication backbone:

Custom Recording Storage

Government bodies often have specific, long-term data retention requirements governed by law and policy. With Samvyo, organisations have full flexibility to define where and how meeting recordings are stored. Recordings can be directed to on-premise storage servers, private data centres, or specific archival systems — all under the full control of the organisation. No data is stored on third-party infrastructure. No data leaves the boundary you define.

End-to-End Encryption

Every communication on Samvyo is protected by robust end-to-end encryption. This means that audio, video, and data shared during a meeting are encrypted at the source and decrypted only at the intended recipient's end. There is no point in the communication chain — not even the server — where the content is accessible in an unencrypted state. For government departments discussing sensitive policy matters, classified information, or national security issues, this level of encryption is not a feature — it is a requirement.

Fully Operational on LAN / WAN / VPN — Without Internet

Perhaps the most critical advantage of Samvyo for government use cases is its ability to operate entirely without internet connectivity. The platform can be deployed and run on an organisation's internal Local Area Network (LAN), Wide Area Network (WAN), or secure VPN infrastructure. This means that communication happens in a fully closed loop — no packets leave the organisation's network, no external dependencies exist, and no external entity can intercept or monitor the communication.

This capability is particularly vital for defence establishments, intelligence agencies, critical infrastructure operators, and any government body that requires air-gapped or network-isolated communication. Samvyo transforms video conferencing from a cloud-dependent service into a fully sovereign communication tool — one that the organisation owns, controls, and secures entirely on its own terms.

A Global Signal: France Leads the Way on Digital Sovereignty in Video Conferencing

India is not the only nation recognising the risks of depending on foreign technology for critical communications. In January 2026, France made headlines when it officially announced the phase-out of US-based video conferencing platforms — including Zoom, Microsoft Teams, and Google Meet — across all government departments. The move is part of France's strategy to stop using foreign software vendors, especially those from the United States, and regain full control over critical digital infrastructure.

The French government is replacing these platforms with Visio, a domestically developed video conferencing tool. Visio has been in testing for about a year and already supports around 40,000 users within French government networks. The switch promises significant cost savings — the French government said that switching to Visio could cut licensing costs and save as much as €1 million per year for every 100,000 users.

France's minister for the civil service, David Amiel, framed the decision plainly: "We cannot risk having our scientific exchanges, our sensitive data, and our strategic innovations exposed to non-European actors."

This is part of a broader shift toward communication sovereignty — enterprises and governments choosing to own their own infrastructure rather than rent it.

This is not an isolated move. The EU is increasingly keen on digital sovereignty, backing a network of European data service providers to reduce dependence on US cloud computing. The message is clear: nations around the world are waking up to the fact that sovereign, homegrown communication infrastructure is no longer optional — it is a strategic imperative.

For Indian enterprises and government departments, the lesson is directly applicable. If France — a technologically advanced nation — is making this shift, the question for India is not whether to adopt a homegrown video conferencing solution, but which one to trust.

Why "Fully Made in India" Matters

In a world where data sovereignty and digital self-reliance are becoming national priorities, the origin and architecture of the technology you adopt matters more than ever. Samvyo is not just made in India — it is designed in India, engineered in India, and optimised for the unique requirements of Indian enterprises and government bodies.

This means faster support, deeper understanding of local compliance frameworks, alignment with initiatives like Digital India and Make in India, and the confidence that your organisation's communication infrastructure is built on technology you can trust, understand, and govern.

The Bottom Line

Choosing a video conferencing platform is not just a technology decision — it is a strategic one. For industries like BFSI, Healthcare, Automotive, Safety & Security, and Manufacturing, and especially for government departments, the right platform must deliver security without compromise, flexibility without complexity, and performance without dependency on external infrastructure.

Samvyo delivers all of this. It is a highly customizable video conferencing solution that adapts to the unique needs of every organisation, a fully made in India platform engineered to world-class standards and built to serve enterprises not just across India, but across the globe, and an on-premise secure video conferencing system that keeps your data, your conversations, and your operations entirely under your control.

The future of enterprise communication is secure. It is sovereign. It is built in India — and it is built for the world.

Ready to Experience Samvyo? Let's Talk.

Whether you are evaluating secure video conferencing options for your enterprise, exploring on-premise deployment for your government department, or simply looking for a highly customizable platform that fits your industry's unique demands — we would love to hear from you.

📅 Schedule a Demo Experience Samvyo firsthand with a personalised walkthrough tailored to your industry and requirements. 👉 Book a Demo with Our Team

📞 Talk to a Specialist Have specific questions about on-premise deployment, compliance, or integration? Our team of experts is ready to assist. 👉 Schedule a Consultation

📧 Get in Touch Prefer to start with an email? Reach out to our enterprise solutions team directly. 👉 Contact Us

Samvyo — Secure. Sovereign. Built in India. For India and the World.

Discover how Samvyo's unified platform combines video conferencing, AI-powered contact centers, and developer SDKs to transform business communication in 2026

Table of Contents

1. Introduction: The Communication Revolution
2. Samvyo Meet: Beyond Traditional Video Conferencing
3. Samvyo Meetnow: AI-First Contact Center Revolution
4. Samvyo Video SDKs: Developer-First Integration Platform
5. Why Now: A Decade of Enterprise Experience
6. Why Choose Samvyo: The Unified Communication Advantage
7. Getting Started with Samvyo
8. Future Roadmap and AI Integration
9. Frequently Asked Questions

Introduction: The Communication Revolution {#introduction}

The landscape of business communication has fundamentally shifted. What began as a necessity during the global pandemic has evolved into a strategic imperative: organizations need communication solutions that are not just functional, but intelligent, customizable, and seamlessly integrated into their business workflows.

Today, we're proud to announce Samvyo v3.0, a comprehensive real-time communication platform that addresses the three critical gaps in today's market: enterprise-grade video conferencing, AI-powered customer support, and developer-friendly integration tools.

Unlike fragmented solutions that force businesses to juggle multiple platforms, Samvyo provides a unified ecosystem designed for the modern enterprise. Our platform combines the reliability of enterprise software with the flexibility of open-source solutions and the intelligence of AI-first design.

Key Statistics:

• 78% of businesses use 3+ communication tools daily
• 64% report integration challenges between platforms
• 89% want AI-powered insights from their communication data
• 92% of developers prefer pay-per-use pricing for communication APIs

Samvyo v3.0 isn't just another communication platform—it's the foundation for intelligent business communication in the AI era.

Samvyo Meet: Beyond Traditional Video Conferencing {#samvyo-meet}

The Problem with Current Video Conferencing Solutions

Traditional video conferencing platforms like Zoom, Google Meet, and Microsoft Teams were designed for a pre-AI world. They excel at basic video calls but fall short when businesses need:

• Deep customization without compromising security
• Advanced analytics beyond basic attendance tracking
• Seamless integration with existing business systems
• Flexible pricing that scales with actual usage
• Enterprise compliance without enterprise complexity

Samvyo Meet: A New Paradigm

Samvyo Meet redefines video conferencing by combining enterprise reliability with startup agility. Built on our decade of experience in real-time communication, it delivers:

🎯 Enterprise-Grade Performance

• 99.9% uptime SLA with global CDN distribution
• End-to-end encryption with GDPR, HIPAA, and PCI-DSS compliance
• Unlimited participants with intelligent load balancing
• 4K video quality with adaptive streaming technology
• Sub-100ms latency worldwide through our optimized infrastructure

🔧 Unprecedented Customization

Unlike rigid platforms that offer limited theming options, Samvyo Meet provides:

• White-label solutions with complete brand customization
• Custom UI/UX tailored to your workflow requirements
• API-first architecture enabling deep system integration
• Configurable media flows for specialized use cases
• Custom analytics dashboards with business-specific KPIs

🤖 Built-in Intelligence

• Real-time transcription in 40+ languages
• Automated meeting summaries with action item extraction
• Participant engagement analytics including attention tracking
• Voice sentiment analysis for meeting effectiveness measurement
• Smart scheduling with calendar integration and conflict resolution

💰 Transparent Pay-Per-Use Pricing

• No per-seat licensing - pay only for actual usage
• Minute-based billing starting at $0.01 per participant per minute
• Volume discounts that scale with your growth
• Predictable costs with detailed usage analytics
• Free tier with 100 minutes monthly for small teams

Use Cases: Where Samvyo Meet Excels

🏢 Enterprise Communications

• Board meetings with advanced security requirements
• Global team collaboration with multi-language support
• Client presentations with custom branding
• Training sessions with engagement tracking

🏥 Healthcare & Telemedicine

• HIPAA-compliant patient consultations
• Medical team collaboration with screen annotation
• Training sessions with recorded playback
• Multi-specialist consultations with seamless handoffs

🎓 Education & Training

• Interactive classrooms with real-time polls
• Corporate training with completion tracking
• Webinars with custom registration flows
• Student assessment with proctoring capabilities

⚖️ Legal & Professional Services

• Client consultations with document sharing
• Court proceedings with recording compliance
• Contract negotiations with annotation tools
• Team depositions with multi-party coordination

Samvyo Meetnow: AI-First Contact Center Revolution {#samvyo-meetnow}

The Contact Center Crisis

Traditional contact centers are broken. The statistics are alarming:

• Average wait time: 11 minutes across industries
• First-call resolution: Only 74% achieve resolution
• Customer satisfaction: Declining year-over-year
• Agent burnout: 75% annual turnover rate
• Setup complexity: 6-12 months for enterprise deployment

Phone trees, IVR systems, and queue-based support create friction exactly when customers need help most. The result? Frustrated customers, overwhelmed agents, and businesses losing revenue to poor support experiences.

Samvyo Meetnow: The QR Code Revolution

Samvyo Meetnow eliminates traditional contact center friction through innovative QR code-based video calling. It's not just an evolution—it's a complete reimagining of customer support.

🚀 Instant Connection Without Barriers

QR Code Magic:

• Scan and connect in under 3 seconds
• No app downloads or phone number requirements
• Works anywhere - websites, mobile apps, physical locations
• Universal compatibility across all devices and browsers
• Offline resilience with smart retry mechanisms

Real-World Implementation:

• eCommerce: Product consultation directly from product pages
• Retail Stores: Instant staff assistance via QR codes on shelves
• Hotels: Concierge services without calling the front desk
• Restaurants: Table service requests and menu explanations
• Healthcare: Patient support without waiting rooms
• Financial Services: Secure account discussions with video verification

🤖 AI-First, Human-Led Approach

Unlike traditional systems that use AI as an afterthought, Meetnow is designed with AI at its core:

Pre-Call Intelligence:

• Context gathering from QR code location and user behavior
• Intent prediction based on customer journey analysis
• Agent matching using skill-based routing and availability
• Background research on customer history and preferences
• Prep briefings delivered to agents before connection

During-Call Enhancement:

• Real-time translation for global customer support
• Sentiment monitoring with escalation triggers
• Knowledge base integration with suggested responses
• Screen sharing and collaborative problem-solving
• Automated note-taking with CRM integration

Post-Call Intelligence:

• Automatic call summaries with resolution tracking
• Follow-up scheduling based on conversation outcomes
• Satisfaction surveys with intelligent timing
• Performance analytics for continuous improvement
• Training insights for agent development

📊 Analytics That Drive Business Decisions

Customer Experience Metrics:

• Connection time: Average time from QR scan to agent connection
• Resolution rate: First-call resolution tracking with root cause analysis
• Satisfaction scores: Real-time NPS with sentiment correlation
• Journey mapping: Visual representation of customer touchpoints
• Conversion tracking: Support-to-sale conversion analytics

Operational Efficiency:

• Agent productivity: Calls per hour with quality maintenance
• Queue optimization: Dynamic routing based on real-time demand
• Cost per interaction: ROI measurement across all channels
• Capacity planning: Predictive staffing based on historical patterns
• Training effectiveness: Skill development tracking and impact measurement

🛡️ Enterprise Security & Compliance

• End-to-end encryption for all video communications
• GDPR compliance with automatic data retention policies
• PCI-DSS certification for payment-related discussions
• HIPAA compliance for healthcare customer support
• SOC 2 Type II certification for enterprise trust
• Custom data residency options for regulatory requirements

Competitive Advantage: Why Meetnow Wins

🆚 Traditional Contact Centers:

• Setup Time: Minutes vs. months
• Customer Wait: Seconds vs. minutes
• Resolution Rate: 92% vs. 74% industry average
• Agent Satisfaction: 89% vs. 25% industry retention
• Cost Efficiency: 60% lower than traditional systems

🆚 Chat-Only Solutions:

• Communication richness: Video + voice vs. text only
• Emotional connection: Face-to-face interaction builds trust
• Problem-solving speed: Visual demonstration vs. lengthy descriptions
• Verification capability: Identity confirmation through video
• Resolution complexity: Handle complex issues that chat cannot

Samvyo Video SDKs: Developer-First Integration Platform {#samvyo-sdks}

The Developer Integration Challenge

Modern applications require real-time communication, but implementing video and voice capabilities has historically been a nightmare:

• Months of development for basic functionality
• Complex WebRTC management across browsers and devices
• Scalability concerns as user base grows
• Security vulnerabilities in custom implementations
• Maintenance overhead for ongoing updates
• Cross-platform compatibility issues

Samvyo SDKs: Integration in Hours, Not Months

Our comprehensive SDK suite transforms video integration from a months-long project into an afternoon's work.

📦 Complete SDK Ecosystem

🌐 JavaScript SDK

// Initialize Samvyo in 3 lines
import Samvyo from 'samvyo-js-sdk';
const client = new Samvyo.init({ apiKey: 'your-key' });
await client.joinRoom('room-id');

Features:

• Vanilla JavaScript compatibility with any web framework
• TypeScript support with full type definitions
• Tree-shakable for optimal bundle sizes
• CDN distribution for global performance
• Offline support with intelligent reconnection

⚛️ React SDK

// React components ready out of the box
import { VideoRoom, useParticipants } from 'samvyo-react-sdk';

function MyVideoApp() {
  return (
    <VideoRoom 
      roomId="my-room"
      onJoin={handleJoin}
      customUI={MyCustomControls}
    />
  );
}

Features:

• Pre-built components for rapid development
• Custom hooks for state management
• Composition patterns for flexible UI design
• SSR support for Next.js applications
• Performance optimized with React.memo and useMemo

📱 React Native SDK

// Native mobile performance
import { SamvyoCall } from 'samvyo-rn-sdk';

<SamvyoCall
  roomId="mobile-room"
  enableCamera={true}
  enableAudio={true}
  customStyles={mobileStyles}
/>

Features:

• Native iOS/Android modules for optimal performance
• Background calling with CallKit/ConnectionService integration
• Push notifications for incoming calls
• Bluetooth device support for headsets and speakers
• Picture-in-picture mode for multitasking

🚀 Developer Experience Excellence

🔧 Comprehensive Documentation:

• Interactive tutorials with live code examples
• API reference with searchable documentation
• Video guides for complex integration scenarios
• Community examples across different frameworks
• Migration guides from other platforms

🎮 Sandbox Environment:

• Live testing without affecting production
• Mock scenarios for edge case testing
• Performance monitoring during development
• Debug tools with detailed logging
• Integration testing with CI/CD pipelines

🛠️ Developer Tools:

• CLI tools for project scaffolding and deployment
• Browser extensions for debugging WebRTC issues
• VS Code extension with autocomplete and snippets
• Postman collections for API testing
• Webhook testing tools for event handling

⚡ Performance & Scalability

Global Infrastructure:

• Edge deployment across 40+ regions worldwide
• Automatic scaling based on demand patterns
• Load balancing with intelligent traffic routing
• CDN optimization for media delivery
• Redundancy with 99.99% uptime guarantee

Optimization Features:

• Adaptive bitrate streaming based on network conditions
• Bandwidth management with quality adjustment
• Battery optimization for mobile devices
• CPU efficiency with hardware acceleration
• Memory management with automatic cleanup

💡 Advanced Capabilities

AI Integration:

• Real-time transcription APIs with custom vocabulary
• Sentiment analysis hooks for mood detection
• Noise cancellation with environmental adaptation
• Voice enhancement for crystal-clear audio
• Background replacement with custom scenes

Custom Media Flows:

• Screen recording with selective area capture
• Virtual backgrounds with green screen effects
• Audio mixing for multiple input sources
• Video filters and real-time effects
• Broadcasting to social media platforms

Use Cases: SDK Integration Success Stories

🛒 eCommerce Platforms

• Product consultation with live video shopping
• Customer support integration within checkout flows
• Virtual try-ons with augmented reality features
• Expert advice connecting customers with specialists

🎓 EdTech Applications

• Virtual classrooms with interactive whiteboards
• One-on-one tutoring with session recording
• Group study sessions with collaborative tools
• Parent-teacher conferences with scheduling integration

🏥 Healthcare Applications

• Telemedicine consultations with HIPAA compliance
• Remote patient monitoring with vital sign integration
• Medical training with procedure recording
• Mental health support with privacy-first design

💼 Business Applications

• Customer onboarding with document verification
• Sales presentations with interactive demos
• Team collaboration with project management integration
• Client consultations with CRM synchronization

Why Now: A Decade of Enterprise Experience {#why-now}

Our Journey: From Enterprise Consulting to Platform Innovation

For the past decade, Samvyo has been the hidden force behind some of the world's most sophisticated communication applications. We've partnered with Fortune 500 companies across BFSI, healthcare, automotive, and manufacturing sectors, building custom real-time communication solutions that handle millions of interactions daily.

🏗️ Enterprise Foundations

Our Track Record:

• 50+ enterprise deployments across 15 countries
• 10M+ hours of production video/voice traffic
• 99.98% uptime across all enterprise installations
• Zero security breaches in production environments
• 24/7 support with average 2-minute response times

Industries Served:

• Banking & Financial Services: Secure customer consultations, loan processing, investment advisory
• Healthcare Systems: Telemedicine platforms, specialist consultations, patient care coordination
• Automotive Manufacturing: Remote quality inspection, technician training, supplier collaboration
• Insurance Companies: Claims processing, risk assessment, customer onboarding
• Government Agencies: Citizen services, inter-agency communication, public safety coordination

📈 The Post-COVID Pattern Recognition

The pandemic accelerated digital transformation by 5-7 years, but it also exposed critical gaps in existing communication solutions. Through our enterprise partnerships, we identified three consistent failure patterns:

🚫 Pattern 1: The Customization Ceiling Commercial providers like Zoom and Teams offer limited customization options. Enterprises hit walls when they need:

• Custom authentication flows
• Industry-specific compliance requirements
• Unique workflow integrations
• Specialized analytics and reporting
• White-label deployment options

Real Example: A healthcare client needed HIPAA-compliant video calls with custom patient verification. Existing solutions required workarounds that introduced security vulnerabilities.

🚫 Pattern 2: The Open Source Scalability Trap Open-source solutions like Jitsi and WebRTC libraries provide flexibility but create new problems:

• Unpredictable scaling costs
• Complex deployment and maintenance
• Security vulnerability management
• Limited enterprise support
• Integration complexity with existing systems

Real Example: A financial services company built on open-source WebRTC spent 18 months and $2M+ just to handle peak traffic loads reliably.

🚫 Pattern 3: The Integration Nightmare Most organizations end up with communication tool sprawl:

• Separate platforms for internal meetings, customer support, and API integrations
• Disconnected analytics and reporting
• Inconsistent user experiences
• Multiple vendor relationships to manage
• Data silos that prevent unified insights

Real Example: An automotive manufacturer used 7 different communication tools, making it impossible to track the customer journey from initial inquiry to post-sale support.

🔍 Market Research Insights

Our extensive market research revealed that 89% of enterprises want a solution that combines:

• Commercial reliability with enterprise SLAs
• Open-source flexibility for custom requirements
• Unified platform approach to reduce complexity
• Pay-per-use pricing that scales with actual business value
• AI-first design for future-ready capabilities

The Samvyo Solution Architecture

Based on this decade of learnings, we architected Samvyo v3.0 with five core principles:

🎯 1. Commercial Reliability with Open Source Flexibility

• Enterprise SLAs with 99.9% uptime guarantees
• Customizable core including media processing pipelines
• API-first design enabling deep system integration
• Professional support with dedicated success managers
• Regular updates without breaking changes

💰 2. Transparent Pay-Per-Use Economics

• No seat-based licensing that penalizes growth
• Minute-based billing aligned with actual value delivery
• Predictable scaling with volume discounts
• No hidden fees or surprise overage charges
• Real-time usage monitoring for cost optimization

🔗 3. Unified Platform Approach

• Single dashboard for all communication needs
• Shared analytics across meeting, support, and integration use cases
• Consistent APIs reducing development complexity
• Centralized user management with SSO integration
• Consolidated billing simplifying vendor relationships

🤖 4. AI-First, Human-Centered Design

• Built-in intelligence rather than bolted-on features
• Context-aware automation that enhances human capabilities
• Privacy-preserving AI that respects data sovereignty
• Continuous learning that improves over time
• Explainable insights for decision-making transparency

🛡️ 5. Security and Compliance by Design

• Zero-trust architecture with end-to-end encryption
• Multi-region deployment for data residency requirements
• Automated compliance reporting for audits
• Threat detection with real-time monitoring
• Regular penetration testing by third-party security firms

Why Choose Samvyo: The Unified Communication Advantage {#why-choose-samvyo}

The Communication Intelligence Revolution

While competitors focus on individual communication channels, Samvyo provides unified communication intelligence. Our platform understands the complete context of your business communications—from internal team meetings to external customer interactions—creating a foundation for intelligent decision-making.

🧠 Unified AI Context Understanding

Cross-Channel Intelligence: Traditional platforms analyze communications in isolation. Samvyo's AI understands the relationships between:

• Internal team discussions about customer issues
• Customer support interactions with resolution outcomes
• Sales conversations with conversion patterns
• Product feedback from multiple touchpoints
• Training sessions with performance improvements

Real-World Impact: Imagine your sales team discussing a client challenge in a Samvyo Meet session. Our AI identifies the client name and automatically surfaces:

• Recent support tickets from that customer
• Previous sales call sentiment analysis
• Product usage patterns and pain points
• Competitor mentions and concerns
• Recommended talking points for the next interaction

This level of context awareness is impossible with fragmented communication tools.

📊 Business Intelligence Through Communication Data

🎯 Customer Journey Optimization

• Touchpoint mapping across all communication channels
• Sentiment tracking from first contact to resolution
• Conversion analysis identifying successful interaction patterns
• Churn prediction based on communication frequency and tone
• Upsell opportunities discovered through conversation analysis

👥 Team Performance Insights

• Collaboration patterns identifying high-performing team structures
• Knowledge gaps revealed through question patterns in meetings
• Training needs identified through support call analysis
• Communication effectiveness measured across different mediums
• Leadership development insights from meeting facilitation patterns

📈 Business Strategy Intelligence

• Market sentiment analysis from customer interactions
• Product feedback aggregation from support and sales calls
• Competitive intelligence gathered from customer conversations
• Feature requests prioritization based on customer urgency
• Revenue impact correlation between communication quality and business outcomes

🔄 Seamless Workflow Integration

🛠️ CRM and Business System Synchronization

• Automatic call logging with context and outcomes
• Contact enrichment using conversation insights
• Deal progression tracking through communication milestones
• Support ticket creation from video call discussions
• Follow-up automation based on conversation analysis

📋 Project Management Integration

• Action item extraction from team meetings
• Task assignment based on conversation commitments
• Project status updates derived from team communications
• Resource allocation insights from collaboration patterns
• Timeline adjustment recommendations based on communication velocity

💼 Enterprise Workflow Automation

• Approval processes triggered by video call outcomes
• Escalation protocols based on conversation sentiment
• Compliance documentation automatically generated from calls
• Training assignments based on identified knowledge gaps
• Performance reviews enriched with communication analytics

🎚️ Single Dashboard Operational Command Center

📊 Executive Dashboard

• Communication health metrics across all channels
• Customer satisfaction trends with drill-down capabilities
• Team productivity insights with improvement recommendations
• Revenue correlation with communication quality scores
• Competitive positioning based on customer conversation analysis

🔧 Operations Dashboard

• Real-time monitoring of all communication channels
• Capacity planning with predictive analytics
• Quality assurance with automated conversation scoring
• Cost optimization with usage pattern analysis
• Security monitoring with threat detection alerts

👨‍💼 Manager Dashboard

• Team performance tracking with coaching recommendations
• Customer relationship health scoring with risk alerts
• Process optimization opportunities identified through communication analysis
• Training effectiveness measurement with ROI calculations
• Goal tracking with communication-based success metrics

Competitive Differentiation: The Samvyo Advantage

🆚 vs. Fragmented Tool Ecosystems

Traditional Approach Problems:

• Data silos preventing unified insights
• Context switching reducing productivity
• Integration complexity requiring custom development
• Vendor management overhead across multiple relationships
• Inconsistent experiences confusing users and customers

Samvyo Unified Approach Benefits:

• Single source of truth for all communication data
• Contextual continuity across all interaction types
• Native integrations with pre-built connectors
• Simplified vendor relationship with comprehensive support
• Consistent experience improving adoption and efficiency

🆚 vs. AI-Washing Competitors

Many platforms claim AI capabilities but offer shallow features that don't understand business context.

Superficial AI Features:

• Basic transcription without context understanding
• Generic sentiment analysis without business relevance
• Simple chatbots without conversation flow comprehension
• Keyword extraction without relationship mapping
• Templated responses without personalization

Samvyo's Deep AI Integration:

• Contextual understanding across all business communications
• Predictive insights based on communication patterns
• Proactive recommendations for business improvement
• Continuous learning from your specific business context
• Explainable AI with clear reasoning for recommendations

🆚 vs. Enterprise Legacy Solutions

Legacy Platform Limitations:

• Rigid architectures that resist customization
• Seat-based pricing that penalizes growth
• Vendor lock-in with proprietary formats
• Slow innovation cycles missing market opportunities
• Security through obscurity rather than transparency

Samvyo Modern Architecture:

• API-first design enabling unlimited customization
• Usage-based pricing that scales with business value
• Open standards preventing vendor lock-in
• Rapid feature delivery with weekly updates
• Transparent security with public architecture documentation

The Economic Impact of Unified Communication Intelligence

📊 Quantified Business Benefits:

Customer Experience Improvements:

• 40% reduction in average issue resolution time
• 60% increase in first-call resolution rates
• 25% improvement in customer satisfaction scores
• 35% decrease in customer churn rates
• 50% increase in support-to-sale conversion rates

Operational Efficiency Gains:

• 30% reduction in communication tool costs
• 45% decrease in time spent switching between platforms
• 55% improvement in team collaboration effectiveness
• 40% reduction in onboarding time for new team members
• 60% decrease in communication-related technical issues

Revenue Enhancement:

• 20% increase in sales conversion rates through better customer insights
• 30% improvement in upsell success through communication intelligence
• 25% reduction in customer acquisition costs through referral optimization
• 35% increase in customer lifetime value through proactive engagement
• 15% boost in overall revenue per employee through productivity gains

Getting Started with Samvyo {#getting-started}

Choose Your Samvyo Journey

Whether you're a developer looking to add video capabilities, a business seeking better customer support, or an enterprise needing comprehensive communication solutions, Samvyo has a path designed for you.

🚀 For Developers & Technical Teams

Quick Start Options:

🔥 5-Minute Integration Challenge

# Install Samvyo SDK
npm install samvyo-react-sdk

# Create your first video room
import { VideoRoom } from 'samvyo-react-sdk';
// 3 lines of code = production-ready video calling

📦 Starter Kits Available:

• React Video Chat - Complete Slack-like interface
• Customer Support Widget - Embeddable support solution
• Meeting Room Builder - Zoom-alternative template
• Mobile Video Calling - React Native implementation
• Healthcare Telemedicine - HIPAA-compliant template

🛠️ Developer Resources:

• Interactive Documentation: Live code examples you can modify and test
• API Playground: Test all endpoints without writing code
• Postman Collections: Ready-to-import API testing suites
• GitHub Examples: 20+ implementation examples across frameworks
• Developer Community: Discord channel with 1,000+ active developers

🎯 Free Developer Tier:

• 100 minutes/month free video calling
• Unlimited development in sandbox environment
• Full API access with rate limiting
• Community support via Discord and forums
• No credit card required for signup

💼 For Business Teams & Startups

Business Quick Start:

🎪 Try Before You Buy:

• 30-day free trial with full platform access
• Demo environment with sample data and scenarios
• Guided onboarding with dedicated success manager
• Custom use case consultation and setup
• Migration assistance from existing platforms

📋 Business Starter Packages:

📞 Customer Support Starter - $99/month

• Up to 500 support minutes monthly
• QR code generator for websites
• Basic analytics dashboard
• Email support with 4-hour response
• Integration with popular help desk tools

🤝 Sales & Marketing Starter - $199/month

• Up to 1,000 meeting minutes monthly
• Custom branding for video calls
• Lead capture integration
• Advanced analytics and reporting
• Priority support with 2-hour response

🏢 Business Growth - $499/month

• Up to 5,000 minutes across all products
• AI-powered insights and recommendations
• CRM integrations (Salesforce, HubSpot)
• Custom domain and white-labeling
• Dedicated success manager

🏗️ For Enterprise Organizations

Enterprise Engagement Process:

🔍 Discovery & Assessment (Week 1-2)

• Current state analysis of existing communication stack
• Use case identification and requirement gathering
• ROI modeling with quantified business benefits
• Security and compliance requirement review
• Integration complexity assessment and planning

🧪 Proof of Concept (Week 3-6)

• Sandbox environment with your branding and data
• Pilot user group testing key workflows
• Integration testing with existing systems
• Performance benchmarking against current solutions
• Security penetration testing and compliance validation

🚀 Deployment & Scaling (Week 7-12)

• Phased rollout across departments and regions
• Change management support and user training
• Monitoring and optimization of system performance
• Feedback collection and feature customization
• Success measurement and ROI validation

💎 Enterprise Features:

• Unlimited usage with volume discount pricing
• 99.99% uptime SLA with financial penalties
• Dedicated infrastructure with single-tenant options
• 24/7 priority support with 15-minute response times
• Custom feature development with engineering team access
• Global deployment across multiple regions and data centers

Implementation Timeline & Support

⏱️ Typical Implementation Timelines

Developer Integration:

• Simple video calling: 1-3 hours
• Customer support widget: 1-2 days
• Full communication platform: 1-2 weeks
• Enterprise customization: 2-4 weeks

Business Deployment:

• Basic setup: Same day
• Team onboarding: 3-5 days
• Workflow integration: 1-2 weeks
• Full optimization: 4-6 weeks

Enterprise Rollout:

• Pilot program: 2-4 weeks
• Department-wide: 6-8 weeks
• Organization-wide: 12-16 weeks
• Global deployment: 16-24 weeks

🆘 Support & Success Resources

📚 Learning Resources:

• Video tutorials covering every feature and use case
• Best practices guides based on successful implementations
• Webinar series with industry experts and power users
• Certification programs for developers and administrators
• Community forum with peer-to-peer support

🎯 Success Management:

• Dedicated success managers for business and enterprise customers
• Regular check-ins to ensure optimal platform utilization
• Performance reviews with improvement recommendations
• Feature updates and beta access to new capabilities
• Business review meetings with ROI measurement and optimization

Future Roadmap and AI Integration {#future-roadmap}

The AI-Powered Communication Future

Samvyo v3.0 is just the beginning. Our roadmap focuses on making communication not just connected, but intelligent—transforming every interaction into actionable business intelligence.

🤖 Q3 2026: Advanced AI Intelligence

🧠 Conversation Intelligence Engine

• Multi-language transcription with 99.5% accuracy across 50+ languages
• Real-time sentiment analysis with emotional state tracking
• Intent recognition predicting customer needs before they're expressed
• Key phrase extraction automatically identifying critical discussion points
• Action item detection with automatic follow-up scheduling

📊 Predictive Analytics Platform

• Customer churn prediction based on communication patterns and sentiment trends
• Sales opportunity scoring using conversation quality and engagement metrics
• Support ticket volume forecasting for optimal resource allocation
• Team performance prediction identifying training needs before issues arise
• Revenue correlation modeling connecting communication quality to business outcomes

🎯 Personalization Engine

• Dynamic conversation routing matching customers to optimal agents
• Personalized communication recommendations based on individual customer history
• Adaptive UI/UX adjusting interface based on user behavior patterns
• Content customization showing relevant information during conversations
• Proactive engagement suggesting optimal times and methods for outreach

🔗 Q4 2026: Unified Business Intelligence

🏢 Enterprise CRM Integration Suite

Salesforce Deep Integration:

• Automatic opportunity updates based on video call outcomes
• Lead scoring enhancement using communication engagement metrics
• Contact enrichment with conversation insights and preferences
• Pipeline management with communication-driven stage progression
• Revenue attribution tracking communication impact on deals

HubSpot Comprehensive Connector:

• Marketing automation triggers based on support conversation topics
• Customer journey mapping incorporating video interaction touchpoints
• Content personalization using communication preference data
• Lead nurturing optimization with video engagement scoring
• Attribution reporting connecting communication to marketing ROI

Custom CRM Adaptability:

• API-first integration supporting any CRM system
• Webhook-based automation for real-time data synchronization
• Custom field mapping aligning communication data with business processes
• Bi-directional sync ensuring data consistency across platforms
• Compliance-aware integration maintaining security and privacy standards

📈 Business Intelligence Dashboard

Executive Command Center:

• Real-time KPI monitoring across all communication channels
• Predictive business insights with 90-day forecasting
• Competitive intelligence gathered from customer conversations
• Market sentiment tracking identifying trends and opportunities
• ROI measurement quantifying communication platform business impact

Operational Intelligence:

• Resource optimization recommendations based on usage patterns
• Quality assurance automation with AI-powered conversation scoring
• Training need identification using performance gap analysis
• Process improvement suggestions derived from communication flow analysis
• Cost optimization insights maximizing value from platform investment

🌐 2027: Global Scale & Innovation

🚀 Next-Generation Features

Immersive Communication:

• Virtual reality meeting spaces for enhanced collaboration
• Augmented reality overlays providing contextual information during calls
• 3D product demonstrations within video conversations
• Spatial audio creating realistic meeting environments
• Holographic projection support for premium enterprise clients

Advanced AI Capabilities:

• Real-time language translation with cultural context awareness
• Emotion recognition with appropriate response suggestions
• Voice cloning for multilingual customer support
• Automated meeting summaries with action item assignment
• Predictive conversation routing optimizing outcomes before calls begin

Blockchain Integration:

• Immutable conversation records for compliance and legal requirements
• Smart contracts for automated billing and service level agreements
• Decentralized identity verification enhancing security and privacy
• Token-based incentive systems rewarding quality interactions
• Distributed infrastructure for enhanced reliability and privacy

Platform Evolution Strategy

🔄 Continuous Innovation Methodology

User-Driven Development:

• Monthly feature releases based on community feedback
• A/B testing framework for all new capabilities
• Beta user programs providing early access to innovations
• Customer advisory boards guiding product direction
• Open source contributions from community developers

Data-Driven Optimization:

• Performance monitoring across all platform components
• Usage pattern analysis informing feature prioritization
• Success metric tracking ensuring business value delivery
• Predictive capacity planning maintaining optimal performance
• Security threat modeling staying ahead of emerging risks

Ecosystem Expansion:

• Partner integration marketplace with third-party solutions
• Developer tool ecosystem supporting custom extensions
• Industry-specific solutions for healthcare, finance, education
• Regional customization meeting local compliance requirements
• White-label partnerships enabling reseller opportunities

Frequently Asked Questions {#faq}

🔧 Technical Integration Questions

Q: How quickly can we integrate Samvyo into our existing application? A: Integration time depends on complexity:

• Basic video calling: 1-3 hours using our React SDK
• Custom UI implementation: 1-2 days with our JavaScript SDK
• Full platform integration: 1-2 weeks including CRM connections
• Enterprise customization: 2-4 weeks with dedicated support

Our SDKs are designed for rapid integration with comprehensive documentation and live examples.

Q: What programming languages and frameworks do you support? A: We provide native SDKs for:

• JavaScript/TypeScript (vanilla and all major frameworks)
• React (hooks, components, and Next.js support)
• React Native (iOS and Android)
• REST APIs for any backend language
• Webhooks for real-time event handling

Additional SDK requests are evaluated based on community demand.

Q: How does Samvyo handle scaling and performance? A: Our platform is built for global scale:

• Auto-scaling infrastructure handling traffic spikes automatically
• Global CDN with 40+ edge locations worldwide
• Adaptive bitrate streaming optimizing for connection quality
• Load balancing distributing traffic across multiple regions
• 99.9% uptime SLA with redundant failover systems

Q: Can we customize the UI/UX to match our brand? A: Absolutely! Samvyo offers multiple customization levels:

• Theme customization with colors, fonts, and logos
• Component-level styling using CSS or styled-components
• Custom component development using our SDK building blocks
• White-label solutions with complete brand control
• API-first architecture enabling fully custom interfaces

🔒 Security & Compliance Questions

Q: What security certifications does Samvyo have? A: We maintain the highest security standards:

• SOC 2 Type II certified by independent auditors
• GDPR compliant with data residency options
• HIPAA compliant for healthcare applications
• PCI-DSS certified for payment-related communications
• ISO 27001 information security management
• Regular penetration testing by third-party security firms

Q: How is our data protected and where is it stored? A: Data protection is our top priority:

• End-to-end encryption for all communications
• Zero-knowledge architecture - we cannot access your content
• Regional data storage options for compliance requirements
• Automatic data retention policies with customizable periods
• Encryption at rest using AES-256 standards
• In-transit encryption using TLS 1.3

Q: Can we control where our data is processed and stored? A: Yes, we offer flexible data residency options:

• Single region deployment for strict compliance requirements
• Multi-region replication for performance and redundancy
• On-premises deployment for maximum control (enterprise only)
• Hybrid cloud options combining cloud efficiency with local control
• Data sovereignty compliance with local regulations

💰 Pricing & Business Questions

Q: How does pay-per-use pricing work? A: Our transparent pricing model charges only for actual usage:

• Per-minute billing for video/voice calls
• Per-participant calculation for fair multi-user pricing
• Volume discounts automatically applied as usage increases
• Predictable costs with usage monitoring and alerts
• No seat licenses - pay only for active communication time
• Real-time billing dashboard showing current usage and costs

Q: What's included in the free tier? A: Our free tier includes:

• 100 minutes monthly of video/voice calling
• Unlimited development in sandbox environment
• Full API access with reasonable rate limits
• Community support via Discord and forums
• Basic analytics and usage monitoring
• No credit card required for signup

Q: How do you compare to competitors on cost? A: Samvyo typically costs 40-60% less than traditional solutions:

• Zoom/Teams: $15-25 per user monthly vs. our usage-based model
• Custom development: $50K-200K+ vs. hours of integration
• Contact center solutions: $100-300 per agent monthly vs. our per-minute pricing
• Enterprise savings: Often exceed $100K annually for medium-sized businesses

🚀 Platform & Features Questions

Q: What makes Samvyo different from Zoom, Teams, or Google Meet? A: Samvyo offers unique advantages:

• Unified platform combining meetings, support, and integration APIs
• AI-first design with built-in intelligence across all features
• Unlimited customization including core media processing
• Pay-per-use pricing vs. expensive per-seat licensing
• Developer-friendly with comprehensive SDKs and APIs
• Business intelligence providing insights from all communications

Q: Can Samvyo replace our current contact center solution? A: Yes, Samvyo Meetnow is designed as a complete contact center replacement:

• QR code calling eliminates phone trees and wait times
• AI-powered routing matches customers to optimal agents
• Video-first support resolves issues faster than voice-only
• Integrated analytics providing comprehensive performance insights
• CRM synchronization maintaining complete customer context
• 60% lower costs compared to traditional contact center platforms

Q: How does the AI functionality work? A: Our AI operates across multiple dimensions:

• Real-time transcription with context understanding
• Sentiment analysis tracking emotional state throughout conversations
• Intent recognition predicting customer needs and agent responses
• Conversation intelligence extracting key insights and action items
• Predictive analytics forecasting trends and recommending actions
• Privacy-preserving - AI processes metadata, not sensitive content

Q: What support do you provide during implementation? A: We offer comprehensive implementation support:

• Dedicated success managers for business and enterprise customers
• Technical consulting for complex integrations
• Training programs for administrators and end users
• Migration assistance from existing platforms
• 24/7 priority support for enterprise customers
• Regular check-ins ensuring optimal platform utilization

🌍 Global & Accessibility Questions

Q: What regions and languages do you support? A: Samvyo provides global coverage:

• 40+ data centers across North America, Europe, Asia-Pacific
• 50+ languages for transcription and translation
• Regional compliance meeting local data protection requirements
• Multi-timezone support with appropriate routing
• Cultural customization adapting features for regional preferences

Q: How do you ensure accessibility for users with disabilities? A: Accessibility is built into our platform:

• WCAG 2.1 AA compliance for web interfaces
• Screen reader support with proper ARIA labeling
• Keyboard navigation for all functionality
• Closed captioning with real-time transcription
• High contrast modes and customizable text sizing
• Audio descriptions for visual elements when needed

Conclusion: Transform Your Communication Today

The future of business communication isn't about having more tools—it's about having intelligent, unified, and customizable communication that drives real business outcomes. Samvyo v3.0 represents a fundamental shift from fragmented communication tools to an integrated intelligence platform.

The Samvyo Advantage: Three Pillars of Success

🎯 Unified Intelligence: Unlike competitors who treat meetings, support, and integration as separate products, Samvyo provides unified intelligence across all communication touchpoints. This holistic approach enables insights and automation impossible with fragmented solutions.

⚡ Developer-First Innovation: Our comprehensive SDK suite and API-first architecture enable integration in hours, not months. Whether you're building a simple video chat or a complex multi-tenant platform, Samvyo provides the tools for rapid development and infinite customization.

🤖 AI-Powered Insights: Built-in artificial intelligence transforms every conversation into actionable business intelligence. From predicting customer churn to optimizing team performance, Samvyo's AI provides the insights modern businesses need to stay competitive.

Ready to Transform Your Communication?

For Developers: Start building with our free tier and comprehensive SDKs. Join our developer community and see why thousands of developers choose Samvyo for real-time communication integration.

For Businesses: Replace fragmented communication tools with Samvyo's unified platform. Reduce costs, improve customer experience, and gain unprecedented insights into your communication effectiveness.

For Enterprises: Partner with us to transform your organization's communication infrastructure. Our enterprise team provides white-glove service ensuring successful deployment and ongoing optimization.

Take Action Today

🚀 Start Free: Get your API keys and begin building in minutes
📞 Schedule Demo: Book a personalized demonstration with our team
💼 Enterprise Inquiry: Contact our enterprise team for custom solutions
📖 Explore Documentation: Dive deep into our APIs and capabilities

The communication revolution starts now. Join thousands of developers and hundreds of businesses who have chosen Samvyo as their communication platform.

Transform your communication. Transform your business. Transform your future.

About Samvyo Technologies

Samvyo Technologies is a leading provider of real-time communication solutions, serving developers, businesses, and enterprises worldwide. Founded by veterans of the telecommunications and software industry, we combine a decade of enterprise experience with startup innovation to deliver the future of intelligent communication.

Contact Information:

• Website: https://www.samvyo.com
• Documentation: https://docs.samvyo.com
• Developer Community: https://discord.gg/samvyo
• Enterprise Sales: enterprise@samvyo.com
• Technical Support: support@samvyo.com

Follow Us:

• LinkedIn: @samvyo-technologies
• Twitter: @SamvyoTech
• GitHub: @samvyo
• YouTube: Samvyo Technologies

As urban landscapes continue to evolve with the rise of high-rise buildings, elevators have become an essential part of modern infrastructure. With millions relying on these systems daily, ensuring passenger safety has never been more critical. This white paper delves into the evolution of safety elevators, the current market landscape, and how WebRTC technology is revolutionizing safety standards through real-time, two-way video communication.

The Evolution of Safety Elevators

The invention of the safety elevator transformed urban architecture, making skyscrapers and high-rise buildings feasible. In 1852, Elisha Otis introduced the first safety elevator, incorporating a fail-safe brake mechanism that prevented free-fall in case of a rope failure. Since then, elevators have become an indispensable part of city life, evolving from manually operated systems to highly automated units with advanced safety features.

The Rising Importance of Elevator Safety

As cities continue to expand vertically, the global demand for safety elevators is accelerating. Market research indicates that the elevator industry will reach $135 billion by 2030, driven by increased construction of high-rise structures and stricter safety regulations. In this rapidly urbanizing world, ensuring passenger safety in emergency situations is a top priority for manufacturers and regulatory bodies alike.

Rethinking Elevator Safety: The Need for Two-Way Video Communication

While traditional safety measures such as alarms and emergency stop buttons have been effective, they often fail to address real-time emergencies like medical crises or mechanical failures. Two-way video calling systems offer a game-changing solution, allowing direct communication between passengers and emergency responders. This technology closes crucial gaps in emergency response by providing live visual and audio information, enabling faster and more effective rescue operations.

Existing Emergency Response Systems in Elevators

Most modern elevators are equipped with:

• Emergency intercoms for voice communication
• Alarm buttons to alert building security
• Automatic emergency braking systems to prevent mechanical failures

However, these traditional systems lack real-time visual data, which is essential for making quick, informed decisions in complex emergency scenarios.

WebRTC: Elevating Safety Through Real-Time Video Communication

WebRTC (Web Real-Time Communication) introduces a breakthrough in elevator safety by enabling high-quality, low-latency video and audio calls between passengers and rescue teams. Key benefits include:

✅ Enhanced Situational Awareness – Live video feeds provide real-time insights into emergency situations.
✅ Faster Emergency Response – Rescue teams can assess incidents instantly and react accordingly.
✅ Increased Passenger Confidence – Clear visual communication reduces panic and reassures passengers.

Unlike traditional systems, WebRTC-based solutions function efficiently without relying on centralized servers, ensuring seamless performance even in challenging network environments.

Challenges in Hardware Integration

Deploying WebRTC-powered video calling in elevator systems presents unique challenges:

🔹 Limited Processing Power: Elevator control units typically run lightweight Linux-based OS with minimal CPU resources.
🔹 No Browser Environment: Many systems lack built-in web browsers required for running WebRTC applications.
🔹 Hardware Limitations: Restricted support for real-time video and audio processing, leading to potential performance bottlenecks.

Developing a Native WebRTC Solution for Elevators

To overcome these hurdles, Samvyo engineered an optimized WebRTC solution tailored for elevator hardware:

✔ Custom WebRTC Build: Compiled WebRTC libraries optimized for embedded hardware.
✔ C++ Application: Built using RTC peer connection for establishing seamless video calls.
✔ Media Capture: Developed browser-equivalent getUserMedia functionality for accessing cameras and microphones.
✔ Efficient Rendering: Leveraged GStreamer and libgtk for optimized video/audio processing.
✔ Hardware Acceleration: Utilized available GPU resources to reduce CPU load.
✔ Multithreading: Distributed workloads across multiple threads to maintain smooth, uninterrupted communication.

Beyond Elevators: Expanding WebRTC Applications

The same WebRTC-based solutions are transforming workflows across various industries:

🏭 Industry 4.0: Real-time video monitoring in manufacturing processes.
🚗 Automotive Sector: Video telematics for driver assistance and remote diagnostics.
⛏ Industrial Safety: Enhanced emergency communication in mines, oil rigs, and remote construction sites.

Case Study: Transforming Emergency Response for a Leading Elevator Manufacturer

Recently, Samvyo partnered with one of the world’s top elevator manufacturers to develop an advanced emergency response system powered by WebRTC. By following the principles outlined above, we successfully implemented a two-way video calling system that:

🔹 Operates efficiently on low-powered hardware – The solution was optimized for a 900MHz dual-core NXP i.MX6 processor, responsible for running both the elevator’s core operating system and application layer. The target was to keep CPU usage below 70% while supporting a high-quality video call alongside other elevator processes. We achieved this with a CPU utilization of just 62% while running a smooth WebRTC-powered video call.

🔹 Delivers crystal-clear video and audio – Extensive testing revealed that a 320x240 resolution at 10fps strikes the perfect balance between video clarity and CPU efficiency, ensuring optimal two-way communication while maintaining system performance.

🔹 Meets stringent safety and compliance standards – The solution underwent rigorous testing under real-world conditions to proactively identify and resolve any potential issues before deployment.

This WebRTC-powered innovation significantly improved emergency response times, enhancing passenger safety across multiple high-rise installations.

WebRTC and Elevator Safety: A New Standard

As the demand for real-time safety communication continues to grow, Samvyo’s customizable WebRTC-based solutions are setting new benchmarks in emergency response. Whether in elevators, industrial settings, or the automotive sector, our technology is designed to adapt and excel across diverse environments.

If your organisation is looking to implement enterprise-grade real-time audio/video solutions with seamless hardware integration, we can help.

📩 Get in Touch: Schedule a free 30-minute strategy session with us to discuss your specific needs and discover the best approach for integrating WebRTC into your critical business workflows. Reach out to us at hello@samvyo.com or visit our [services page] for more details.

Looking to speed up your development process? Explore the Samvyo Video API/SDK – deploy a ready-to-use backend for global operations in less than a week!

A product team can keep its calling interface, preserve its customer workflows and still face a different bill after an infrastructure retirement. The reason is that the cost may move from an ACS consumption meter to a Teams-aligned licensing model, while the people using the product are customers your company does not control.

That is the important qualification in the title. Staying on an ACS Calling path does not automatically mean buying one Teams licence for every person who joins a call. The applicable model depends on how the workload identifies users, whether they participate as Teams users or external meeting participants, which Teams-aligned service is involved and which Microsoft terms apply.

The commercial decision is therefore straightforward: first classify the calling scenario, then compare its unavoidable licence and usage meters. A per-minute ACS price can look inexpensive until the required identity or Teams product changes who carries the cost.

Start with the retirement boundary

Microsoft’s Azure Communication Services retirement and breaking-changes guide, checked on October 29, 2026, gives September 30, 2028 as the retirement date for the affected standalone services. Microsoft defines retirement as permanent removal from Azure; after retirement, a retired service is unsupported and cannot be used.

That date matters because it prevents a misleading comparison. You cannot evaluate a future Teams-aligned path by looking only at today’s ACS usage charge. You need to establish which part of your implementation remains available, which product or service it must align with and whether that alignment introduces a separate licensing requirement.

For a white-labelled product, this classification is more consequential than it is for an internal company application. An internal deployment can usually identify its users, assign the relevant licences and pass the cost to one operating budget. A product sold to other organisations has a different boundary: its users belong to customers, may have different identities and may join through different meeting or calling paths.

That brings the analysis to the meter you can verify today.

The ACS usage meter is clear

Microsoft’s Teams interop pricing page lists ACS consumption for a Teams user participating through ACS APIs or SDKs at $0.004 per user minute. The unit is a user minute, so the charge follows the participating user minutes recorded through that ACS path.

The same pricing material shows native Teams-client participation at $0 per minute because that participation is covered by the applicable Teams licence. Those are different billing situations. One is an ACS consumption charge for a user participating through ACS APIs or SDKs; the other is participation through the Teams client under its applicable licence.

Microsoft’s Calling and Chat pricing page also lists an ACS over-IP calling rate of $0.004 per user minute for VoIP calling and video or audio participant legs. The page notes that a total bill can contain other meters, including recording, PSTN, direct routing, chat and storage.

The useful conclusion is limited but important. ACS gives you a visible variable charge for the ACS portion of the call. It does not tell you the total cost of a future Teams-aligned architecture, because the future model may add a licence, change the user identity model or introduce other service charges.

Before comparing totals, separate those units instead of treating them as interchangeable.

Three user models produce three different cost questions

The first model is an ACS application serving users through ACS APIs or SDKs. In that case, the directly documented consumption input is the ACS user-minute rate. Your forecast needs the number of participating user minutes, the call types that use ACS and any additional meters attached to the workload.

The second model is a Teams-aligned application in which participants are Teams users. Here, the question is whether each relevant user has the required Teams identity and licence for the specific product configuration. The answer cannot be inferred from the ACS rate alone. It must be confirmed against the applicable Microsoft product terms and the exact calling scenario.

The third model is a Teams-meeting arrangement in which people join as external participants. This can avoid additional Teams licences for those external participants, depending on the meeting and integration model. It also changes the product. Your application may have less control over identity, meeting policy, user experience and calling features than it had when the product owned the interaction through ACS.

These models are not interchangeable ways to buy the same thing. A lower apparent licence burden can come with a narrower integration surface, while a richer application experience can place more responsibility on the product owner to resolve identity, licensing and usage costs.

The third-party product problem

For a product sold to third parties, the hard question is who is expected to hold the licence. If the Teams-aligned scenario requires licensed Teams users, the product owner must determine whether those users are its own employees, the customer’s employees or people invited into a customer-controlled meeting.

That distinction changes the feasibility of the model. A company can budget for licences assigned to its staff. It has a much harder commercial and operational problem when every customer organisation must provide appropriately licensed users, or when the product owner is expected to account for users it does not administer.

Do not turn that problem into a universal rule. Some external-participant models may avoid additional Teams licences for those participants. They may also fail to provide the same product capabilities as a Teams-user or ACS SDK integration. The buyer needs Microsoft to confirm the permitted identity and licensing arrangement for the exact flow before treating the model as a migration plan.

This is why “the Teams licence costs less than the ACS minutes” is an incomplete conclusion. The licence may attach to a different population, and the product may have to change to qualify for that treatment.

Why the $0.004 rate is useful but insufficient

The verified $0.004 rate gives you a starting point for the variable side of the comparison. For example, a call with 10 participating user minutes would produce a $0.04 ACS consumption charge before any other applicable meter. That calculation uses only the published per-user-minute rate and the stated 10-minute workload assumption.

It does not establish a break-even point against a Teams plan. A break-even calculation requires a readable, current price for the applicable Teams product, the licence population, the billing period and the exact relationship between that licence and the calling workload. Those inputs vary by scenario, and a single Teams price would misrepresent the decision.

Once those inputs are confirmed, the method in the usage-based versus flat licensing crossover analysis applies directly.

The practical comparison should therefore be built as a model rather than a headline number:

Use the table for a workload-specific forecast. Record the user population, identity path, participant type, minutes and additional services separately. Then ask Microsoft to confirm which product terms apply to that exact configuration.

What a buyer should verify before staying

Ask five questions before treating the existing ACS Calling implementation as the low-risk option.

1. Which service supports this workload after the retirement boundary? Record the Microsoft product name and the dated documentation that covers your particular API, SDK and participant flow.
2. Who is a licensed user in this design? Separate your employees, your customer’s employees, Teams users and external meeting participants.
3. What happens when a customer has no suitable Teams licence? Confirm whether the user can join through an external-participant path and which application capabilities would change.
4. Which costs remain usage-based? Apply the ACS user-minute rate where it still applies, then add the documented rates for recording, PSTN, direct routing, chat, storage or other services in scope.
5. Who owns the commercial obligation? Put the answer in the contract and operating model. A technically valid flow can still be unsuitable if the product owner cannot administer or recover the required licensing cost.

Microsoft may revise retirement and product documentation before September 30, 2028, so recheck the guide and the applicable pricing and licensing pages before committing to the path. Base the decision on the current documented scenario, and treat continuity of the existing ACS user experience and billing model as something to verify.

Bottom Line

Staying on an ACS Calling path does not automatically create a Teams licence obligation for every caller. The cost depends on whether the workload uses ACS consumption, licensed Teams identities or an external-participant meeting model, and those choices affect the product experience as well as the bill.

For a third-party white-labelled product, the safest recommendation is to model the user and identity path before comparing prices. Use the documented ACS rate of $0.004 per user minute as one input, obtain written confirmation of the applicable Teams licensing scenario and reject any forecast that assigns one unverified seat price to every customer user.

What's Next

Cost is only one part of the replacement decision. The companion guide, Choosing an ACS Replacement: What to Check Before You Commit Again, turns the retirement into a broader evaluation of roadmap durability, deployment control and the ability to leave later.

Read it after you have mapped your current users, identities and billing meters, because those details determine which replacement options are genuinely comparable.

FAQs

Does staying on ACS Calling always require a Teams licence for every user?

No. Licensing depends on the Teams-aligned scenario, the identity model and whether people participate as Teams users or external meeting participants. Confirm the exact configuration and applicable Microsoft terms before assigning a licence obligation to every caller.

What is the ACS price for a Teams user participating through an ACS SDK?

Microsoft lists ACS consumption for a Teams user participating through ACS APIs or SDKs at $0.004 per user minute. The rate applies to that ACS consumption path and does not represent the total cost of every Teams-aligned design.

Can external participants avoid additional Teams licences?

Some Teams-meeting integration models allow external participants to join without additional Teams licences for those participants. That model can have different identity, control and feature constraints, so it should be evaluated as a different product flow rather than treated as a like-for-like replacement.

Can I calculate the break-even point between ACS minutes and Teams licences?

Only after you have a verified price for the applicable Teams product, the licence population and the relevant billing terms. The $0.004 ACS rate alone is insufficient to produce a valid break-even point.

What else can appear on an ACS calling bill?

Microsoft’s Calling pricing documentation identifies additional possible meters, including recording, PSTN, direct routing, chat and storage. Forecast each applicable service separately instead of treating the user-minute rate as the complete bill.

When should a company recheck the ACS retirement information?

Recheck Microsoft’s retirement and breaking-changes guide before committing to a migration or long-term licensing model. The guide currently gives September 30, 2028 as the retirement date for the affected services, and product documentation can change before that date.

A team can still be running Azure Communication Services today and discover that its next product decision has already been made for it. Microsoft’s guide says the standalone Azure Communication Services offering retires on September 30, 2028. That date does not describe one uniform migration to Teams. Microsoft has separated ACS capabilities into services that retire, services that continue only in supported Teams-aligned scenarios, and integrated solutions or alternative destinations that follow their own path.

The practical recommendation is to inventory your ACS dependencies by service and classify each one before choosing a replacement. A product using ACS Rooms or the Web UI Library has a different problem from a calling application that can operate through Teams interoperability. A business using ACS Email, SMS, WhatsApp, or Job Router may be looking at a different destination altogether. Treating every workload as a Teams migration creates the wrong project plan.

What Microsoft is actually retiring

Microsoft defines retirement as permanent removal from Azure. Once the retirement date arrives, the affected service, feature, model, or SDK will no longer be available or supported under ACS. The authoritative ACS retirement and breaking-changes guide identifies the following services and SDKs as retired:

• ACS Email
• ACS SMS
• ACS Advanced Messaging with WhatsApp
• ACS Chat
• ACS Chat for Teams Meeting Interop
• ACS Rooms
• ACS Number Management (Direct Offer)
• ACS Direct Routing
• ACS Job Router
• ACS Web UI Library SDK
• ACS Mobile UI Library SDK

These entries belong to the retirement category. Microsoft’s guide points to different destinations depending on the workload. Email customers are directed toward options including Microsoft 365 High Volume Email, Exchange Online, and Marketplace partners. Job Router guidance points toward Dynamics 365 Contact Center and named partners. Direct Routing and number-management workloads have Teams and telephony destinations. Those recommendations describe possible paths for individual services; they do not turn the ACS portfolio into a single Teams product.

The distinction matters for planning. An application that uses several ACS services may have several migration tracks, each with a different identity model, API surface, operational owner, and commercial structure. ACS Chat also has separate Microsoft guidance stating that Graph Chat is not a drop-in replacement and brings Teams identities, licensing, tenant policies, and governance into the design. The replacement question therefore starts with the service your application actually uses.

What continues, with a new condition

Microsoft classifies several capabilities as affected by breaking changes rather than as outright retirements. Those services remain available after the retirement date, but continued support requires use with a supported Teams-aligned service. Microsoft specifically lists Teams Phone Extensibility, Microsoft Teams Meeting Interoperability, and Microsoft Teams Click-2-Call for Teams Voice Apps as the relevant Teams-aligned services in its guide.

The affected ACS capabilities include:

• Voice and Video Calling SDK
• Call Recording
• Closed Captions
• Call Automation

The Calling SDK illustrates the boundary. Microsoft says existing calling workloads continue through September 30, 2028, while support after that date requires a supported Teams-aligned scenario. The migration table identifies Teams Meeting Interoperability and says an applicable Teams licence is required. That preserves a supported route for some calling applications, while changing the environment in which those applications operate.

Recording, captions, and automation have their own eligibility conditions. A Teams-aligned integration does not establish feature parity for every ACS capability. Microsoft says recording remains supported only for documented eligible Teams scenarios, captions depend on SDK capabilities and meeting or calling policies, and Call Automation continues after the retirement date only for capabilities documented for eligible Teams scenarios. Each workload needs a feature-level check before anyone treats the Calling SDK as a complete continuation.

Microsoft also warns that supported services may introduce additional service costs, licensing costs, or both. The guide gives no universal per-user amount. That cost question deserves its own model because a Teams-aligned route can change who must be licensed and how the application is sold.

What remains supported as an integrated solution

Microsoft identifies supported integrated scenarios including Microsoft Teams interoperability, Teams Phone, Teams Phone Extensibility, and Microsoft Foundry Speech. This is the third part of the status map. These references describe supported Microsoft solutions and integrations; they are not a blanket statement that every ACS capability outside the retirement list remains unchanged.

That qualification is important for teams that depend on a surrounding ACS component. A calling workload may have a supported Teams route while its existing UI layer is separately listed for retirement. A speech workflow may remain associated with a supported integrated solution while another communications service in the same product follows a different destination. Read the service entry and the supported-scenario entry together.

The safest interpretation is therefore service-specific:

The table classifies each dependency; every retired one still needs its own migration plan. ACS Rooms, for example, is retired, and Microsoft has separately stated that it has no migration path to Teams meetings.

The dates that affect your project

The final retirement date is September 30, 2028. Microsoft says existing ACS resources remain available from the September 2026 notification through that date, subject to the restrictions and support limits described in the guide. Availability during the transition does not mean that retiring services will receive new features or normal product investment.

The earlier operational date is October 23, 2026. Beginning then, Microsoft says it will limit onboarding to and expansion of retiring ACS services. Customers without an ACS resource created before that date will not be able to acquire phone numbers for retiring telephony workloads, including PSTN calling and SMS. Microsoft also says that additional measures limiting expansion of other retiring services may be introduced after the date.

Existing customers should therefore separate three questions. Can the current resource continue operating during the transition? Can the team add new numbers, users, or workload capacity? Will the same architecture remain supported after September 30, 2028? A “yes” to the first question does not answer the other two.

For teams starting a new project, the onboarding restriction is the immediate constraint. For teams with an existing resource, the retirement date is the architectural deadline. Both dates belong in the delivery plan, even when the current application appears stable.

What the retirement costs you

The cost is determined by the dependency you carry forward. A service that retires outright creates replacement work. A capability that continues through a Teams-aligned scenario can add licensing or service charges. A workload directed to Dynamics 365, Microsoft 365, Microsoft Foundry, or a Marketplace partner may move into a different commercial and operational model.

Microsoft’s guide explicitly warns that customers may incur additional service costs, licensing costs, or both. It does not publish a universal per-user price for the surviving ACS scenarios, so this article does not attach a dollar amount to staying supported. The correct calculation needs the actual Teams-aligned scenario, the people or identities covered by it, the service meters involved, and the way your product is delivered to its users.

The economic decision is especially different for an internal application and a product sold to third parties. An internal team can evaluate the licensing model against its own workforce and tenant policies. A software company must also determine whether the required licensing model fits a product whose end users belong to customer organisations. That distinction can change the apparent cost of retaining the Calling SDK, even before engineering work is priced.

The detailed economics belong in the companion analysis of enterprise video pricing and the Teams licensing analysis. The reference decision here is simpler. Do not assume that keeping an ACS API means keeping the same bill.

How to classify your ACS dependency

1. List every ACS service and SDK in production. Include communication features that are hidden behind an internal wrapper or shared component. The Web and Mobile UI Library SDKs, for example, may be doing work that product teams do not count as a separate dependency.
2. Assign each dependency to Microsoft’s status category. Mark it as retired, breaking-change affected, or part of a supported integrated solution. Do not infer the category from the product’s marketing name.
3. Record the required destination. A service may point toward Teams, Dynamics 365, Microsoft 365, Microsoft Foundry, a telephony route, or a Marketplace partner. Capture the specific destination named for that workload.
4. Test the product boundary. Check identity, tenant policy, permissions, SDK support, recording or caption behaviour, call state, and administration. A supported destination can still require product changes.
5. Model the commercial change. Include new licensing and service costs where Microsoft says they may apply. Use the actual scenario rather than a generic Teams price.
6. Set the delivery order around the dates. Treat October 23, 2026 as the onboarding and expansion checkpoint for retiring services, and September 30, 2028 as the end of availability for the retired category.

If the inventory contains Rooms or either UI Library SDK, the work is a rebuild of that dependency and deserves its own technical plan. If it contains the Calling SDK, the work begins with Teams-scenario eligibility and licensing. If it contains Email, SMS, WhatsApp, Chat, Job Router, Direct Routing, or Number Management, follow the destination Microsoft documents for that service rather than assuming a common Teams migration.

Bottom Line

Azure Communication Services is retiring as a standalone offering on September 30, 2028. The outcome varies by dependency: some services disappear, some continue only through supported Teams-aligned scenarios, and some workloads have destinations in Microsoft 365, Dynamics 365, Microsoft Foundry, telephony products, or the partner marketplace.

Start with a service-by-service inventory and price the route that Microsoft actually supports. The October 23, 2026 onboarding restriction makes that work an active planning task for new and expanding workloads.

What's Next

Rooms is one of the clearest examples of why the status map needs to be read service by service. The ACS Rooms analysis explains what Microsoft’s lack-of-migration-path statement means for a product built on Rooms.

For the broader engineering question of what changes when a communications dependency moves, see the guide to provider acquisition and shutdown risk.

FAQs

Is Azure Communication Services shutting down completely?

Microsoft is retiring ACS as a standalone offering on September 30, 2028. Some services are retired outright, while some capabilities continue only when used with supported Teams-aligned services or other documented integrated solutions.

What Azure Communication Services products are being retired?

Microsoft lists ACS Email, SMS, Advanced Messaging with WhatsApp, Chat, Chat for Teams Meeting Interop, Rooms, Number Management Direct Offer, Direct Routing, Job Router, and the Web and Mobile UI Library SDKs for retirement. They are scheduled to become unavailable after September 30, 2028 under Microsoft’s retirement guide.

Does the ACS Calling SDK survive?

The Voice and Video Calling SDK is classified as a breaking change rather than an outright retirement. Existing workloads continue through September 30, 2028, while continued support after that requires a supported Teams-aligned scenario and an applicable Teams licence.

What happens to ACS Call Recording and captions?

Call Recording and closed captions continue only in eligible, documented Teams scenarios after the retirement date. Microsoft says eligibility does not guarantee feature parity, and captions also depend on SDK capabilities, licensing, and meeting or calling policies.

Can a new customer still start using retiring ACS services?

Microsoft says it will begin limiting onboarding and expansion of retiring services on October 23, 2026. Customers without an ACS resource created before that date cannot acquire phone numbers for retiring telephony workloads such as PSTN calling and SMS, and Microsoft may introduce further restrictions on expansion.

Will staying on ACS cost more after the retirement announcement?

It may. Microsoft warns that supported services can involve additional service costs, licensing costs, or both, but its retirement guide does not provide a universal per-user amount. The cost depends on the Teams-aligned scenario or alternative destination, the users and identities involved, and the services your application continues to consume.

Is every ACS workload moving to Microsoft Teams?

No single Teams mapping covers the ACS portfolio. Microsoft documents Teams-aligned continuation for selected capabilities, while other workloads point toward Microsoft 365, Dynamics 365, Microsoft Foundry, telephony products, or Marketplace partners.

Microsoft’s wording leaves little room for a “lift and shift” interpretation: “ACS Rooms and Teams meetings through the Microsoft Graph API offer similar functionality, but exist in two different environments and don't offer a migration path.”

That sentence changes the engineering plan. A product built around ACS Rooms should not treat Teams meetings or Graph online meetings as a replacement endpoint that accepts the same room IDs, participants, roles, and schedules. The practical task is to identify the Rooms control plane your product depends on, choose a target environment, and redesign that layer against the target’s identity, authorization, meeting, and lifecycle model.

Microsoft lists Teams Meeting interoperability and Microsoft Graph APIs as possible alternatives, but it does not describe either as a Rooms conversion process. The recommendation is therefore straightforward: start a bounded redesign of the Rooms-dependent control plane before the retirement deadline, and validate every assumed mapping instead of promising automatic continuity.

What ACS Rooms gave your application

ACS Rooms was more than a container around a video call. It provided a server-side model for structured meetings: your application could create and manage rooms, control who belonged to them, assign participant roles, apply schedules, and set room-level security limits.

Microsoft’s Rooms API documentation describes the model directly. The documented control-plane operations include:

• Creating, retrieving, updating, listing, and deleting Virtual Rooms.
• Adding, updating, and removing users from a room.
• Assigning and updating predefined participant roles.
• Setting and updating a room’s schedule.
• Applying security limits, including restrictions on PSTN dial-out.

Those operations are the part of the product that needs the closest attention. They are separate from the client media experience and separate from the visual call interface. The Calling SDK and the Web and Mobile UI Library are separate dependencies with their own retirement terms.

The Rooms object model is part of your product

A Rooms-based application normally has its own records and workflows around the Microsoft resource. Microsoft’s Rooms quickstart says that, because rooms are server-side entities, developers should track and persist the roomId in their chosen storage medium. That guidance is documented in the ACS Rooms creation quickstart.

That persisted identifier may appear in more places than the API call that created it. It can be associated with a customer, a scheduled session, a participant list, an access policy, an audit record, or an application-specific workflow. The retirement guide does not say that an existing Rooms identifier can be imported into a Graph online meeting. Treat that relationship as application data that needs a deliberate migration or replacement plan.

The same principle applies to participant identity. The Rooms quickstart states that ACS Communication Services Rooms currently support a participant of type CommunicationUserIdentifier; other Communication Identity types cause a runtime error. A move into the Teams and Graph environment introduces a different identity and authorization context. Existing participant records may still be useful to your application, but their meaning and authorization in the target system must be re-established.

Roles and schedules do not carry across automatically

The four predefined participant roles in ACS Rooms are Presenter, Collaborator, Attendee, and Consumer. They are documented in the Rooms API reference. These names should not be treated as a portable permission contract.

Microsoft documents Teams and Graph meetings through a different set of APIs and permissions. The retirement guide does not provide a one-to-one table that maps each ACS Rooms role to a Teams meeting role. The safe engineering assumption is that role intent must be re-evaluated in the target environment. For example, your product may use “Presenter” as a business permission, while the target meeting system may express the relevant capability through meeting options, participant policy, tenant settings, or a different role model.

Schedules require the same treatment. ACS Rooms lets an application set or update a room’s schedule with validFrom and validUntil values. Those fields describe the validity window of the Virtual Room. They are not evidence that the same values can be transferred into a Graph meeting resource with identical behavior.

Before choosing a target, document what each schedule field means in your product. A validity window may control when participants can use a room, when your application shows it as active, or when a server-side policy applies. Those are application decisions. The target API must be tested against each one rather than selected because its terminology appears similar.

Why Teams interoperability is not a Rooms migration

ACS Rooms does not directly interoperate with Microsoft Teams. Microsoft marks Teams interoperability as unsupported in the Rooms API documentation. The retirement guide points workloads toward Teams Meeting interoperability and Teams-native meeting creation and management APIs depending on their requirements.

That recommendation identifies possible destinations. It does not establish feature parity, preserve Rooms state, or create a conversion procedure.

Microsoft’s wording matters here because it explicitly separates the two environments. The relevant systems may support overlapping meeting scenarios, but they do not expose the same operating model. A product that currently controls a Virtual Room through ACS APIs cannot assume that sending the same room record to a Teams or Graph endpoint will produce an equivalent meeting.

The broad provider-change questions are covered in the general inventory of what changes when you move video providers. For ACS Rooms, narrow that inventory to the control plane: resource identity, participant state, roles, schedule rules, authorization, and the server-side controls your product actually uses.

Graph online meetings are a different operating environment

Microsoft Graph can create or join online meetings and return meeting coordinates. Participants can join through a joinWebURL or through the create-call API, according to Microsoft’s online meetings documentation. That gives a product a way to work with online meetings, but it does not make Graph a Rooms-compatible API.

The authorization model is one visible difference. For an application to call POST /users/{userId}/onlineMeetings, Microsoft requires an application access policy granted by a tenant administrator. The API creates the meeting on behalf of a user. The requirement is described in Microsoft’s Create onlineMeeting API reference.

That changes the questions your product must answer. Which tenant authorizes the application? Which user is the meeting organizer? How are permissions granted and revoked? What happens when the organizer changes? Which part of the experience belongs to your application, and which part is governed by Teams and tenant policy?

Graph also has behavior that product teams must account for explicitly. Microsoft states that a meeting created through the online-meeting API is a standalone meeting and is not associated with an event on the user’s calendar. It therefore does not appear on that calendar unless the application uses a calendar API as well. A Rooms product that presents scheduled sessions inside its own interface cannot assume that creating a Graph meeting will reproduce the same calendar or scheduling behavior.

What the redesign should inventory

Microsoft does not publish a checklist of what a Rooms-based product must change, so bound the inventory by the Rooms capabilities your product actually uses.

Room creation and persistence

Find every place where your application creates, stores, retrieves, updates, lists, or deletes a Rooms resource. Record whether the stored roomId is exposed to customers, embedded in URLs, used in webhooks, or joined to business records. Then decide whether the target system needs a new identifier, a translated internal identifier, or an application-owned session record that sits above the target meeting.

Participant and identity handling

Document how your application creates a Communication User, adds that user to a room, removes the user, and decides whether the user can join. Compare that behavior with the identity and authorization requirements of the selected Teams or Graph design. Existing customer and participant data may remain valuable, but portability of the data does not prove portability of its permissions.

Roles and policy

List the business actions attached to Presenter, Collaborator, Attendee, and Consumer in your application. Do not migrate the labels without testing their meaning. Re-express the underlying business rules in the target environment, where the available meeting roles, policies, and administrative controls may differ.

Validity and scheduling

Separate the Rooms validity window from the customer-facing schedule. Determine whether your product uses the window to permit joining, to show availability, to enforce a session boundary, or to trigger another workflow. Then test how those behaviors will be implemented around the target meeting resource.

Server-side controls

Record each control your application applies at room level, including restrictions such as PSTN dial-out. A target environment may offer a related policy, require tenant administration, or provide no equivalent control in the same API. The target decision is incomplete until each important control has a documented implementation or an accepted product change.

What to do before the retirement date

ACS Rooms will continue receiving security, compliance, and critical reliability updates during the retirement period, but Microsoft says that no new features or enhancements will be introduced. Microsoft defines retirement as permanent removal from Azure, and the guide gives the retirement date as September 30, 2028. After that date, retired services are not supported and cannot be used. Both points are stated in the ACS retirement and breaking changes guide.

That transition window is useful for discovery and validation. It is not a reason to defer the design. Start by capturing the Rooms contract your application relies on, then select the target scenario: Teams Meeting interoperability, Graph-based meeting creation, or another architecture that satisfies the product’s requirements. For each target, test identity, permissions, participant behavior, roles, schedules, meeting creation, and server-side controls with representative workflows.

Keep the existing Rooms path available while the replacement is being validated, subject to Microsoft’s published retirement terms. Do not describe the project internally as an API endpoint swap. The evidence supports a narrower and more accurate description: the Rooms control plane is moving between different environments, so the application must preserve the product behavior through a redesigned implementation.

Bottom Line

ACS Rooms is retired outright, and Microsoft explicitly says that Rooms and Teams meetings through Graph exist in different environments without a migration path. Teams interoperability and Graph APIs may be target environments, but neither should be treated as a direct import destination for Rooms resources.

The right first move is to inventory the Rooms control plane your product owns: room identity, participant state, roles, schedules, authorization, and server-side controls. Then validate a redesigned target implementation before the September 30, 2028 retirement date.

What’s Next

Once the Rooms dependency is clear, the next decision is broader than API compatibility. Choosing an ACS replacement looks at the durability and deployment questions to test before committing to another provider.

FAQs

Does ACS Rooms have a migration path to Microsoft Teams?

No. Microsoft states that ACS Rooms and Teams meetings through the Microsoft Graph API exist in different environments and do not offer a migration path. Teams Meeting interoperability and Graph APIs are alternatives to evaluate, and Microsoft documents no conversion from Rooms to either.

What happens to ACS Rooms after September 30, 2028?

Microsoft lists ACS Rooms as retired, with permanent removal from Azure on September 30, 2028. During the retirement period, Rooms receives security, compliance, and critical reliability updates, but Microsoft says no new features or enhancements will be introduced.

Can existing ACS room IDs be imported into Graph online meetings?

Microsoft does not publish a procedure stating that ACS room IDs can be imported into Graph online meetings. Treat the existing roomId as application data and define how it relates to a new target meeting or an application-owned session record.

Are ACS Rooms roles equivalent to Teams meeting roles?

No equivalence is established by Microsoft’s retirement guidance. ACS Rooms defines Presenter, Collaborator, Attendee, and Consumer, while Teams and Graph use a different API and permission environment, so the business meaning of each role must be re-evaluated.

Can Microsoft Graph create a Teams meeting for an application user?

Microsoft Graph can create online meetings on behalf of a user, but the application needs the relevant permissions and an application access policy granted by a tenant administrator. That authorization model is part of why Graph online meetings should be designed as a different environment rather than treated as a Rooms endpoint.

Will a Graph-created meeting automatically appear on the user’s calendar?

No. Microsoft says that a meeting created through the online-meeting API is a standalone meeting and is not associated with a calendar event. If your product needs calendar visibility, it must account for calendar integration separately.

What should a team built on ACS Rooms do first?

Start by documenting the Rooms operations and policies your product actually uses: room lifecycle, persisted identifiers, participants, roles, schedules, authorization, and server-side controls. Use that inventory to test a target design and to decide which product behavior remains unchanged, which must be redesigned, and which target capabilities are unavailable.

A prebuilt calling interface can disappear without taking the underlying media service with it. That is the position ACS customers now face: Microsoft's retirement guide lists the Azure Communication Services Web and Mobile UI Library SDKs among the retired services and SDKs, while the underlying Calling SDK remains a separate part of the ACS story.

The Microsoft retirement and breaking-changes guide says the ACS UI Library will no longer be available after September 30, 2028. The same guide names no replacement for the UI Library. That wording matters. It does not establish that no partner or third-party option exists; it tells you that Microsoft has not named a replacement in its current guidance.

The practical consequence is a product decision. Your application can continue using the existing library during the wind-down, or you can take ownership of the call interface before the support boundary arrives. The work is larger than changing a few buttons because the library sat between your product and the Calling SDK's device, participant, lifecycle, and accessibility details.

The trade-off between a prebuilt UI kit and a headless SDK, and what each costs later, is priced in the guide to embed video options. For ACS teams, the retirement makes the headless side of that trade-off compulsory.

What Microsoft is retiring

The retirement applies to the ACS UI Library for web and mobile. Microsoft's overview describes the library as a set of production-ready UI components that developers could add to their applications. The retirement guide separately lists the Web UI Library SDK and Mobile UI Library SDK under retired services and SDKs.

This is a UI-layer retirement. It does not mean that every ACS calling capability disappears on the same date. The Calling SDK and the UI Library are different layers, so a team can still use the Calling SDK as the media and call-control foundation while replacing the interface that presents those capabilities to users.

Existing UI Library workloads remain available during the transition period. Support is limited to stability, security, compliance, and critical problems that block normal usage. Microsoft does not plan new features, UI modernisation, or proactive dependency upgrades during that period, so the interface may continue to work while becoming increasingly difficult to evolve safely.

That support boundary turns the retirement date into an engineering deadline, rather than a date to discover a broken application.

What the UI Library was doing for your product

The easiest way to underestimate this migration is to think of the UI Library as visual decoration. Its documented mobile CallComposite included a pre-call experience for configuring default audio and video devices, followed by an end-to-end call experience with a defined layout and participant video. Those are product behaviours as well as presentation choices.

A custom replacement therefore needs to make deliberate decisions about at least four areas:

• Device setup: how people choose microphones, cameras, and speakers before joining, and what happens when permission is denied or a device cannot be read.
• Call presentation: how local and remote participants appear, how the layout changes as participants or media states change, and how speaker-related information is surfaced.
• Call state: how the product represents setup, waiting, joining, active calls, disconnection, call ending, and rejoining.
• Accessibility: how keyboard users, screen-reader users, users who zoom the interface, and users who rely on clear control labels operate the call.

This is the rebuild surface relevant to the retirement. It is not a complete inventory of every Web, iOS, and Android component or edge case that the UI Library may have supported.

First responsibility: devices and permissions

A custom call screen has to earn access to the user's devices before it can offer a reliable call experience. Microsoft's device and permission guidance explains that the Calling SDK requires browser and system permissions for audio and video devices. An application can use DeviceManager.askDevicePermission to trigger the permission prompt, and detailed device-list information also depends on permission.

That creates several states your UI must represent clearly:

• The user has granted microphone and camera access.
• The user has denied one or both permissions.
• The browser or operating system has blocked access.
• The application cannot show detailed device information yet.
• The selected device is unavailable when the call begins or changes during use.

The Calling SDK gives you the mechanism. Your product still has to provide the explanation, retry path, device controls, and failure state. A permission prompt alone is not a device experience.

Once devices are available, the next problem is deciding how people and media should occupy the call surface.

Second responsibility: layout and speaker state

The UI Library overview describes the mobile CallComposite as providing a clean layout and participant video. Rebuilding that experience means defining how the interface behaves as the call changes, rather than drawing a fixed grid and hoping it remains usable.

The Calling SDK exposes an isSpeaking boolean for remote participants. Microsoft's call-management documentation establishes the available speaker-state input, while the UI Library changelog records Speaker Mode and visual speaker-state behaviour in the video gallery. Your replacement must decide how that input affects presentation: whether the current speaker receives visual emphasis, how the local preview is handled, and what happens when several participants speak or nobody is speaking.

Those decisions should be explicit because the Calling SDK does not prescribe one universal active-speaker algorithm for every product. The SDK provides state; the application owns the presentation and the interaction model.

Third responsibility: lifecycle and reconnection states

A call interface is also a state machine. Microsoft's calling-widget tutorial models waiting, setup, and in-call states around the CallComposite. The UI Library changelog records additional behaviours involving disconnecting, call-ended, hold, and rejoining states.

A product-owned interface should make those states visible and actionable. At minimum, the user needs to understand whether the application is preparing to join, waiting for the call to begin, connected, attempting to recover, ending the call, or ready to rejoin. The exact screens depend on the product, but the responsibility does not disappear when the prebuilt component does.

Reconnection deserves particular care. A user who sees a frozen layout cannot tell whether the other participant stopped sending media, the network changed, or the application is recovering. The UI needs a coherent status message and a defined next action, even when the underlying SDK supplies only events and state changes.

Lifecycle handling is where a replacement stops being a visual exercise and becomes part of the product's reliability model.

Fourth responsibility: accessibility and localisation

Microsoft described the UI Library as being developed with usability, accessibility, and localisation in mind. The UI Library theming documentation and its associated changelog record work involving keyboard navigation, ARIA roles, screen-reader announcements, high-contrast borders, 400% zoom and reflow, and device-control labelling.

Those examples show the kind of engineering detail that a custom interface inherits. A replacement needs semantic controls, predictable focus movement, announcements for important state changes, usable contrast, layouts that survive zoom, and labels that make device controls understandable. It also needs a plan for translated labels and messages if the existing product serves more than one language.

The documentation supports accessibility as a responsibility, but it is not a complete WCAG conformance statement. Treat it as a rebuild workstream that requires testing with assistive technologies, rather than as a checklist that can be closed by copying the old visual design.

What to do during the transition

The recommended path is to build a product-owned UI against the Calling SDK and begin with an inventory of the behaviours your current product actually uses. Record the join flow, device setup, participant presentation, speaker treatment, call controls, lifecycle states, error messages, keyboard paths, screen-reader announcements, and localisation requirements. Then implement and test those responsibilities in that order.

A fork can provide continuity when the existing UI Library is close to the product you need. Microsoft says customers who need ongoing evolution or dependency modernisation can fork and maintain the library independently. That makes a fork a bridge for preserving a known interface; it also transfers dependency, compatibility, security, and maintenance responsibility to your team. It should not be treated as a Microsoft-supported replacement product.

The limit is equally important: rebuilding the interface does not remove the need to review the Calling SDK's own lifecycle, permissions, browser, mobile-platform, and release behaviour. The UI Library retirement changes who owns the presentation layer. It does not turn the Calling SDK into a complete application interface.

Bottom Line

Microsoft's current retirement guide names no replacement for the ACS UI Library, and the Web and Mobile SDKs are scheduled to leave availability after September 30, 2028. The durable response is to own the call UI and build it against the Calling SDK, with a fork used only when short-term continuity is more valuable than long-term control.

The work covers device permissions, layout and speaker state, lifecycle and recovery states, and accessibility. Starting with those responsibilities gives the migration a concrete shape before the support window narrows.

What's Next

Owning the UI answers how the product continues to function, but it does not answer whether the remaining ACS Calling path still fits the commercial model. The Teams licensing analysis works through what staying on the ACS Calling path actually costs.

FAQs

When will the ACS UI Library be retired?

The ACS Web and Mobile UI Library SDKs will no longer be available after September 30, 2028. Existing workloads remain available during the transition, with support focused on stability, security, compliance, and critical problems that block normal usage.

Does ACS UI Library retirement mean the Calling SDK is also retired?

No. Microsoft's retirement guide lists the UI Library SDKs separately from the underlying Calling SDK. A team can use the Calling SDK as the foundation for a product-owned interface, subject to the separate support and product decisions that apply to that SDK.

Does Microsoft provide a replacement for the ACS UI Library?

Microsoft's current retirement guide names no replacement for the Web and Mobile UI Library. That statement describes Microsoft's published guidance; it does not establish that no third-party or partner option exists.

What has to be rebuilt when the ACS UI Library retires?

The main responsibilities include device setup and permission handling, participant and speaker presentation, call lifecycle states, recovery and rejoining behaviour, and accessibility. The Calling SDK supplies relevant controls and state, while your application owns the screens, explanations, interaction rules, and testing.

Can an ACS customer fork the UI Library?

Yes, Microsoft says customers who need ongoing evolution or dependency modernisation can fork and maintain the library independently. A fork can preserve continuity, but your team then owns its dependencies, compatibility, security fixes, and future changes.

Is rebuilding the ACS UI Library a small frontend change?

It should be planned as a product workstream rather than a styling update. The documented device, layout, call-state, and accessibility responsibilities reach into permissions, asynchronous events, recovery states, assistive-technology behaviour, and platform-specific testing.

Your replacement decision changed the moment Microsoft announced that standalone Azure Communication Services will retire. The relevant question is no longer which API has the most attractive feature list. It is whether the next platform gives you enough roadmap clarity, portability, and deployment control to survive the next strategic change.

Microsoft announced the standalone ACS retirement on September 23, 2026, with the retirement taking effect on September 30, 2028, according to its retirement and breaking-changes guide. The guide separates services that will be permanently removed from services that remain available only in supported Teams-aligned scenarios. It also says that, after the retirement date, standalone ACS scenarios that do not integrate with Teams will no longer be supported.

That changes how you should evaluate an ACS alternative. The recommendation is to choose the platform that leaves your product with the clearest exit route, even when that means accepting fewer ready-made features today. Test every candidate against four questions: who controls the roadmap, how much notice the contract provides, what can move if the vendor changes direction, and which parts of the media system you can operate under your own control.

Start with the failure that brought you here

A provider exit is not only a migration exercise. It is a test of the assumptions you made when the product was first launched.

ACS gave many teams a convenient foundation for adding communications to an application. The difficult discovery comes later: the application may depend on the provider's room model, identity model, calling primitives, user interface, recording workflow, number management, or service-specific policy. When the provider retires the standalone product, those dependencies become part of the replacement decision.

Before reviewing vendors, write down the parts of the current product that users actually experience:

• How users join, authenticate, and receive permission to enter a call.
• How rooms, meetings, participants, tracks, devices, and call state are represented.
• How the product handles camera and microphone permissions, device changes, reconnection, active speaker state, and accessibility.
• Where media travels and where TURN, recording, processing, and storage run.
• Which functions are essential to the product and which were merely convenient additions from the original platform.

The inventory tells you what the replacement must preserve. It also exposes the components that should belong to your own application rather than being hidden inside another provider's product model. The switching-cost analysis is useful for working through that inventory before you compare platforms.

Roadmap durability comes before feature breadth

A platform can have a strong feature set and still be a poor foundation for a product that must remain stable for years. The ACS retirement demonstrates why: the service can remain available during a transition period while the original standalone operating model loses its long-term support boundary.

Microsoft describes the ACS transition as a two-year retirement period after the September 2026 announcement. During that period, existing ACS resources and current workloads remain supported under the stated terms, while Microsoft's focus is existing functionality and critical security and stability updates. The guide says Microsoft cannot commit to new feature development for services affected by the retirement.

Ask each candidate to explain four things in writing:

1. Which product and APIs are strategic for the provider.
2. Which capabilities are in maintenance mode, preview, or subject to a separate product direction.
3. How the provider announces breaking changes, product withdrawals, and ownership changes.
4. What happens to your application if a capability is retired without a feature-equivalent successor.

Do not treat a public roadmap as a guarantee. Treat it as evidence to compare with the contract, service terms, release history, and the provider's behaviour when products change direction. The key distinction is whether the platform's future is aligned with your product's future, rather than whether its current checklist is long.

Read the notice terms as an engineering requirement

Notice gives you time, but notice alone does not give you continuity.

Microsoft's Azure infrastructure lifecycle FAQ says the typical notice period for Azure infrastructure retirement is at least 12 months. It also explains that, after retirement, features may be removed, disabled, automatically migrated, or require manual action, and that service-level agreements may no longer apply. Microsoft describes that period as typical rather than a guaranteed minimum for every Azure service.

Other major cloud terms use their own conditions. The AWS Customer Agreement says AWS may provide at least 12 months' prior notice before discontinuing a material functionality of a generally available service that the customer is using, subject to stated exceptions. The Google Cloud Platform Terms of Service describes at least 12 months' notice before discontinuing a service or associated material functionality, unless an exception applies or a materially similar replacement is provided.

These provisions are useful reference points, but they do not promise feature parity or a migration that preserves your architecture. When you evaluate a replacement, ask the provider to identify the notice period, the exceptions, the treatment of data and recordings, the support available during the transition, and what happens to your application after the end date. Have legal and engineering review the same language. A notice clause that looks acceptable to procurement may still leave engineering with a rewrite.

Measure portability at the boundaries that matter

Portability is often discussed as though moving a video product means changing one SDK import. In practice, the difficult boundaries are the ones that connect the provider to the rest of your product.

Evaluate portability across these surfaces:

Then run a small exit exercise before signing. Model how you would create a room, issue access, establish a call, record it, retrieve the result, and close the session on a second platform. You are testing the seams between your product and the provider. A candidate that leaves those seams in your code gives you more control when the provider changes its terms.

This is also where the choice between an embedded interface, a UI kit, and a headless SDK matters. The video embed options guide explains why a faster initial integration can leave more product behaviour inside the provider's layer.

Deployment control reduces dependence, within limits

Deployment control is valuable when it covers the parts of the system that affect data location, network policy, operational continuity, and replacement work. It does not automatically give you independence from the vendor.

Ask whether you can control the media path, TURN, recording, processing, and storage. Ask which components require the vendor's service, credentials, support, or proprietary control plane. Ask for the answer in deployment documentation and contract terms rather than relying on a sales description.

A customer-controlled deployment can reduce the amount of infrastructure that must move during a provider change. It cannot establish source-code escrow, perpetual licence rights, independent support, or a guarantee that the complete system will continue operating if the vendor stops providing service. Those protections require explicit contractual and operational arrangements.

The right criterion is therefore narrower and more useful: choose a platform that gives you meaningful control over the system boundaries you care about, then verify what that control permits in practice.

Build, buy, or deploy the replacement

There are three practical paths after an exit. Each places a different amount of responsibility in your organisation. The architectures themselves are compared in depth in the technical decision guide and the white-label decision guide; the notes below cover how each path looks after a provider exit.

Build on open source

Building on an open-source media stack can give your team greater control over the media layer and the ability to shape the product around your own abstractions. It also makes your team responsible for integration, upgrades, security response, deployment, observability, capacity planning, and the surrounding product experience.

This path fits an organisation that wants to own the engineering and operations of the communication system as a long-term capability. It is a poor fit when the team wants a finished service and has no capacity to operate the underlying components.

Buy a cloud video API

A cloud API can shorten the first release and place more of the infrastructure operation with the provider. The trade-off is that your application becomes dependent on the provider's APIs, service terms, pricing model, roadmap, and export capabilities.

This path fits a product whose requirements align closely with a stable, documented service and whose team has verified the exit terms. It is a weak choice when the provider's abstraction becomes the product's domain model or when a future provider change would require rewriting the client and backend together.

Deploy a commercial platform

A commercial platform can occupy the middle ground: embeddable SDKs and product components, combined with greater control over deployment and the boundary between your application and the media system. The evaluation must still distinguish a platform that is merely hosted from one that gives you meaningful control over the media path, TURN, and recording.

Samvyo is one option in this category. Its documented model is based on SFU architecture and provides embeddable SDKs, OEM and white-label depth, and a managed-service option. It describes customer-controlled deployment for the media path, TURN, and recording, including on-premise or managed-cloud arrangements, as set out in its deployment-model overview.

That description does not establish an ACS migration path, Teams interoperability, source-code escrow, perpetual licences, or a guarantee that the complete platform will operate without vendor support. Samvyo also states that it is not the fit when a buyer's needs are already met by a certified SaaS provider's standard terms, or when the buyer needs to operate and modify every layer itself. Those limits belong in the evaluation rather than being hidden behind the deployment model.

Choose the path whose responsibilities match your organisation. The safest selection is the one you can explain in an exit plan before you sign, including what your team would own if the provider changed direction.

Bottom Line

Choose an ACS replacement for its durability and exit structure before you choose it for its feature list. The provider should give you clear notice terms, a roadmap you can assess, portable application boundaries, and deployment control over the media functions that matter to your product.

A commercial platform can reduce provider dependence when its deployment model and contract give you real control, but that control has limits. Verify those limits before committing, and keep the application boundary yours from the first release.

What's Next

The companion guide, Azure Communication Services Is Retiring: What Actually Goes, What Survives, and What It Costs You, maps the ACS services that retire, the capabilities that remain in Teams-aligned scenarios, and the dates that shape the decision.

Read it before turning this selection framework into a migration plan, because the right replacement depends on which part of ACS your product actually uses.

To make the next exit cheaper whichever platform you choose, The Seam shows how to put video behind your own interface so the provider can be swapped later.

FAQs

What should I look for in an ACS alternative?

Look for roadmap durability, clear retirement and breaking-change terms, portable application boundaries, and control over the media path, TURN, and recording. Evaluate those criteria against the specific dependencies in your product rather than comparing feature lists alone.

When does Azure Communication Services retire?

Microsoft's retirement and breaking-changes guide states that the standalone Azure Communication Services offering retires on September 30, 2028. Microsoft also describes an onboarding restriction beginning October 23, 2026 for retiring services, with specific treatment for existing resources and Teams-aligned services.

Does a longer retirement notice make a video platform durable?

No. Notice gives your team time to respond, but it does not guarantee a replacement, feature parity, or continued support for the original architecture. Review the notice clause together with export capability, contractual rights, deployment control, and the provider's product direction.

Should a company build its own video infrastructure after the ACS retirement?

Build on open source when your organisation is prepared to own the media stack, deployment, upgrades, monitoring, and security response as a long-term engineering capability. Buy or deploy a commercial platform when those responsibilities would distract from the product, while checking exactly which parts remain under your control.

Can Samvyo replace Azure Communication Services directly?

Do not assume a direct ACS replacement or Teams interoperability from Samvyo's documented deployment model. Samvyo describes a platform based on SFU architecture with embeddable SDKs, OEM and white-label depth, and customer-controlled options for the media path, TURN, and recording; the buyer must separately validate product fit, migration work, and contractual continuity.

What does deployment control protect against?

Deployment control can reduce the amount of media infrastructure that must move when a provider changes direction, especially when the media path, TURN, recording, processing, and storage are under customer control. It does not by itself provide source-code escrow, perpetual licences, independent support, or a guarantee that every component will keep operating without the vendor.

How can I test a video platform's portability before signing?

Run an exit exercise using a representative workflow: create a room, authenticate a participant, establish a call, handle a device or network change, record the session, retrieve the result, and close the session. Document which data, application code, infrastructure, credentials, and provider services the workflow depends on, then ask the candidate to explain how each dependency would move.

In 2023 the Delhi High Court declined to halt a plan to install nearly 1.5 lakh (about 150,000) cameras in government school classrooms and live-stream them to parents, Bar & Bench reported. The petitioners, a parents' association and a teachers' association, argued that students had not been consulted and that live footage could reach people who should never see it. The court called the challenge premature and asked the government for its operating procedures.

That case puts the central design question of school video surveillance in the open. A school's cameras exist for a few minutes of real emergency and thousands of hours of ordinary days, and almost every hard decision is about who may see children on video, and when.

Why the Response in a School Is Different

Our pillar post on proactive and reactive surveillance describes response as the step where someone acts on what the cameras detected. In most commercial settings that means intervening: a voice from a speaker, a guard, a patrol.

A school's emergency response usually runs the other way. Its emergency plan decides when to lock down, shelter or evacuate, and the job of everyone involved is to make that decision quickly and get it to every classroom. In a building full of children, the response is set by that plan, and a remote operator confronting an intruder is not what it is built around.

That changes what the video system is for in an emergency. Its job is to:

• Inform the decision. Show the people who call a lockdown what is happening, where, and how it is moving, within seconds.
• Reach outside responders. Give arriving police or emergency services a live view of the building they are about to enter, for as long as the incident lasts.
• Record what happened. Preserve a reliable account for the investigation that follows.

The CISA's K-12 security guidance for school-based law enforcement treats monitored CCTV as a detection measure and expects school policies to cover how CCTV feeds are monitored. The protocol belongs to the school; the video system's role is to serve it.

Who May Watch Children: The Law Behind School Video Surveillance

On ordinary days the same cameras raise a different question. Children's data is treated more strictly than adults' almost everywhere, and the two regimes most of our readers face draw the lines in specific places. What follows describes what the texts say about processing and access. It is not a statement of what any school is required to install.

India.  Section 9 of the Digital Personal Data Protection Act, 2023 requires verifiable parental consent before processing a child's personal data, and states that a data fiduciary "shall not undertake tracking or behavioural monitoring of children." The DPDP Rules notified in November 2025 exempt educational institutions from both requirements, but only where processing is "restricted to tracking and behavioural monitoring" for the institution's educational activities or "in the interests of safety of children enrolled." Law-firm summaries of the Rules, such as AMS Shardul's, place the children's consent requirements in the phase that commences on 14 May 2027.

The exemption is a purpose limit. Cameras for safety sit inside it; the same footage used for something else may not. For a video system, purpose limits turn into access rules: which roles can view which cameras, for what reason, and with a record of who looked.

United States.  Under FERPA, the US Department of Education's FAQ on photos and videos says a video is an education record when it is "directly related to a student" and maintained by the school. Its example is a hallway surveillance video of two students fighting, used in a disciplinary action. Parents may generally inspect such a record, and footage of other students must be redacted first where that can be done without destroying its meaning. Video created and kept by a school's law enforcement unit for a law enforcement purpose falls outside the definition, until a copy is shared into, for example, a disciplinary file.

Both regimes connect to the general rules covered in our post on recording rules across the EU, US and India. For schools, the common thread is that the purpose and the holder of the footage decide what may be done with it.

Designing Live Access Before the Incident

The access model has to be built in advance, because there is no time to set permissions during a lockdown. Four roles cover most schools:

The responder row is the one most systems get wrong. A permanent login for the local police is convenient and is also standing access to children on video that nobody reviews. A better design issues access at the moment of the incident, scoped to the cameras that matter and expiring automatically, which is the same principle as issuing short-lived access tokens for any video room.

What School Video Surveillance Needs From the Video Layer

The emergency and the ordinary day produce one set of requirements:

• Live views that open in seconds, in a browser. Decision-makers and responders can't wait for software installs or a recorder interface that loads slowly. A live view on a phone or laptop, opened from an alert, is the useful form.
• Fine-grained, logged access. Per-role and per-camera permissions, time-limited sharing, and an audit log of who watched what. Purpose limits are only real if the system can enforce and prove them.
• Recording held under the school's control. Where the footage is stored, and who operates the servers it passes through, decide who else could see it. A school or district answering a parent or a regulator needs to be able to say.
• Retention and redaction that work. Keep footage for a defined period, then delete it, and be able to redact other children before an inspection. Whether that is practical depends on whether a recording can be redacted at all in the format it was made in.

Where Live Monitoring Isn't the Answer

Live-streaming classrooms to parents is the clearest example of a design that maximises viewing and minimises control, and it is the one the Delhi petitioners challenged. More viewers don't make children safer if nobody is responsible for acting on what they see. For most schools, a small number of trained viewers, a clear emergency procedure and well-controlled recording achieve more than wide live access.

The Bottom Line

In a school the response is a decision, usually a lockdown, made quickly and communicated to everyone. School video surveillance serves it by putting a live view in front of the decision-makers and responders within seconds, and by keeping everyone else out. Children's data rules in India and the US make access a design requirement: decide in advance who may see what, for what purpose, for how long, and keep the record.

What's Next

A school is full of people and the response is to protect them in place. A substation is empty and the response has to travel. Next: why detection is worthless without a response path at unmanned sites.

Frequently Asked Questions

What is school video surveillance used for in an emergency?

To inform the lockdown or evacuation decision and to give outside responders a live view of the building. The school's emergency plan decides what to do; the video system's job is to show the decision-makers what is happening within seconds and to record it.

Is CCTV in schools allowed under India's DPDP Act?

The Act bars tracking or behavioural monitoring of children and requires verifiable parental consent, but the 2025 Rules exempt educational institutions where the processing is for educational activities or the safety of enrolled children. The exemption is purpose-limited, and law-firm summaries place the children's consent obligations from 14 May 2027. Take legal advice on a specific deployment.

Can parents see school CCTV footage of their child in the US?

Generally, yes. Under FERPA, a video directly related to a student and maintained by the school is an education record that parents can generally inspect, with other students redacted where feasible. Footage kept by a school's law enforcement unit for a law enforcement purpose is excluded.

Should police have live access to school cameras?

During an incident, a live view helps responders. Standing access is harder to justify, because it gives permanent visibility of children without review. Time-limited access issued when an incident starts and revoked when it ends is the safer pattern.

Should schools live-stream classrooms to parents?

It widens who can see children without making anyone more able to act. The Delhi government's classroom live-streaming plan was challenged on privacy grounds in the Delhi High Court; as of the January 2023 hearing the court had asked for operating procedures. Most safety goals are met with fewer, trained viewers.

What should a school look for in a video platform?

Fast browser-based live views, per-role and time-limited access with an audit log, recording kept under the school's control, and practical retention and redaction. Samvyo, which is based on SFU architecture, delivers live camera feeds to browsers at sub-second latency and supports on-premise deployment, so the media path and recording stay on infrastructure the school or district controls.

North America's grid security information-sharing centre logged more than 3,500 physical security incidents in 2025, according to the E-ISAC's end-of-year report. Three percent of them caused an operational disruption. The other 97%, more than 3,300 incidents, still each needed someone to decide whether it was worth sending a crew, calling the police, or doing nothing.

That decision is what substation video surveillance is for. Our pillar post on proactive and reactive surveillance describes proactive monitoring as a loop of detect, classify, verify, respond and resolve. At an unmanned site, the respond step starts as a decision made far away, and the video system exists to give that decision good evidence quickly.

Why Nobody on Site Changes the Problem

At a guarded warehouse or a staffed store, detection can trigger someone nearby. At a substation, a telecom tower or a pumping station there is nobody nearby. The nearest crew may be a long drive away, at night.

Our post on perimeter detection sets out the race between detection and response: the response has to arrive before the intruder finishes. At a remote unmanned site, that race usually can't be won by arrival. Someone stripping copper or cutting through a fence will often be gone before any vehicle gets there.

So the response path changes shape. It becomes two steps:

1. A remote decision. Someone in a control room looks at the site and decides what is happening and what it warrants.

2. A dispatch sized to that decision. A crew in the morning, a crew now, the police now, or nothing.

Proactive is the only mode here, because there is no one on site to be reactive with. But the thing it buys is a better decision, made in time to send the right response.

What the 15 Minutes in CIP-006 Is For

North American utilities have a written deadline for the first step. NERC CIP-006-6, requirement R1.5, says a utility must "issue an alarm or alert in response to detected unauthorized access" into a physical security perimeter to the people named in its incident response plan "within 15 minutes of detection."

Two details matter for the video system:

• It is an alert deadline. The standard puts a clock on getting the right people informed. It says nothing about anyone arriving.
• Its scope is narrow. It covers physical perimeters around high-impact systems, and medium-impact systems with external routable connectivity. The separate physical-security standard for transmission stations, CIP-014, doesn't apply below 200 kV, as ReliabilityFirst's substation security briefing notes. Many substations fall under neither.

So many unmanned sites have no regulatory clock at all, and the ones that do have a 15-minute window to inform people. Video either makes that window useful or wastes it. A raw alarm reaching a control room says that a door contact opened. A live view reaching the same room says who opened it, what they are doing, and whether anyone is in danger.

Triage at a Distance: The Job Substation Video Surveillance Does

The same ReliabilityFirst briefing describes the expected response: the control centre or security operations centre assesses rapidly, then notifies dispatch to contact law enforcement. That assessment is the step most unmanned-site video is not designed for.

The operator is sorting events into categories that need different responses:

The last row is about life, as well as assets. Substations are lethal to people who don't know what they are touching. In April 2023 two men died at a substation in Gainesville, Georgia, while trying to steal copper and electrical components, CBS News reported from the police account. A control room that can see where an intruder is standing can tell responders what they are walking into.

The volume makes the sorting the main cost. Reporting also varies: the WECC's 2025 security review counted 220 physical security incidents reported on the federal DOE-417 form in the Western Interconnection in 2024, up from 107 in 2023, and attributes much of the rise to minor incidents reported by a single entity. Either way, most events are minor, and each one costs an operator's attention. Video that lets the operator dismiss the minor ones in seconds is what keeps the control room able to act on the serious ones.

What Substation Video Surveillance Has to Survive

Unmanned sites have the worst conditions for live video: thin backhaul, no local IT staff, darkness, and weather. A design that ignores them produces a control room that receives alarms and then waits for video that never loads.

The requirements follow from the triage job:

• A live substream that fits the link. Many remote sites connect over cellular or a narrow utility WAN. Across India, average upload speeds in late 2025 ranged from about 2.5 to 8.4 Mbps depending on the operator, per Opensignal's national figures, and remote locations sit below the average. A low-bitrate live view that opens instantly is worth more to triage than a full-resolution stream that buffers.
• Full-resolution recording kept on site. Record at full quality locally, send the live substream to the control room, and pull high-resolution clips only when an incident needs them.
• Camera control that responds. An operator triaging an event wants to pan, tilt and zoom to the alarm zone. Delay in that loop makes the camera overshoot, which is why steering a camera over the web is harder than streaming it.
• One control room, many sites. A utility's sites report into one place. Our post on connecting dozens of sites to one control room covers why that is an architecture problem more than a bandwidth one.
• The alarm and the view arrive together. The operator should never have to find the camera that matches an alarm. The alert should open the right live view, already pointed at the zone.

Latency matters, but in a specific way. A talk-down needs sub-second audio and video. Triage can tolerate a second or two of delay in the live view, but it can't tolerate the view taking 30 seconds to start, or a PTZ control loop so slow the operator can't frame the scene.

Evidence for Whoever Arrives Later

Because the dispatched response arrives after the event, the second job of the video is evidence. The crew needs to know what was damaged and where to look. The police need footage they can use. The utility needs a record for its incident report.

That means the recording has to survive the incident. Intruders who know where the recorder is can damage it, so footage should leave the site promptly once an event is confirmed, and the copy that matters should be held somewhere the intruder can't reach. Recording, export and retention belong in the response design from the start.

Where Video Doesn't Help

Video doesn't make the drive shorter. If the decision is right and the crew is still far away, the cable is still gone. What video changes is how many trucks roll for nothing, how quickly the right people learn about the serious events, and what they know when they arrive.

It is also easy to overbuild. If 97% of incidents cause no disruption, a small distribution site may not justify a live-monitored system at all. Recording with a daily review, or alarms with on-demand video, may be proportionate. The design question for each site is what decision someone needs to make about it, and how fast.

The Bottom Line

At an unmanned site nobody can intervene in the moment, so the first response is a decision made at a distance. Substation video surveillance earns its cost by making that decision fast and well: a live view that opens with the alarm, a camera the operator can steer, full-resolution evidence kept safe, and a control room that can dismiss the minor events quickly enough to act on the serious ones.

What's Next

Unmanned sites are permanent. The opposite problem is a site whose boundary changes as the work progresses. Next: watching a perimeter that moves every three months on a construction site.

Frequently Asked Questions

What is substation video surveillance used for?

It is mainly for remote triage. Nobody is on site and responders are far away, so video lets a control room operator decide whether an alarm is a false trip, vandalism, theft in progress or a person in danger, and send the right response. It also provides evidence for the crew and the police who arrive later.

How quickly must a utility respond to a substation intrusion?

For high-impact and some medium-impact systems in North America, NERC CIP-006-6 requires an alarm or alert to reach the people in the incident response plan within 15 minutes of detection. That is a deadline for informing people. It sets no arrival time, and many substations fall outside its scope.

Can you do a talk-down at an unmanned substation?

You can, but it isn't the core response. Talk-down needs sub-second audio and video and works best where a verbal warning is likely to end the event. At a remote substation the main job is deciding what to send, and that depends on a fast-opening live view and camera control more than on audio.

How much bandwidth does remote site video need?

Far less than full resolution. A low-bitrate live substream is enough for an operator to triage an event, while full-resolution video is recorded on site and retrieved when needed. Size the live stream to the worst link, because remote sites often run on cellular or narrow utility networks.

Should substation video be recorded on site or in the cloud?

Ideally both, in sequence. Record locally at full quality so nothing depends on the link, then move confirmed incident footage off site promptly so an intruder can't destroy it. Platforms such as Samvyo, based on SFU architecture, keep the media path and recording on infrastructure the operator controls, on premises or in its own cloud.

What does a control room need from unmanned site video?

An alert that opens the right live view, a camera it can steer without lag, a feed that loads over a thin link, and recorded evidence it can export. Samvyo is one option for the live delivery layer, carrying camera feeds to browser-based control rooms at sub-second latency while the operator keeps control of the media path.

On day one, a construction site is a fenced field with a site cabin. Three months later it has a basement, a tower crane and a compound full of plant. Six months after that the scaffold is coming down and the fit-out crews are moving copper pipe and cable into finished floors. The boundary, the valuables and the blind spots change with every phase.

That is the problem construction site surveillance has to solve, and it changes both halves of the response model in our pillar post on proactive and reactive surveillance. Detection has to come from cameras that run on temporary power and a cellular link, in positions that will be wrong next quarter. The response has to reach a site where nobody lives, through deterrence first and a call-out second.

Why Construction Site Surveillance Is a Different Problem

Most surveillance is designed for a building that will look the same in five years. A construction site is the opposite in four ways:

Each row pushes the design the same way. The surveillance system becomes temporary infrastructure, like the hoarding and the site cabin, and has to be planned as kit that gets installed, moved and taken away.

The target also changes. Early on the risk is plant and fuel. Later it is materials: cable, pipe, fixtures and tools, small enough to carry and worth enough to resell. A camera position chosen for the compound in month two is looking at an empty corner by month eight.

The Detection Half: Power, Uplink and Positions That Move

Three practical constraints decide what construction site surveillance can detect and send.

Power.  Camera positions on a site's edge rarely have a supply. Self-contained towers with solar panels and batteries exist for exactly this, and they trade continuous operation for energy budget. Analytics on the camera, a live stream on demand rather than always on, and infrared that only lights when needed all extend how long a tower runs between visits.

Uplink.  Most sites send video out over cellular, and upload is the scarce direction. Across India, national average upload speeds in late 2025 ranged from about 2.5 to 8.4 Mbps by operator, according to Opensignal's national figures, and coverage drops sharply away from towns. In TRAI's November 2025 drive tests, 21 to 25% of highway samples on the two largest networks had poor signal, against under 3.2% in the city tested. Edge-of-town sites sit somewhere between. Our post on how many feeds fit down a 4G uplink does the arithmetic for vehicles; a site has the same uplink with fewer cameras and more time.

Positions.  Cameras get moved as the perimeter moves. That means mounts and towers that a site team can relocate, a record of which camera covers what this phase, and a monitoring setup that doesn't break when a camera's location changes.

The design that fits all three sends a low-bitrate live view only when an event needs a human, and records at full quality on the tower itself. Full-resolution footage crosses the cellular link only when an incident calls for it, an approach covered in keeping the footage the network drops.

The Response Half: Deterrence, Then a Call-Out

Nobody is resident on most sites out of hours, and the response that works reflects that. It has two steps.

Deterrence comes first.  A remote operator who sees someone climbing the hoarding at night can light the area and speak to them through a speaker on the tower. On a construction site that can end the event, because an intruder who knows they are being watched has lost the cover the empty site gave them. Deterrence only works if the voice arrives while the person is still deciding, which is why the talk-down latency budget matters here: audio that lands ten seconds late is talking to someone who already has the cable.

The call-out comes second.  If deterrence fails, someone has to go. On a construction site that is usually a keyholder, a mobile security patrol, or the police. Each costs money and goodwill, so the operator's job is to call out only when the evidence justifies it, and to tell the responder what they will find: how many people, where on the site, with or without a vehicle.

That second step is where monitoring economics bite. Every false call-out costs a patrol visit, and every unwatched alert risks a real loss. Our post on what one operator can actually watch covers how detection quality sets the number of sites an operator can cover.

Why the Money Argument Is About Redeployment

A construction site's surveillance has a fixed end date, so the cost question differs from a permanent building's. Buying cameras for one project means writing them off over months. Renting monitoring per site means paying a recurring fee for a system whose positions keep changing.

The contractor that runs many projects has a third option: own the kit and move it. Towers, cameras and recorders that come off one site at handover and go onto the next turn surveillance into a reusable asset, spread across many projects. That only works if the system was designed to move: self-contained power, cellular rather than site-specific networking, and a monitoring setup where adding and retiring sites is routine.

Whether that beats renting depends on how many projects a contractor runs at once and how long each lasts. Published figures on construction theft don't settle it either. Registers such as the UK's CESAR and NCATT reports publish recoveries (127 items worth £1.72 million in the first quarter of 2024), not the number of thefts, so the loss side of the calculation has to come from a contractor's own claims history.

What Construction Site Surveillance Needs From the Video Layer

Put the detection and response halves together and the video requirements are specific:

• Live video that starts fast over cellular. The operator deciding whether to speak or call out needs a view within seconds of the alert, at a bitrate the uplink can carry at night.
• Two-way audio with low delay. Deterrence is the first response, and it works only if the voice reaches the person in time.
• Recording that survives the link. Footage recorded locally and pushed off site once an incident is confirmed, so a stolen or smashed tower doesn't take the evidence with it.
• Sites as a fleet. Many sites, each changing, monitored from one place, where adding or retiring a site and moving a camera are routine operations.

Where It Doesn't Pay

Not every site needs live monitoring. A small, short project with little plant and few materials on site may be better served by recording, good lighting and secure storage containers. Live construction site surveillance pays where the value at risk overnight is high, the site is exposed, and a call-out can arrive while it still matters.

The Bottom Line

A construction site is temporary, so its surveillance has to be temporary infrastructure too: self-powered, cellular, and easy to move as the perimeter is redrawn. The response is deterrence first and a call-out second, and both depend on live video and audio that reach the operator quickly over a thin link. Kit that moves from project to project is what makes the economics work.

What's Next

Deterrence and call-out assume the system should interrupt an intruder. Some sites need the opposite. Next: school and campus video, when the response is lockdown and the system's job is to inform a decision.

Frequently Asked Questions

What is construction site surveillance?

It is security monitoring for a temporary site whose layout changes as the build progresses. It usually means self-powered camera towers on cellular links, monitored remotely out of hours, with a response of audio deterrence first and a call-out to a keyholder, patrol or police if that fails.

How do construction site cameras get power and internet?

Usually through self-contained towers with solar panels and batteries, and a cellular router for connectivity. That makes energy and upload bandwidth the main design limits, so cameras record locally and send live video only when an event needs a human.

Does talk-down work on construction sites?

It can, because an intruder who knows they are being watched has lost the cover an empty site gave them. It only works if the operator's voice arrives within a few seconds, which needs low-latency audio and video over the site's cellular link.

Should a contractor buy or rent construction site surveillance?

It depends on how many projects run at once and for how long. Contractors with a steady pipeline can own the kit and redeploy it from site to site; occasional projects often suit rented, monitored systems. The kit has to be designed to move either way.

How much bandwidth does a construction site camera need?

Far less for live viewing than for recording. Record at full quality on the tower, send a low-bitrate live view only when an operator needs it, and pull full-resolution clips after an incident. Platforms such as Samvyo, based on SFU architecture, deliver live camera feeds to browser-based monitoring at sub-second latency while the operator keeps control of the media path.

How many construction sites can one monitoring operator cover?

It depends mainly on how many false alerts each site generates. Better detection lets one operator cover more sites. A video layer that opens a live view in seconds over cellular, such as the one Samvyo provides, shortens each check, but the alert quality sets the ratio.

A customer reports that yesterday's all-hands was unwatchable. You pull the browser stats from one attendee and find high packet loss on the video they received. That tells you the stream arrived damaged. It can't tell you whether the presenter's uplink failed, the attendee's Wi-Fi did, or the media server between them was overloaded.

Client-side collection, covered in our post on getStats, stops at exactly that point, and its section on what client stats cannot tell you says so. SFU observability is the other half. The media server is the only component that sees every sender's uplink and every receiver's downlink at once, which makes it the only place that can say whose network failed.

What the Media Server Sees That Clients Can't

An SFU holds a separate connection to every participant, so it measures each direction independently. That gives you five levels of evidence, each answering a different question.

The first two rows are what a client can never get. The presenter's browser knows its own uplink, and each viewer knows their own downlink, but only the server holds both for the same stream.

SFU Observability in LiveKit, mediasoup and Janus

The common open-source SFUs expose this evidence very differently, and that decides how much of your observability is configuration and how much is code.

LiveKit  ships a Prometheus endpoint. Its sample configuration notes that, when enabled, "LiveKit will expose prometheus metrics on :6789/metrics"; it is commented out by default. The metric definitions in its source cover rooms, participants and tracks, session join latency, NACK, PLI and FIR counts, packet loss, jitter, round-trip time, forwarding latency and a connection quality score. They carry node labels and no room or participant labels, which keeps the metric count manageable and means Prometheus can tell you a node is unhealthy but not which call suffered.

mediasoup  gives you the raw material and no exporter. Its RTC statistics are returned by getStats() on each producer, consumer and transport, including fraction lost, NACK and PLI counts, round-trip time, bitrate per layer and available outgoing bitrate. Events report score changes, layer changes and a worker process dying. Turning that into time series is code you write.

Janus  offers two routes. Its Admin API is, in the project's own words, "a poll-based protocol," so you query it on a schedule. Its event handlers push events instead, covering sessions, handles, SDP negotiation, ICE and DTLS state, media statistics and plugin events, to whatever backend you plug in.

With mediasoup or Janus, that collector is part of the running cost inside engineering time when you self-host. Whichever stack you run, the useful design splits two jobs. Low-cardinality metrics per node drive alerts. Per-session events and logs, keyed by room and participant, drive the investigation that follows.

Whose Network Failed: Sender, Receiver or Server

This is the first question of every call-quality incident, and the server can answer it if you keep sender and receiver quality apart.

mediasoup makes the split explicit. Each consumer reports a score from 0 to 10 for the stream it is sending to its receiver, a separate producerScore for the sender's stream it is forwarding, and per-layer scores when the sender uses simulcast. Where a stack doesn't package it as a score, loss and round-trip time measured separately on the incoming and outgoing streams give the same split.

Read together, the scores point at the failure:

The last row matters as much as the first three. A healthy server-side picture rules out the media path quickly, which is often the most useful thing an on-call engineer can establish in the first five minutes.

Signals That Lead and Signals That Lag

Google's SRE book frames monitoring around four golden signals: latency, traffic, errors and saturation. "If you can only measure four metrics of your user-facing system, focus on these four." Mapped onto a media server, they become concrete.

Two media-specific signals lead the generic ones. The first is layer downgrades. When bandwidth estimation reacts before the user notices, the server switches a receiver to a lower simulcast layer, and mediasoup emits a layerschange event when it does. A rising rate of downgrades across a node means quality is being traded away before anyone complains. The second is the keyframe request rate. PLI and FIR counts climb when receivers lose enough packets to need a fresh picture, and a jump across many consumers is an early sign of loss somewhere shared.

The lagging signals are the ones users produce: participants leaving and rejoining, low scores that have persisted for minutes, support tickets. They confirm an incident and are worth dashboards, but by the time they move, the call already went bad.

For saturation, our post on SFU scaling covers the capacity ceilings worth alerting on in detail and why bitrate and round-trip time make poor alert triggers on their own.

What SFU Observability Should Page On

The SRE book's rule is that "every page should be actionable." For a media server that excludes most single-participant problems. One attendee on a weak hotel network is real, but nobody on call can fix it at 2am, so it belongs on a dashboard or in a support ticket.

Page on conditions that affect many people and that an engineer can act on. No published thresholds exist for these, so the numbers below are design choices to tune against your own baseline:

• A worker or media process dies. Page immediately. Every call on it has just dropped or is about to.
• Join failures rise. For example, more than a few percent of join attempts failing over five minutes.
• Join latency climbs at the high percentile. For example, the 99th percentile of join latency doubling against the same hour last week. It leads saturation.
• A node approaches a hard ceiling. For example, sustained CPU per worker or egress above roughly 80% of what you have measured it can carry, so there is time to drain it before calls degrade.
• Many consumers degrade on one node at once. For example, the share of consumers with a low score or a recent downgrade crossing a set level across unrelated rooms. One room is a participant problem; many rooms on one node is yours.

Everything else, from single bad consumers to elevated loss in one room, goes to dashboards and to the investigation trail.

What the 2am Page Should Contain

A page that says "SFU node 3 unhealthy" sends the engineer hunting. A useful one arrives with the first answers attached:

• Scope. The node, how many rooms and participants are on it, and how many are affected.
• Direction. Whether producer scores, consumer scores or both have dropped, which tells the reader whether to look at senders, receivers or the server.
• Recent change. Deploys, configuration changes or certificate renewals on that node in the last hour.
• Saturation context. CPU, egress and streams per worker against their ceilings at the time of the alert.
• The trail. Links to the per-session events and to the matching client-side getStats records, joined on room and participant IDs.

That last item is why the identifiers matter. If the server logs and the client collector use the same room and participant IDs, an engineer can go from the alert to the affected sessions to the browser's own view of them in a few clicks.

The Bottom Line

The media server is the only place that sees both directions of every stream, so it is where you find out whose network failed. Keep sender and receiver quality apart, watch the signals that lead (join latency, layer downgrades, keyframe requests and saturation), and page only on conditions that affect many people and that someone can act on. Treat every threshold as a design choice and tune it against your own traffic.

What's Next

Knowing what to alert on is half the job; knowing who answers is the other. See who gets paged at 2am under build, buy and embed.

Frequently Asked Questions

What is SFU observability?

It is monitoring a selective forwarding unit from the server side: the quality of every incoming and outgoing stream, the health of each server process, and how quickly people can join. It complements client-side getStats, which only sees one connection from one participant's point of view.

What metrics should I alert on for a media server?

Worker or process deaths, join failure rate, high-percentile join latency, saturation against measured ceilings, and widespread consumer degradation on one node. Single participants with poor networks belong on dashboards rather than pages.

How can I tell if a call problem is the sender or the receiver?

Compare sender-side and receiver-side quality for the same stream. If the incoming stream is degraded, every receiver suffers and the sender's uplink is the cause. If the incoming stream is healthy and one receiver is degraded, the problem is that receiver's downlink.

Does LiveKit expose Prometheus metrics?

Yes, when enabled in its configuration it serves Prometheus metrics on port 6789. The metrics are labelled per node, so they are suited to alerting, while per-room investigation needs session-level events or logs.

Are there standard alert thresholds for WebRTC servers?

No published standard exists. Treat any threshold as a design choice: measure your own baseline, alert on sustained changes relative to it, and tune after real incidents.

Can I see server-side media metrics if I use a hosted video API?

Usually only what the provider chooses to expose. Platforms that keep the media path on infrastructure you control, such as Samvyo, which is based on SFU architecture, let you collect server-side metrics yourself and put them next to client stats for the same session.

Revoke a certificate on your internal certificate authority, publish the new revocation list, and Chrome will carry on accepting the certificate. According to the US Defense Department's Chrome security checklist, if the online-checking policy "is not set, or is set to false, then Chrome will not perform online revocation checks." Most of the revocation machinery a textbook PKI describes is never consulted by the clients that matter most in a video estate.

Our post on air-gapped video covers why an isolated network needs one at all: browsers only open cameras on secure pages, and no public CA will vouch for an internal hostname. This post is the operating manual. It covers which endpoints need the CA, how to get its root onto every device, which certificates the platforms will accept, and why rotation does the job revocation was supposed to do.

What in a Video Estate Actually Needs the Internal Certificate Authority

Start by scoping the CA to the endpoints that need it. Fewer certificates means fewer expiry dates, and one category of certificate in a video system never needed a CA at all.

Most of these sit at the network edge of a self-hosted deployment, and the relay is the one teams forget. Clients on restrictive networks fall back to TURN over TLS on port 443, and that connection fails silently if the relay's certificate comes from a root the client doesn't trust. The calls that break are exactly the ones on the most locked-down networks.

The media row is the one that saves work. RFC 5763, which defines how DTLS-SRTP keys are set up, says the certificates "can be self-signed and completely self-generated." The binding comes from a fingerprint of that certificate sent in the SDP. Browsers already generate their own, and media servers can too. Leave media certificates out of the CA's scope.

That has a consequence worth stating. The fingerprint travels over signalling, so the TLS certificate on your signalling endpoint is what stops someone substituting their own DTLS certificate in the middle. The CA doesn't encrypt the media, but it protects the channel that vouches for the media's keys.

The Root: Offline, Constrained and Distributed

A sound shape for a video estate is two tiers. The root signs an issuing intermediate and is then switched off and stored offline. The intermediate does the daily issuing. If the intermediate is compromised you revoke and replace it with the root, which nobody could reach.

Constrain the intermediate to your own names. RFC 5280 defines a name constraints extension that limits which hostnames a CA may issue for, and requires conforming software to recognise it. Put the constraint on the intermediate as well as, or instead of, the root: enforcement of constraints placed on a root has varied, and independent testing found that Chrome only began enforcing root name constraints in version 112 in 2023. With a constrained intermediate, a leaked issuing key can only mint certificates for names under video.corp.example.

Distribution is where the hours go, because every platform has its own trust store and its own rules.

The Android row matters most if you ship a native app. A browser on the device may trust your root while your own app, built against a modern SDK, rejects the same server. The fix belongs in your app's network security config, so it ships with every build of the app.

Leaf Certificates the Platforms Will Accept

Apple publishes explicit requirements, and they apply to all TLS server certificates on iOS 13, macOS 10.15 and later, with no exception carved out for private CAs:

• RSA keys of at least 2,048 bits, and SHA-2 signatures.
• Hostnames in the Subject Alternative Name. Names in the Common Name are no longer trusted.
• For certificates issued after 1 July 2019, the serverAuth extended key usage, and a validity period of 825 days or fewer.

Internal CAs that issue five-year certificates, a common default in older templates, produce certificates that iPhones and Macs refuse. Build your issuing templates to Apple's rules from the start, so no certificate has to be reissued when the first iPhone joins.

Rotation Is the Control That Works

Revocation is a list of certificates to stop trusting. Expiry stops trusting a certificate without anyone needing to check a list. That is why the stronger design for an internal CA leans on short lifetimes and automated renewal.

step-ca, an open-source CA, issues 24-hour certificates by default and renews them when about two-thirds of the lifetime has passed, retrying every minute if renewal fails. Its documentation calls short lifetimes "passive revocation." A stolen 24-hour certificate is useless by tomorrow, whether or not any client checks a list. It also supports ACME, the protocol public CAs use for automated issuance, so the same tooling that renews public certificates can renew internal ones.

For an isolated network this settles a real tension. Short lifetimes are only safe if renewal never depends on reaching outside, so the CA and its ACME endpoint must sit inside the boundary along with everything else. Once they do, renewal is routine and expiry stops being a scheduled outage.

Three rotations need planning beyond the leaves:

• Intermediate. Issue the new intermediate from the root while the old one is still valid, deploy the new chain to servers, then let the old intermediate's leaves age out. With 24-hour leaves that takes a day.
• Root. Distribute the new root to every device well before anything chains to it. This is the slow one, because it runs at the speed of your MDM and your least-managed device.
• Server reload. Check that each component reloads a renewed certificate without a restart. A TURN server or media server that only reads its certificate at startup turns a routine renewal into a dropped call.

Short lifetimes have one gap. Renewal lets anyone holding a private key keep extending the certificate, so step-ca's documentation warns that a retired certificate still has to be explicitly revoked on the CA, to stop it renewing.

Revocation: What Actually Checks It

The opening line was not an exaggeration. Chromium-based browsers stopped making online OCSP and CRL checks for most certificates years ago; Microsoft Edge aligned with Chrome in 2018, as Eric Lawrence's account of Edge's revocation behaviour explains. What Chrome does check by default is CRLSet, a list Google pushes for publicly trusted CAs. A certificate from your internal CA will never be on it.

Online checks for private roots exist, but only by policy. Edge's RequireOnlineRevocationChecksForLocalAnchors policy makes it "always" check certificates from locally installed CAs, and its description says certificates whose status can't be fetched are treated as revoked. It is supported on Windows only. That is a defensible setting for a managed Windows fleet, and an outage risk if the CRL host ever goes down.

So publish a CRL, for the clients and services that do check it: your own backend services, recording and storage components, and anything you configure to verify. Point its distribution URL inside your network, which RFC 5280's CRL distribution points extension supports. Skip OCSP. The public ecosystem is retreating from it, and Let's Encrypt switched its OCSP responders off on 6 August 2025, citing privacy and the cost of running them. An internal responder is one more service to keep available, for clients that mostly won't ask it.

The practical order of defences is short lifetimes first, then an explicit revoke on the CA so the certificate can't renew, then a CRL for the components that read one.

Where the Internal Certificate Authority Stops and Media Keys Begin

The CA authenticates servers and protects the signalling that carries DTLS fingerprints. It doesn't make the media private from the media server, because every hop's encryption ends at the SFU. If the threat is the server operator, that is a separate layer with its own keys, covered in our post on end-to-end encryption for group video.

The Bottom Line

Scope the internal certificate authority to the endpoints that need it, keep the root offline and the intermediate constrained, and build leaf templates to Apple's rules. Then treat rotation as your main control, because the browsers your users run will not consult your revocation list unless you force them to.

What's Next

A CA that renews certificates every day needs someone watching when renewal fails. Next: what to alert on before a call goes bad on the server side of a video estate.

Frequently Asked Questions

Why do I need an internal certificate authority for self-hosted video?

Browsers only allow camera and microphone access on secure pages, so the web app and signalling endpoint need certificates the browser trusts. On an internal or isolated network no public CA will issue those, so an internal certificate authority issues them and its root is installed on every device.

Does WebRTC media need certificates from my CA?

No. DTLS-SRTP uses self-signed certificates, and RFC 5763 binds them with a fingerprint sent in the SDP. What the CA secures is the signalling channel that carries the fingerprint.

Does Chrome check my internal CA's revocation list?

Not by default. Chrome makes no online OCSP or CRL checks unless a policy enables them, and its built-in CRLSet only covers publicly trusted CAs. Short certificate lifetimes are the more reliable control.

How long should internal certificates last?

As short as your renewal automation can sustain. step-ca defaults to 24 hours and renews automatically, and Apple rejects any TLS server certificate valid for more than 825 days. Hours to days is a good target where renewal runs inside your network.

Why does my mobile app reject a certificate the phone's browser accepts?

On Android, apps targeting API level 24 or later don't trust user-added CAs unless their network security config opts in. On iOS, a manually installed root has to be enabled under Certificate Trust Settings; MDM-installed roots are trusted automatically.

Who owns the certificates in an on-premise video deployment?

You do, for every endpoint inside your network. With an on-premise deployment of a platform based on SFU architecture, such as Samvyo, the media servers, TURN relays and recording run on infrastructure you control, so their TLS certificates come from your CA and your renewal schedule.

Turn on end-to-end encryption in a Zoom meeting and its own support documentation lists what switches off: cloud recording, live transcription, live streaming, the AI features, polling and the whiteboard. Phone and SIP participants can't join, nor can its Web App and Web SDK clients, and the meeting is capped at 1,000 people.

That list is the visible price of end-to-end encryption for group video, and our post on video deployment architecture already lists what that costs in general terms. This post covers the less visible part: what the server forwarding your call can still see, which features keep working, and the question that decides whether the claim is true at all, namely who holds the key.

Why an SFU Gets in the Way of Ordinary Encryption

Every WebRTC call is already encrypted. DTLS-SRTP protects each hop, but an SFU sits at the end of a hop. Media arrives at the server, is decrypted, and is re-encrypted for every subscriber. In a two-person call that terminates at the other browser; in a group call through an SFU it terminates at the server.

The server needs that access for ordinary work. It reads RTP headers to route packets, reads RTCP feedback to manage bandwidth, and drops layers when a subscriber's link is weak. The SFrame specification, RFC 9605, exists because full encryption would blind the server to exactly the information it needs to forward media.

SFrame's answer is a second layer. The sender encrypts each media frame with a key the server never receives, then hands the encrypted frame to the normal WebRTC stack, which wraps it in SRTP as usual. The server removes the outer layer and finds a frame it cannot read.

What SFrame Encrypts, and What the SFU Still Sees

SFrame encrypts the media payload. Almost everything around it stays visible to the server, and some of it says a lot about the call.

RFC 9605 is direct about the header: an observer can learn "which parties are sending media" from the key IDs and at what rates from the counters, and the key-ID structure can expose epoch counts and sender identifiers. The audio level extension is the sharper leak. RFC 6464 notes that because SRTP authenticates header extensions without encrypting them, "audio levels are therefore visible on a packet-by-packet basis," and an observer "might be able to infer information about the conversation." An SFU uses that extension to pick the active speaker, so it keeps receiving it.

Put together, end-to-end encryption for group video hides what was said. It does not hide who was in the call, who spoke, for how long, or when. For many threat models that is enough. For some, the metadata is the secret.

There is a second limit the specification states plainly: SFrame does not provide per-sender authentication. Every participant holds the keys needed to encrypt as any sender, so a malicious participant can impersonate another inside the call. The server is locked out; the other participants are trusted completely.

What Keeps Working: Forwarding and Layer Selection

A common assumption is that encryption stops the SFU from adapting quality. It doesn't, provided the stream is built for it.

RFC 9605 requires each simulcast layer to be encrypted separately, and each scalable (SVC) layer to be its own SFrame ciphertext, so that the SFU can still drop layers it doesn't need to forward. The server reads layer information from RTP headers and header extensions, never from the payload. If you want a refresher on how simulcast layers work, that is the mechanism being preserved.

The AV1 RTP payload specification goes further. Its Dependency Descriptor header extension was designed so an intermediary can forward frames "when the RTP payload is encrypted end-to-end," without parsing the bitstream at all.

What does break is any server logic that peeks into the codec payload. Some SFUs detect keyframes or read codec-specific descriptors from inside the frame, and that information is now ciphertext. Mozilla's WebRTC team describes the practical consequence in its guide to end-to-end encryption in all browsers: applications must know which bytes to leave unencrypted so the packetizer keeps working, and for some codecs, H.264 among them, that takes trial and error.

Two smaller costs come from encrypting whole frames. A receiver can't decode part of a frame, because the frame only authenticates once all of it has arrived. And key rotation can delay video for someone who has just joined, because they have to wait for a keyframe encrypted under a key they hold.

What Stops Working: Anything That Needs to See the Media

The list in Zoom's documentation has one cause. Every feature on it needs the server to see or hear the media, and under end-to-end encryption the server can't.

• Recording on the server produces ciphertext. A useful recording has to come from something that holds a key.
• Transcription, captions, noise processing in the cloud and any AI that has to read the media lose their input.
• Phone and SIP gateways have to decrypt to translate media into a format the other network understands, so a gateway becomes a participant with a key, or the call excludes it.
• Live streaming to a CDN needs decoded media at some point, with the same consequence.

The honest workaround is to make the component a participant. A compliance recorder that joins the call, holds the key and records it is legitimate, as long as everyone can see it is there. It also means the call is end-to-end encrypted between the participants, one of which is a recorder, which is a weaker sentence than most marketing pages use.

End-to-End Encryption Is a Key-Management Claim

SFrame encrypts frames. It deliberately says nothing about where the keys come from. RFC 9605 puts key exchange out of scope and describes two patterns an application can use: sender keys distributed over an existing end-to-end secure channel, or keys derived from an MLS group.

That gap is where most of the security lives. LiveKit's encryption documentation is a clear example: its built-in key provider uses "a single shared key for the whole room," which the server typically generates when the room is created and distributes the same way the platform hands out access tokens. Per-participant keys and rotation need a custom key provider. The documentation is careful to say LiveKit does not store or transport keys itself, and that signalling is still readable by the server.

That design is reasonable for keeping media unreadable to a cloud SFU operated by someone else. But if the same organisation runs the SFU and the service that generates keys, it can read the media by design. The test for any group-video encryption claim is one sentence long. Can the party that operates the media server obtain the key?

A strong answer to that question needs three properties:

• Keys are agreed between clients. No server generates the media key or sees it in transit.
• Keys change when membership changes. RFC 9605 says clients should rekey when participants join or leave, so a new joiner can't decrypt earlier media and a departed one can't decrypt later media.
• Identity is verified out of band. Otherwise the server can add a participant it controls, and that participant receives the key legitimately.

Messaging Layer Security, RFC 9420, is the IETF standard built for the first two. It gives a group forward secrecy and post-compromise security, and its key operations cost scales "as the log of the group size," which is what makes rekeying on every join practical for groups ranging "from two to thousands." The third property is a product decision: safety numbers, verified devices, or an identity provider the server can't impersonate.

The Browser Side in 2026

The browser API this depends on is now available everywhere. RTCRtpScriptTransform, which lets a worker see and rewrite each encoded frame, is Baseline on MDN since October 2025, after Chrome shipped WebRTC Encoded Transform in Chrome 141 on 30 September 2025. Safari and Firefox had already implemented it natively.

What browsers don't give you is SFrame itself. The native SFrameTransform interface was still "in limbo" when Mozilla's team wrote its guide in February 2024, so applications implement SFrame in script inside the transform. That puts the cryptography, the key handling and the packetizer details in your code.

The bandwidth overhead is small for video and noticeable for audio. RFC 9605 assumes 22 bytes per encrypted frame. The arithmetic, at 1,000 bits per kilobit:

Audio sends more frames than video and each one is small, so the fixed per-frame cost weighs more. On a constrained link that is worth budgeting for.

When End-to-End Encryption Is the Wrong Tool

End-to-end encryption answers one threat: the operator of the media server reading your media. If that operator is a vendor you would rather not trust, it is the right answer, and its costs are the price of that guarantee.

If the server operator is you, the calculation changes. A regulated organisation that must record and retain calls, transcribe them, or run analytics needs a server that can see the media. Encrypting the media end to end and then adding a recorder that holds the key gives you most of the costs and a weaker version of the claim. Running the media server, relay and recorder inside your own boundary keeps every feature and keeps the media away from any third party, without pretending the server is blind.

The question to ask is who you are protecting the media from. The answer picks the architecture.

The Bottom Line

SFrame lets an SFU forward media it can't read, and layer selection and active-speaker detection survive. What it doesn't hide is who spoke and when, and what it can't protect is a key that the operator generated. An end-to-end encryption claim is only as strong as the answer to one question, which is whether whoever runs the media server can get the key.

What's Next

Keys aren't the only trust root a self-hosted media estate has to run. Next: running your own certificate authority for real-time media, from root distribution to rotation.

Frequently Asked Questions

Does end-to-end encryption for group video work with an SFU?

Yes. SFrame, defined in RFC 9605, encrypts each media frame with a key the SFU never receives, while leaving the headers the SFU needs for forwarding and layer selection readable. The server can route the media but can't decode it.

What can the server still see in an end-to-end encrypted call?

Who is sending media and at what rate, packet timing and sizes, and the audio level of each packet, which reveals who is speaking. Signalling such as joins and leaves is usually visible to the platform too. The content of the audio and video is what stays hidden.

Can you record an end-to-end encrypted video call?

Only with something that holds a key. A server-side recorder sees ciphertext, so the recording has to come from a client or a recorder that joins the call as a participant. That makes the recorder a party to the encryption, and it should be visible to everyone in the call.

Is SFrame the same as WebRTC Insertable Streams?

No. Insertable Streams, now standardised as WebRTC Encoded Transform, is the browser API that lets your code see and modify each encoded frame. SFrame is the encryption format you can implement with that API. Browsers ship the API; most applications still implement SFrame themselves.

Who should generate the keys for end-to-end encrypted video?

The clients, ideally. If the server that runs the media also generates or distributes the media key, it can decrypt the call. Group key agreement such as MLS, RFC 9420, lets clients agree keys among themselves and rekey whenever someone joins or leaves.

Do I need end-to-end encryption if I self-host the media server?

Often not. End-to-end encryption protects media from whoever operates the media server. If you need recording, transcription or analytics and want media kept away from third parties, running the media path inside your own network may serve better. Samvyo, which is based on SFU architecture, supports on-premise deployment where the media path, TURN and recording run on infrastructure you control. End-to-end encryption is available as an option, off by default and configured for customers who need it, so a deployment can choose which guarantee it wants.

A video token is a signed note. It says who you are, which room you may enter, and what you may do there. The media server trusts it because it carries a signature only your secret can produce.

Whoever holds that secret can write any note they like. That includes one that joins your customer's board meeting as a participant nobody can see, and records it. This is why video SDK token auth is a security decision before it is an integration step.

The integration guide covers the mechanics: your backend mints tokens, the client never sees the secret. This post covers what goes wrong when that rule is broken, and the five decisions a token service has to get right when it isn't.

What the Secret Can Sign

Tokens are usually JWTs signed with the provider's API secret. The secret doesn't open one room; it can produce a token for any room, any identity and any permission the platform supports.

LiveKit's tokens and grants reference is a useful list because it is explicit. A token can carry, among others:

Read that table as an attacker would. A secret that reaches the browser lets anyone list your rooms, join any of them hidden, and record what they hear. Other platforms name the permissions differently, but every one signs tokens with a secret and trusts whatever the signature covers.

What Ships When the Secret Ships

Anything in a JavaScript bundle is public. Minification doesn't hide a string, and environment variables baked in at build time end up in the file the browser downloads. A secret in the client is a secret on every user's machine.

Be precise about which value matters. Many platforms hand out two things: an identifier (an app ID or API key) and a secret. The identifier often appears in client code by design. The secret must not. Agora shows the difference clearly: its projects can run with an App ID alone, and Agora's project documentation recommends App ID plus token, saying production should use token authentication rather than App ID only.

A leaked secret costs more than a leaked password, for two reasons:

• Revoking it ends every session at once. Tokens signed with the old secret stop verifying, so legitimate users are cut off along with the attacker.
• Rotation is a release. If the secret lives in client code, replacing it means shipping a new build to every web, iOS and Android user, while old builds keep the leaked one.

The Token Service: Five Decisions

The fix is a small backend endpoint. The client asks for a token, the server decides, signs and returns it. Each request answers five questions.

1. Who is asking?

Authenticate the user with your own identity system first, then put that identity in the token. Never take the identity from the request body. If a client can send identity: "ceo@customer.com" and get a token for it, you have built impersonation as a service.

2. Do they belong in this room?

The room name in the request is a claim, not a fact. Check it against your own data: is this user invited to this meeting, a member of this support queue, assigned to this case? Room names are often guessable (team-standup, sequential IDs), so the check matters.

3. What may they do?

Derive permissions from role, never from the request:

Least privilege here has a concrete payoff: a viewer token that leaks lets someone watch one room, not broadcast into it. Keep hidden for service participants such as recorders, never for people.

4. How long should it live?

This is the decision with a real trade-off. Short tokens limit damage; long tokens survive reconnection.

On security, the lifetime is your revocation window. LiveKit's guide to removing participants notes that removing someone from a room does not invalidate their token, and recommends short TTLs and not issuing that person a new token. Your token service is the kill switch: when it stops issuing tokens to someone, they are locked out once their current token expires.

On reliability, a reconnect has to present a valid token. Twilio lists an expired token as a reason reconnection fails in its reconnection documentation, and recommends tokens valid for the maximum session length, which its access token documentation caps at 24 hours. LiveKit takes the other route: the server refreshes tokens for connected clients, so a short lifetime only constrains the first join.

So the answer depends on the platform. With server-side refresh, use minutes. Without it, either have the client fetch a fresh token before expiry, or accept a lifetime as long as your longest realistic call and compensate with tight room and role checks. The failure on the other side is covered in keeping a call alive when the network drops.

5. If you verify tokens yourself, verify them properly

The media server verifies the provider's tokens. But teams often reuse the pattern: a recording worker, a webhook receiver or an internal API that accepts JWTs. Those are relying parties, and RFC 8725, the JWT best-practice document, sets the rules: accept only the algorithms you expect, check that the signing key belongs to the issuer, and require and validate the audience claim.

Where the Secret Lives

On the server, the secret belongs in a secret manager or the deployment's environment, never in the repository. Use one secret per environment, so a leaked staging key can't mint production tokens. Make rotation a configuration change you have practised: if your platform allows more than one active key, add the new one, move the token service to it, then retire the old one.

Keep exactly one place that signs. Teams that put one token endpoint behind your own interface get this for free: one service, one secret, one audit log of who was issued what. That log is what a security review will ask for.

A minimal endpoint, using LiveKit's Node server SDK as the illustration:

app.post('/video-token', requireLogin, async (req, res) => {
  const user = req.user;
  const room = req.body.room;

  if (!(await canJoin(user.id, room))) return res.sendStatus(403);

  const role = await roleIn(user.id, room);

  const at = new AccessToken(
    process.env.LK_KEY,
    process.env.LK_SECRET,
    {
      identity: user.id,
      ttl: '10m',
    }
  );

  at.addGrant({
    roomJoin: true,
    room,
    canPublish: role !== 'viewer',
    canSubscribe: true,
    roomAdmin: role === 'host',
  });

  audit.log({ user: user.id, room, role });

  res.json({ token: await at.toJwt() });
});

Ten minutes is safe here only because LiveKit refreshes tokens for connected clients. On a platform without refresh, the lifetime comes from decision four.

When the Simple Version Is Fine

Not every setup needs all of this on day one. A local prototype can use a development key, and App-ID-only modes exist so a demo works in an afternoon. The line is the first build a real user can download. From then on the secret lives on the server, because rotating it out of shipped clients is the expensive part.

Short tokens also have a cost. They add load to your token endpoint, and on platforms without refresh they create a reconnection failure that long tokens would never have. Choose the lifetime deliberately; don't copy one from a quickstart.

The Bottom Line

The signing secret isn't a key to a room. It is the press that prints every token your platform will honour. Keep it on the server, put your own identity and room checks in front of it, derive permissions from role, and treat the token lifetime as both your revocation window and a reconnection constraint.

What's Next

Tokens carry the identity your own system vouches for. Next: what IT will ask before a rollout, from SSO to automatic deprovisioning.

Frequently Asked Questions

Where should video SDK token auth happen, client or server?

On the server. The client authenticates with your app, asks your backend for a token, and the backend signs one with the provider's secret. Signing in the client means shipping the secret, and anyone with the secret can mint tokens for any room and any permission.

Is it safe to put a video API key in frontend code?

It depends which value it is. App IDs and public API keys are identifiers and often belong in client code. The secret that signs tokens never does, because it can create tokens with every permission the platform supports.

How long should a video access token last?

As short as your platform's reconnection behaviour allows. With server-side token refresh, minutes is fine. Without it, an expired token breaks reconnection, so either refresh from the client before expiry or use a lifetime that covers your longest call.

Does kicking a participant revoke their token?

Not necessarily. On LiveKit, removing a participant does not invalidate their token, so they can rejoin until it expires unless your backend stops issuing them new ones. Short lifetimes plus a token service that refuses removed users is the practical revocation.

What should a video token service log?

Every token issued: user, room, role and time. That log answers "who was in this meeting and with what rights" during an incident or audit. On any platform, Samvyo included, the token service sits in your own backend, so this log stays with you.

Does self-hosting video change token security?

The model is the same: a secret signs tokens and the media server trusts them. What changes is who holds the secret and the verification side. With an on-premise deployment, which Samvyo supports, both the signing secret and the media server sit inside your network, so rotation and audit are entirely in your hands.

A user walks out of the office mid-call. Their phone drops the Wi-Fi and picks up 4G in about a second. The call then does one of two things: it freezes for a moment and carries on, or it ends with a "You've been disconnected" screen and a rejoin button.

Which one happens is not luck. A network change breaks three separate things, and each needs its own recovery. A good video SDK runs two of those recoveries for you. Video SDK reconnection fails most often in the parts it leaves to your code, and those parts are small, specific and easy to get wrong.

What a Network Change Actually Breaks

When the phone changes networks, it gets a new IP address. Everything bound to the old one stops working at the same moment, but at three different layers.

The media path notices on its own clock. WebRTC keeps checking that the other side still wants its packets. RFC 7675 sets those consent checks at roughly every five seconds and lets consent expire after 30 seconds without an answer, at which point the browser must stop sending on that path. Getting it back takes an ICE restart or a new session.

Before that hard stop, the browser reports trouble through the ICE connection state. MDN's reference for iceConnectionState describes disconnected as a weaker signal than failed: it can appear on a shaky network and clear by itself. failed means every candidate pair was checked and none works. The timing between the two is left to each browser, so treat it as something to measure, not a constant.

None of this is new machinery. RFC 8445, the ICE specification, allows either side to restart ICE at any time, and the browser exposes it as restartIce(). If you want the background on how ICE finds a path in the first place, that post covers it. What matters here is what an SDK does when the path disappears.

Resume or Rejoin: The Two Recoveries an SDK Runs

Mature SDKs try a cheap recovery first and fall back to an expensive one. LiveKit's documentation is the clearest public description of this, so it is the example here.

The cheap path is a resume. According to LiveKit's connection guide, on a network change the SDK reconnects its signalling WebSocket and starts an ICE restart itself. The session survives. Users see nothing, or a video pause of a few seconds if media on the old path failed first.

The expensive path is a full reconnect, used when an ICE restart is not possible or does not work. The same guide describes the sequence: other participants are reported as disconnected, a Reconnecting event fires, the connection is rebuilt, Reconnected fires, every participant is announced as connected again, and local tracks are published again. LiveKit says plainly that this is the same as everyone leaving the room and coming back.

Twilio's SDK exposes the same split through error codes. Its reconnection documentation raises a reconnecting event with code 53001 for signalling and 53405 for media. If recovery gives up, the room disconnects with a reason:

The last row is the one most teams don't plan for, and it leads straight to the work an SDK cannot do for you.

The Three Jobs That Stay Yours

If you use an SDK, the first rule is to leave ICE restart alone. The SDK already watches the connection and restarts ICE on a network change. Adding your own restart from an iceconnectionstatechange handler duplicates work the SDK is already doing, and the two can collide. The quickstart-skips guide gives reconnection a paragraph; on an SDK, these three jobs are the rest of it.

Token lifetime

A reconnect has to prove the participant's identity again, usually with the token the client joined with. If that token has expired, recovery fails even though the network is fine. That is Twilio's 20104, and Twilio's answer is to issue tokens valid for the maximum session length of 24 hours.

That advice works against security, which wants tokens to expire quickly. LiveKit resolves the tension differently: its tokens and grants reference says the server issues refreshed tokens to connected clients, lasting ten minutes or the original token's remaining lifetime, whichever is longer, so expiry only constrains the first join. If your platform has no refresh, your client must fetch a fresh token from your server before the old one runs out. How to design short-lived tokens and the service that issues them is its own post; for reconnection, the rule is to pick a lifetime and confirm it survives a 30-minute call with a network change at minute 29.

Handlers that survive a replay

A full reconnect replays the room. Every "participant joined" and "track published" handler runs again for people who never left. Handlers that append without checking produce duplicate video tiles, double-counted attendance and two renderers fighting over one element. It looks like a rendering bug and is really a reconnect.

The fix is plain: key all room state by participant identity and track ID, and make every handler an upsert. Adding a participant who already exists should change nothing.

What the user sees

Users forgive a pause they can see explained. They don't forgive a frozen tile with no message. Three choices decide this:

• Don't drive the UI from one event. LiveKit lists Reconnecting only for the full-reconnect path, so a banner tied to it stays hidden during a resume. Its connection-quality value reaching "lost" arrives earlier.
• Don't tear down on disconnected. It is allowed to clear by itself. Show a "reconnecting" state after a short grace period instead.
• Tell the other side. Participants who stay put see a frozen face. A per-participant reconnecting indicator is cheap and saves the "can you hear me?" minute.

If You Are Building It Yourself

Without an SDK, all three layers are yours. The media layer is the familiar part:

pc.addEventListener('iceconnectionstatechange', () => {
  if (pc.iceConnectionState === 'disconnected') {
    graceTimer = setTimeout(() => pc.restartIce(), 3000);
  }

  if (pc.iceConnectionState === 'connected') {
    clearTimeout(graceTimer);
  }

  if (pc.iceConnectionState === 'failed') {
    pc.restartIce();
  }
});

window.addEventListener('online', () => pc.restartIce());

restartIce() makes the next offer an ICE restart, so your negotiation code has to handle negotiationneeded correctly, and the new offer travels over a signalling channel that may itself be reconnecting. That ordering is where most hand-built reconnection breaks: signalling must come back first, carrying a session ID the server recognises, before the restart offer can go anywhere.

The server needs a matching decision: how long it keeps a vanished participant's slot, published tracks and subscriptions before treating them as gone. No standard sets that window; it is a product decision. Too short and every tunnel becomes a rejoin. Too long and others watch a frozen tile.

Finally, the new network may be one that blocks UDP. A phone moving from home Wi-Fi onto a guest network can lose the path that worked at join time, so a restart that only tries UDP fails where a TCP or TLS relay on port 443 would have worked.

How to Know Whether It Works

There is no public data on how often calls survive a network change, and vendors don't publish their own rates. You have to measure yours.

Test the transitions users actually make: Wi-Fi to cellular, cellular to Wi-Fi, airplane mode for five seconds, airplane mode for 40 seconds (longer than the consent timeout), and a laptop that sleeps and wakes. For each, record which path ran (resume or full reconnect), how long media was gone, and whether the session came back as the same participant.

In production, the same questions come from the stats every session already produces: when bytes stopped arriving, when they resumed, and whether the candidate pair changed. Collecting getStats evidence in production shows which fields answer that and how to sample them. Count resumes and full reconnects separately. A rising full-reconnect share is the early warning.

The Bottom Line

A network change breaks the media path, the signalling channel and the session at once. An SDK recovers the first two and usually the third. What it cannot do is choose your token lifetime, make your event handlers idempotent or decide what users see, and those three decide whether a call survives the walk to the car park.

What's Next

Reconnection hurts most on mobile web. Next: iOS Safari, where the camera goes black without an error, even when the connection never dropped.

Frequently Asked Questions

How does video SDK reconnection work when a user switches from Wi-Fi to 4G?

The SDK reconnects its signalling connection and runs an ICE restart to find a new media path from the new IP address. If that works, the session resumes with at most a short video pause. If it fails, the SDK falls back to a full reconnect, which rebuilds the session as if everyone had left and rejoined.

What is the difference between ICE "disconnected" and "failed"?

disconnected means connectivity checks failed for at least one component and may clear on its own on a shaky network. failed means every candidate pair was checked and none works, which needs an ICE restart. Browsers decide the timing between them, so measure it rather than assume it.

Why does a call fail to reconnect even though the network is back?

Often the token expired. Reconnecting means proving the participant's identity again, and an expired token fails that check. Either issue tokens that outlive the session, or use a platform that refreshes tokens for connected clients.

Should I call restartIce() myself if I use a video SDK?

Usually not. Most SDKs restart ICE themselves on a network change, and a second restart from your code competes with theirs. Spend the effort on token lifetime, idempotent event handlers and the reconnecting UI instead.

How long should a server keep a disconnected participant's session?

There is no standard; it is a product decision. Too short turns every tunnel into a full rejoin, too long leaves others watching a frozen tile. When you evaluate a platform, Samvyo included, ask what the window is and whether you can tune it.

Does running video on my own infrastructure change how reconnection works?

The mechanics are the same: ICE restart, signalling resume and session state behave identically. What changes is that you own the TURN relays the new path may need. Samvyo keeps the media path and TURN on infrastructure you control, so relay capacity for reconnecting mobile users is something to size, not something a provider absorbs.

One vendor's documentation puts the gap in a single line: a prebuilt iframe gets you to a working call in minutes, a custom UI on its SDK takes hours to days. That is true, and it is the least important difference between the three embed video options.

Once you have made the build-or-buy decision and chosen a provider, there is a second choice inside "buy": how the video gets into your product. You can drop in the vendor's whole meeting UI in an iframe, assemble it from the vendor's UI components, or use the headless core SDK and draw every pixel yourself. Each one is cheap at a different moment. This post is about the moments after launch.

The Three Embed Video Options

Most providers now offer all three, under different names.

The vendors describe the trade-off in their own words. Daily's documentation on call modes calls its iframe mode the best fit for fast integration with minimal UI work, and its call object mode headless: Daily handles WebRTC and media while you build every pixel. Cloudflare's RealtimeKit SDK guide estimates under two hours to ship with its UI Kit and typically five to six days with the Core SDK alone. These are the vendors' estimates, not measurements, but the order of magnitude is right.

Time to first call is a one-off cost. The rest of this post is the recurring ones.

What Each Option Costs Later

Each row deserves a closer look, because each one is where a team that picked for speed tends to get stuck.

Styling: You Rent the iframe's UI

An iframe from another origin is a sealed box. Your stylesheet cannot reach into it, so every visual change goes through whatever the vendor exposes. Daily's Prebuilt customization guide is generous by iframe standards: feature toggles, colour themes, injected CSS, grid tile limits, custom tray buttons and sidebar apps. It is also clear about the edge: for a fully custom UI, use the call object. Even small things are on its terms; by default an embedded Prebuilt call has no leave button until you add one.

A UI kit moves the line. The components run in your page, take your theme, and can be swapped one at a time when one stops fitting. A headless SDK has no line at all, which is also its cost: every state the vendor's UI already handles (permission prompts, device switching, poor-network banners, screen-share layouts) is now yours to design and test.

Events and Auth: Who Owns the Call's State

With an iframe, your page learns about the call through the messages the iframe API chooses to send. If the API doesn't expose an event, such as a specific participant's network quality, you can't build a feature on it. With a UI kit or a headless SDK you get the full event stream, because the SDK runs in your page.

Auth moves the same way. In the iframe model, the vendor's UI makes the permission decisions, so your roles have to map onto its token properties. Daily's meeting tokens decide who is an owner or can record; 8x8's JaaS integration guide passes a signed JWT straight into the iframe constructor. That works until your product's roles don't fit the vendor's. With a UI kit or headless SDK, your own token service decides grants and your own UI enforces them, which is also where SSO and provisioning questions IT will ask get answered.

Permissions and Mobile: The iframe Has to Be Let In

A cross-origin iframe cannot use the camera unless the page that embeds it allows it. MDN's camera directive reference gives the default allowlist for the camera as self, and a blocked call to getUserMedia() rejects with NotAllowedError, the same error a user's refusal produces. In practice that means the iframe needs allow="camera; microphone", and per MDN's Permissions Policy guide the vendor's origin must also be allowed by your page's own Permissions-Policy header. Miss either and users see "camera blocked" with nothing in your logs to tell you why.

Mobile raises the stakes. Inside a native app, an iframe means a webview wrapping a page you don't control, with the platform's webview camera rules on top. On iPhones, that is WebKit, with its own camera behaviour on iOS Safari. Vendors that ship native SDKs and native UI kits avoid the webview entirely. If a native app is on your roadmap, check which of the three options the vendor offers on iOS and Android before choosing the web one.

Upgrades and Migration: Who Changes the Code

A hosted iframe changes when the vendor deploys. That is convenient: fixes and new features arrive without a release. It also means your users can see a new layout, a renamed button or a moved control before your support team does. With a UI kit or headless SDK, nothing changes until you upgrade the package, which is more work and more control.

Leaving is where the gap is widest. With a headless SDK behind a seam of your own, a provider change replaces an adapter. With a UI kit, the components go too, because they belong to the vendor. With an iframe, the whole meeting experience goes, and everything your users learned about it. That matches the evidence on what a provider switch rewrites: the object model, events and rendering all change.

Choosing: Which Layer Will You Need to Own?

The iframe is the right answer more often than engineers like to admit. If video is a supporting feature, used by a known audience on the web, with roles that fit the vendor's model, a prebuilt UI maintained by people who do nothing else is hard to beat. Accessibility, device quirks and poor-network handling come with it.

The signals that it won't stay right:

• Video is the product, or a core workflow. Branding and UX will matter, and themes run out.
• Your permissions model is your own. Clinician and patient, agent and customer, inspector and site: roles the vendor's token doesn't describe.
• You need call events in your own system. Analytics, billing by participant, CRM notes, compliance logs.
• A native app is coming. A webview is a poor long-term home for a camera.

If two or more apply, start with a UI kit and plan to replace components as you outgrow them. If you already know you need full control, go headless from day one; moving from an iframe to custom UI later means building the custom UI anyway, after users have learned the old one.

The Bottom Line

The three embed video options trade time now against control later. A prebuilt iframe is fastest and puts the vendor in charge of the UI, the roles and the release schedule. A UI kit shares that control. A headless SDK gives you all of it, along with every edge case. Choose by the layer you expect to own in eighteen months, not by the afternoon you save this week.

What's Next

Once auth lives in your own code, the next decision is how to issue tokens safely. Next: why you should keep the signing secret on your server.

Frequently Asked Questions

What are the embed video options for adding calls to a web app?

There are three: the vendor's prebuilt meeting UI in an iframe, the vendor's UI components running in your page, or a headless SDK where you build the UI yourself. Most video providers offer all three, under different names.

Is it bad to embed a video call in an iframe?

No. For a supporting feature on the web, with roles that fit the vendor's model, it is often the best choice. It becomes costly when you need your own branding, your own permission model, call events in your systems, or a native mobile app.

Why does my embedded video iframe say the camera is blocked?

The embedding page has to delegate camera and microphone access, usually with allow="camera; microphone" on the iframe and a matching Permissions-Policy header. Without both, getUserMedia() rejects with NotAllowedError, the same error as a user saying no.

What does "headless" mean for a video SDK?

The SDK handles media, rooms and events but ships no UI. You build every screen. It takes longer to launch and gives full control over design, permissions and behaviour.

Can I start with a prebuilt UI and switch to a custom one later?

Yes, but the custom UI is a rebuild, not a migration: nothing from the iframe carries over. A UI kit is the gentler path, because components can be replaced one at a time. Samvyo, for example, ships SDKs for JavaScript, React and React Native, so the choice of how much UI to own stays with you.

Which embed option is best for an on-premise deployment?

Any of them can work, but with an iframe the UI is served from wherever the vendor hosts it. If the requirement is that nothing loads from outside your network, check where the prebuilt UI is served from. With a platform such as Samvyo, which supports on-premise deployment, an SDK-based UI runs from your own application, so the question reduces to where the media servers sit.

On Android and desktop, a broken camera usually announces itself: a rejected promise, an error event, something your code can catch. On an iPhone, the camera mostly goes quiet instead. The track stays "live", the call stays connected, and the person on the other end watches a frozen or black tile while your logs show nothing wrong.

That is the core difficulty of running a video SDK on iOS Safari. The failures are real, but they arrive as state changes, not errors. We ran a one-page test on a real iPhone with Safari 26.0.1 on 13 October 2026 to see which of the documented behaviours still hold. This post walks through what we found and the handful of handlers that catch it.

Every iPhone Browser Is Safari

Start with scope. On iOS, "Chrome" and "Firefox" use Apple's WebKit engine, because Apple's App Store guideline 2.5.6 requires browsing apps to use WebKit, as The Register reported when Japan moved against the rule. The exception is narrow: Apple's embedded browser engine entitlement allows other engines from iOS 17.4, and only in the EU and Japan.

So testing on Chrome for iPhone is testing WebKit. A bug that appears in Safari almost always appears in every iOS browser your users have.

Don't branch on the version in the user-agent string either. WebKit bug 298473 records that Safari now freezes the iOS version it reports, permanently, after sites misread "26" as lower than "18". Our test phone's Safari reported itself as version 26.0.1 running on iOS 18.7. Detect features, not versions.

Mute Is Not End

A camera track (MediaStreamTrack) can tell you two different things:

The trap is that a muted track is still attached to the peer connection. The call does not drop, so your reconnection logic never runs. Nothing is wrong with the network. The other side simply stops receiving useful video.

iOS uses both signals, for different triggers. Our test results:

One device and one run, so treat it as confirmation of documented behaviour, not a survey.

Three Ways the Camera Goes Quiet

Leaving the page

When the page is hidden, iOS mutes the camera, and unmutes it when the page is visible again. This has been deliberate since 2017: WebKit bug 172200 made iOS mute the video source according to document visibility so a background tab cannot capture the camera.

Our test showed it still holds, with one useful detail: the mute event fired about 0.8 seconds before the page's visibilitychange event. If your UI waits for visibility events to explain the pause, it is late. Listen on the track.

Users do this constantly: checking a message mid-call, taking a phone call, locking the screen. Every time, the other participants see the video freeze.

Switching cameras

This behaviour has changed over the years, and old advice is wrong. In 2017, WebKit bug 179363 reported that a second getUserMedia() call muted the first track with no way to unmute it, and WebKit called that expected. In 2022 it changed: asking for a different camera now stops the previous capture, because iOS cannot capture both at once, while the same camera can run in parallel.

Our test matched the 2022 behaviour. Requesting the back camera ended the front camera's track outright. Asking for the front camera again left both running.

So a camera flip on iOS is not a mute you can wait out. The old track is gone. Get the new track first, then swap it into the call with the sender's replaceTrack(), then stop the old one, and make sure your ended handler doesn't treat this as a failure.

Route changes in a single-page app

Sometimes the trigger is a WebKit bug. WebKit bug 272704 reported that in iOS 17.4.1, calling history.pushState() muted the camera track. That's what any single-page app router does when the user moves between screens. It worked in 17.4.0 and earlier, and a fix landed in WebKit under a related bug. We couldn't re-test it: the camera had already ended in the previous step of our test.

The lesson is not this particular bug. Point releases change camera behaviour, and the change shows up as a muted track, not an exception. Code that listens for mute catches the next regression too.

Sound and Autoplay

Video can autoplay on iOS only under conditions. WebKit's iOS video policy has allowed muted video to autoplay since iOS 10, requires playsinline for inline playback on iPhone, and pauses video that gains sound without a user gesture.

Calls get an exception. As webrtcHacks summarised from WebKit's WebRTC documentation, stream-backed video can autoplay when the page is already capturing the camera or microphone. Our test agreed: remote video with sound started without a tap while the camera was on. An AudioContext created without a tap stayed suspended, so Web Audio processing (meters, noise effects, mixing) still needs a gesture.

The case that still breaks is the viewer who isn't capturing: a webinar attendee, a monitoring wall, a listen-only participant. Without capture there is no exception, so sound needs a tap. Put a real "Join" button in front of the call and start playback from it.

What to Build

Four handlers cover most of it:

function watchCamera(track, sender) {
  track.onmute = () => showPaused('Camera paused');

  track.onunmute = () => hidePaused();

  track.onended = async () => {
    if (switchingCamera) return;

    const s = await navigator.mediaDevices.getUserMedia({ video: true });
    const fresh = s.getVideoTracks()[0];

    await sender.replaceTrack(fresh);
    watchCamera(fresh, sender);
  };
}

// Every <video> element: playsinline. Start playback from the Join button.

Alongside the code:

• Tell the other side. Send a "camera paused" signal over the data channel or your signalling, so remote participants see a label instead of a frozen face.
• Measure it. Count mute and unmute events per session, and watch outbound frame counts drop to zero when you collect getStats in production. A spike after an iOS update is how you learn about the next regression.
• Flip cameras with replaceTrack. Don't tear down and rebuild the connection.
• Feature-detect. Check for the API you need, not the iOS version.

How to Test Without a Device Lab

You need a real iPhone; simulators don't reproduce camera interruptions. You don't need a lab. We used a single HTML page, served over HTTPS (the camera requires it), that logs every track event with a timestamp and produces a copyable report. Someone with an iPhone opens the link, taps through each trigger, and sends the report back.

Re-run it after every major iOS release. The behaviours in this post moved twice in eight years.

The Bottom Line

A video SDK on iOS Safari fails quietly. Leaving the page mutes the camera, switching cameras ends the old track, point releases have muted it by accident, and none of it throws. Listen for mute and ended on the track, tell the other participants, start sound from a tap, and test on a real phone after each iOS update.

What's Next

Mobile is also where the embedding choice bites, because an iframe inside a native app means a webview. Next: choosing between an iframe, a UI kit and a headless SDK.

Frequently Asked Questions

Why does my video SDK on iOS Safari show a black screen with no error?

Usually the camera track has been muted, most often because the user left the page. The track stays live and the call stays connected, so no error fires. Listen for the track's mute and unmute events and show the state to both sides.

Does Chrome on iPhone behave differently from Safari for video calls?

Not in most of the world. Apple requires iOS browsers to use WebKit, so Chrome on iPhone has Safari's camera and autoplay behaviour. Other engines are allowed only in the EU and Japan, from iOS 17.4.

Why does switching to the back camera stop the front camera on iPhone?

iOS can't capture from two cameras at once, so requesting a different camera ends the previous camera's track. Get the new track, swap it into the call with replaceTrack(), then stop the old one.

Can a web video call keep sending video when the user leaves the page on iOS?

No. iOS mutes camera capture while the page is hidden and resumes it on return. Native apps have more options, which is one reason teams with heavy iPhone use ship a native client, for example on Samvyo's React Native SDK. For web, the right response is a clear "camera paused" state for the other participants.

Why won't remote audio play automatically on iPhone?

iOS needs a user gesture to start audio, unless the page is already capturing the camera or microphone. Viewers who only watch need a tap, so start playback from a Join button.

Do these iOS issues depend on which video platform I use?

The behaviour comes from WebKit, so every web video SDK sees it, Samvyo's JavaScript and React SDKs included. What differs is how much of the handling a platform does for you, so test mute, camera switching and autoplay on a real iPhone with any SDK you evaluate.

An employee is let go at 10:00. IT disables their account in the identity provider at 10:05. At 10:20 they are still in the all-hands video call, and their app still works.

Nothing failed here. Single sign-on did its job: it checks identity when someone signs in, and they had signed in that morning. Removing them is a different job, done by different machinery, on a different clock. That is why enterprise video SSO and SCIM come up together in every security review, and why the second one is where the hard questions are.

The admin and provisioning APIs check names this area as one of six things an enterprise buyer tests. This post opens it up: the questions IT will actually ask, and what a good answer looks like.

Question 1: SAML or OIDC?

IT will ask which single sign-on protocol you support. The two in use are SAML 2.0, the XML-based standard most enterprise identity providers have supported for years, and OpenID Connect, built on OAuth 2.0 and common in newer setups and mobile apps.

The practical answer is both, or at least the one this customer's identity provider prefers. Two follow-ups matter more than the protocol: can SSO be enforced, so no one keeps a password login that bypasses it, and does the same identity work in your mobile apps, not only in the browser?

Question 2: How Do People Get Out?

This is the question that fails reviews. SSO checks identity at sign-in and says nothing afterwards. Just-in-time provisioning, where an account is created on first SSO login, has the same blind spot: it learns when someone arrives, never when they leave.

Leaving is what SCIM is for. It is a REST protocol where the identity provider pushes changes to your app: create user, update user, change group membership, deactivate user. The SCIM core schema in RFC 7643 gives every user an active attribute; false generally means the account is suspended, though each service decides exactly what that does.

Microsoft's guide to building a SCIM endpoint for Entra ID shows what that looks like in practice: disabling a user arrives as a PATCH that sets active to false, and a hard delete arrives as DELETE. The same guide sets out what Entra expects from your endpoint, including filtering users by userName and supporting PATCH, and notes that provisioning cycles run approximately every 40 minutes.

Large video vendors follow the same pattern. Zoom's SCIM guide describes deactivation in Entra or Okta flowing through to the Zoom account automatically.

So the good answer to question 2 is: we support SCIM 2.0, deactivation suspends the account and everything attached to it, and here is what "everything" means.

The Deprovisioning Window

"Everything" is where video differs from most SaaS. A suspended account blocks the next login. It does not, by itself, remove someone from a call they are already in, because live media runs on a token issued earlier.

That gives three clocks between "disabled in the IdP" and "out of the call":

The last row is the one teams miss. On LiveKit, removing a participant does not invalidate their token, so the token's lifetime matters as well as the removal. On Twilio, tokens can last up to 24 hours, and Twilio recommends long tokens so reconnection keeps working. A team that only suspends the account, issues day-long tokens and never removes anyone from live rooms has a worst case of about 24 hours 40 minutes.

Closing the window takes three pieces of work, all in your backend:

• React to the SCIM deactivation. Suspend the account, revoke your own app sessions and stop issuing video tokens to that user.
• Remove them from live rooms. Use the platform's server API to disconnect the participant from every room they are in.
• Keep tokens short where you can. A token lifetime is also a revocation window, so pick one that limits how long a removed user can rejoin.

Do all three and the window is the provisioning cycle, about 40 minutes on Entra's schedule, or minutes if an admin triggers provisioning by hand. That is an answer IT can sign.

Question 3: How Do Groups Become Roles?

IT will want permissions driven by groups it already manages, not by a second admin console. SCIM carries group membership, and your app maps groups to roles: "Video-Hosts" can start webinars and record, "Support-Agents" can join customer rooms, everyone else can join meetings they are invited to.

Two details save trouble later. Map roles from groups at token-issuing time, so a group change takes effect on the next token rather than the next login. And don't let video permissions live only in the vendor's console. If roles are set there by hand, every org change becomes a ticket, and the identity system stops being the source of truth.

Question 4: What About People Outside the Directory?

Enterprise video has a population the identity provider doesn't know: customers in a support call, patients in a consultation, candidates in an interview, partners in a joint review. They can't sign in with SSO, and SCIM will never deprovision them.

A good answer separates the two populations clearly:

• Employees sign in with SSO and are governed by SCIM.
• Guests join through a single-room, short-lived link or token, with no publish rights beyond what the session needs, and nothing that outlives the meeting.

IT will also ask whether guests can be blocked entirely for some rooms, and whether a guest can ever be promoted to host. Both should be configurable, and the answer should be "only by an employee in that room".

Question 5: What Gets Logged?

The last questions are about evidence. Who joined which meeting, from where, with what rights? Who started a recording, and who watched it later? IT wants these in its own security tools, not on a vendor dashboard.

That means an export or streaming API for join, leave, role-change and recording events, keyed to the same identity SSO uses. Recordings need their own trail: an access log on every recording retrieval is part of a defensible pipeline. If your token service logs every token it issues, you already have half of this.

The Short Version of the Questionnaire

The Bottom Line

SSO gets people into an enterprise video product; SCIM gets them out. Between the two sits the part specific to video: a live call runs on a token that outlives the account change unless you remove the user and keep tokens short. Answer that, plus groups, guests and logs, and the security review becomes a formality.

What's Next

Identity is one of the things that has to hold when the whole company joins at once. Next: what has to hold at org-wide peak.

Frequently Asked Questions

Do enterprise video platforms need both SSO and SCIM?

Yes, for different jobs. SSO checks identity at sign-in; SCIM creates, updates and deactivates accounts when the identity provider changes. Without SCIM, a departed employee's account stays active until someone removes it by hand.

Is just-in-time provisioning enough instead of SCIM?

It handles arrivals, not departures. JIT creates an account on first SSO login but gets no signal when someone leaves, so deactivation still needs SCIM or a manual process.

How long does SCIM deprovisioning take?

It depends on the identity provider. Microsoft documents Entra ID provisioning cycles running approximately every 40 minutes, so a disable can take up to that long to reach your app. Removing the user from live calls is a separate step your app has to take.

Does disabling a user end their current video call?

Not by itself. The call runs on a token issued before the change. Your app needs to remove the participant from live rooms through the platform's server API and stop issuing new tokens.

How should guests join an SSO-protected video platform?

Through single-room, short-lived access issued by your backend, with only the rights the session needs. Guests are outside the directory, so their access should expire with the meeting.

Where does identity live in a self-hosted video deployment?

In your own identity provider and backend, as with any platform. With an on-premise deployment, which Samvyo supports, the media servers that enforce tokens also sit inside your network. Ask any vendor, Samvyo included, how SCIM deactivation reaches users who are already in a call.

At 9:58 on a Thursday, nobody at a 10,000-person company is in the all-hands. At 10:02, 8,000 of them are. Your video platform has to absorb that in four minutes, and steady-state capacity says almost nothing about whether it will.

Concurrent video session scale is usually discussed as a media problem: how many streams a server can forward. At org-wide peak, the media servers are rarely what fails first. What fails first is everything that happens when people join, because all of it happens in the same minute.

Two Peaks With the Same Headcount

Org-wide peaks come in two shapes. They put the same number of people on the platform and stress completely different things.

The scenario is illustrative: 10,000 employees, 80% attending the all-hands, and a Monday where 8,000 people are in small meetings. The arithmetic below scales linearly with your own numbers.

Shape A: One Room Bigger Than One Server

The all-hands is a broadcast, and the media numbers are large but predictable. LiveKit's published benchmarks are useful because they state the hardware: one 720p publisher to 3,000 subscribers ran a 16-core c2-standard-16 instance at 92% CPU, sending about 531 MB/s. That is roughly 1.42 Mbps per viewer.

At 8,000 viewers, the same rate is about 11.3 Gbps of egress, around 5,100 GB in an hour. Our guide to what that egress costs prices it by venue.

The harder constraint is structural. The same LiveKit page notes that in its benchmarks each room must fit within a single node, and 8,000 viewers is about 2.7 times what one benchmark node carried. An all-hands at that size needs a platform that can spread one session across several servers, which is the cascading covered in our post on consumers per core, network interfaces and cascading.

Hosted APIs make the limit explicit. Twilio's video quotas cap a room at 50 participants. An 8,000-person all-hands is not a bigger room on that kind of platform; it is a different product.

That leads to the honest counterweight: an all-hands may not need to be interactive at all. A one-way live stream with a few seconds of delay, plus chat or moderated Q&A, serves 8,000 viewers on ordinary streaming infrastructure. Real-time video earns its cost when viewers speak, not when they watch.

Shape B: Two Thousand Rooms in One Minute

Monday morning looks harmless room by room. Each meeting is four people, well inside any server. The total is not small: 2,000 rooms × 4 participants × 3 received streams is 24,000 forwarded streams, about 14.4 Gbps at a 600 kbps average. At the roughly 500 forwarded streams per CPU core the SFU scaling post works from, that is 48 cores of forwarding work, spread sensibly across hosts.

That much is ordinary capacity planning. The peak-specific part is creation and placement. Each room has to be created, assigned to a server and filled within a couple of minutes. If your backend creates rooms through a provider's REST API, the account limits apply: Twilio's default is 20 write requests per second, so creating 2,000 rooms takes 100 seconds before anyone is placed. Its default of 10,000 rooms in flight at once is fine here, but it's a number to check against your own Monday.

The placement logic matters too. Two thousand rooms arriving in a minute is the moment a scheduler that packs rooms onto the emptiest server makes its worst decisions, because "emptiest" is measured before the load arrives.

The Join Path Saturates First

Both shapes share the same expensive minute. Every join, in either shape, runs the same sequence:

If arrivals cluster, and for a meeting that starts on the hour they do, the rate is far above the average. Eight thousand joins over four minutes averages 33 per second. If half arrive in the final minute, it is about 67 per second. We know of no public data on arrival curves for scheduled meetings, so measure your own; the shape matters more than the total.

TURN is easy to forget. The only public measurement of relay share, callstats.io's 22% of conferences from 2015–16, is best read as a ceiling for SFU-based products, but even 22% of 8,000 is 1,760 relay allocations in four minutes.

The strongest evidence that the join path is its own failure domain comes from an outage. During Cloudflare's 12 June 2025 incident, its realtime SFU kept existing connections running but could not create new sessions, and its TURN service failed almost completely. Calls in progress survived; nobody new could join. At peak, that pattern is the whole event.

What to Do Before the Peak

• Load-test joins, not minutes. Most load tests hold a number of participants steady. Peak readiness means replaying a realistic arrival curve and measuring join success rate and time-to-first-frame.
• Pre-scale for scheduled events. The all-hands is on the calendar. Autoscaling that reacts to load starts adding servers after the storm has arrived.
• Pre-create rooms. For Monday-style peaks, create rooms when meetings are scheduled, not when the first person clicks join.
• Issue tokens early. A token sent with the meeting reminder at 9:55 moves load off the busiest minute, provided its lifetime covers the meeting.
• Size TURN for allocations, not just bandwidth. The allocation rate at peak is the number to test.
• Decide what the all-hands really is. If almost everyone only watches, a live stream is cheaper and more robust than an 8,000-person interactive room.

The Bottom Line

Concurrent video session scale at org-wide peak is a timing problem before it is a capacity problem. The all-hands needs one session to span several servers, Monday morning needs thousands of rooms created and placed in a minute, and both push every join through identity, tokens, signalling and TURN at once. Test the join path at the arrival rate you will actually see, and the media servers are usually the easy part.

What's Next

Peak is when an outage costs the most, and when the contract matters. Next: what a video SLA actually promises, and what the credit is worth when it breaks.

Frequently Asked Questions

How do you plan concurrent video session scale for an all-hands meeting?

Plan for the join rate as well as the audience. Eight thousand viewers need roughly 11 Gbps of egress at 720p and a platform that can spread one session across several servers, but the first stress is thousands of joins in a few minutes. If most attendees only watch, a one-way live stream is often the better tool.

What usually fails first when everyone joins a video call at once?

The join path: sign-in, token issuance, signalling, room creation and TURN allocation. Media servers are sized for steady state; the join path takes every request in the same minute. Outages have shown existing calls surviving while new joins fail.

How many participants can one video room hold?

It depends on the platform. Twilio caps a video room at 50 participants. LiveKit's benchmarks ran 3,000 subscribers on one 16-core node, with each room fitting on a single node. Larger sessions need cascading across servers or a broadcast path.

Does autoscaling handle video peaks?

Not by itself for scheduled peaks. Reactive autoscaling adds servers after load arrives, which is after the join storm. For known events, scale up in advance.

How should we load-test a video platform for peak?

Replay a realistic arrival curve, such as half the attendees joining in the final minute, and measure join success rate and time to first video frame, not just how many participants the system can hold once connected.

Does self-hosting change peak planning?

You own every step of the join path and the capacity behind it, including TURN. With a platform such as Samvyo, which supports on-premise and managed-cloud deployment and is based on SFU architecture, the questions are the same: how a large session spans servers, how fast rooms can be created, and how the join path was tested.

An enterprise video SLA reads like a promise that calls will work. 99.9% uptime sounds like almost never down.

Read the document instead of the number and the promise narrows quickly. Availability might mean API requests that didn't error, or joins that succeeded, measured in five-minute windows. Outages shorter than five minutes may not count at all. Your own peak can be excluded. And the remedy for all of it is usually a credit of around 10% of one month's bill.

We read three published SLAs from companies that sell real-time video, as they appeared on 13 October 2026. This post sets out what they actually commit to, and what to ask for when it matters.

What the Percentage Allows

Start with the arithmetic. Over a 30-day month:

Forty-three minutes is one all-hands. A 99.9% SLA can be met in full by a month in which your single most important meeting failed from start to finish. The percentage says how much failure the vendor accepts, not when it happens.

Three SLAs, Three Definitions of "Available"

What counts as downtime matters more than the percentage, and the three documents define it differently.

Sources: the Twilio APIs SLA (last updated 9 April 2026), the Amazon Chime SDK SLA (last updated 18 November 2022) and the BytePlus RTC SLA (last updated 18 March 2024). SLAs are revised; check the version in your contract.

BytePlus's definition is the closest to what a user experiences: it measures whether people could join. Chime SDK's measures whether the API calls that create meetings and attendees returned errors. Twilio's measures minutes of unavailability. None of the three measures whether a call, once joined, was any good.

Four Gaps Between the SLA and a Bad Call

Short outages don't count

Twilio excludes unavailability of less than five continuous minutes. BytePlus requires join success below 95% for five minutes or longer. A four-minute failure at 10:00, or three two-minute failures in an hour, can leave the SLA untouched. Real-time video is unusually sensitive to short failures: a call that drops for four minutes is a meeting lost, not a minor blip.

It measures the API, not the call

Chime SDK's availability is built from requests: creating meetings and attendees, starting media pipelines, messaging. If those calls succeed but audio is choppy or video freezes, the SLA sees a healthy service. The same gap exists in reverse during real outages: when Cloudflare's realtime SFU failed in June 2025, calls in progress continued and only new sessions failed. Which side of that split your SLA measures decides whether the incident counts.

Your peak can be excluded

BytePlus excludes high-concurrency events on the customer's side. Chime SDK excludes downtime caused by exceeding service quotas. Both are reasonable from the vendor's side: they can't promise capacity you didn't plan for. But they mean the SLA is weakest at the moment every join arrives at once, which is when an outage costs the most. If your critical events are known peaks, the contract needs to say they are covered, with the quotas to match.

Is video even covered?

Read the product scope before the percentage. Twilio's SLA covers APIs branded "Twilio" without listing Programmable Video by name, a point our post on who gets paged when video fails raised earlier. Twilio also excludes alpha, beta and limited-release APIs. If the feature you depend on is new, it may sit outside the SLA entirely.

What the Credit Is Worth

Take the crossover workload from our pricing analysis: 100 concurrent participants, eight hours a day, 22 days a month, at $0.004 per participant-minute, or $4,224 a month.

A 10% credit on that bill is $422.40, applied to a future invoice, not paid out. It is the same whether the outage hit a quiet Sunday or the board meeting. And it only arrives if you claim it in time, with evidence: AWS asks for the affected five-minute intervals and your request logs, and requires an Enterprise Support plan to be eligible at all. Twilio wants the outage dates and times and supporting documentation within 30 days. Credits below $1 are not issued by AWS.

"Sole and exclusive remedy" closes the loop. All three documents make the credit the only thing you get, which in practice makes it the ceiling on the vendor's liability for downtime.

The counterweight is worth saying plainly. Credits were never meant to compensate you for an outage. They are a signal of how a vendor measures itself and what it is willing to put at risk. A provider with a stricter definition of "available" at 99.9% can be a better bet than one with a loose definition at 99.99%.

What to Ask For Instead

If video is critical, negotiate the definition, not just the number:

• Define availability as join success and media delivery, measured from your users' side, not only API errors.
• Shorten or remove the five-minute floor for real-time services, or add per-incident credits.
• Cover scheduled peaks explicitly, with the quotas and pre-scaling that make them realistic.
• Name the products. The SLA should list the video, recording and TURN services you use.
• Get incident reports. A written root cause within an agreed time is worth more operationally than the credit.

Then measure it yourself. Alerting on join success rate and collecting call-quality statistics gives you the evidence a claim needs, and the early warning the SLA never will.

If you self-host, there is no vendor SLA at all. The number becomes an internal target, the redundancy behind it is yours to build, and the credit is replaced by your own on-call rota.

The Bottom Line

An enterprise video SLA promises less than its percentage suggests. It defines availability its own way, ignores short outages, can exclude your peaks, may not name video, and pays out a credit of around 10% as the only remedy. Read the definition, negotiate it where video is critical, and keep your own measurements, because the contract won't keep them for you.

What's Next

A contract is only as good as the architecture under it. Next: the redundancy that backs the number, and the other checks an enterprise buyer runs.

Frequently Asked Questions

What does a 99.9% enterprise video SLA allow?

About 43 minutes of downtime in a 30-day month. That is enough for one important meeting to fail completely while the SLA is still met. What counts as downtime depends on the document's own definition.

Do video SLAs cover poor call quality?

Not in the three we read. They measure API errors, unavailable minutes or join success. A call that connects but freezes or drops audio isn't counted as downtime.

How much is an SLA credit worth?

Typically 10% of that month's fees for the affected service at the first tier, applied to future invoices. On a $4,224 monthly bill, that is $422.40. Some SLAs step up to 25%, 50% or 100% for longer outages, and most make the credit your only remedy.

Why don't short outages count against the SLA?

Many SLAs exclude unavailability shorter than five continuous minutes or measure in five-minute windows. For real-time video, where a four-minute drop loses a meeting, ask for a shorter floor or per-incident credits.

What should an enterprise ask for in a video SLA?

Availability defined by join success and media delivery, named products, coverage for scheduled peaks, a shorter outage floor and written incident reports. For deployments where Samvyo runs the platform as a managed service, those are the same questions to put to Samvyo.

Does a self-hosted video platform have an SLA?

Not from a vendor. The uptime target becomes your own, and so does the redundancy behind it. Platforms such as Samvyo, which support on-premise deployment, give you control of the media path, TURN and recording, so availability depends on how you run them.

Noise suppression has about ten milliseconds to do its job. Background replacement on a phone takes roughly one whole video frame. Live captions can trail speech by half a second and still be useful. A meeting summary can wait until everyone has left.

All four get sold as real-time AI video, and their deadlines run from milliseconds to minutes. Whether an AI feature adds latency to a call depends less on the model than on where it sits relative to the media: in the path every packet takes, beside it, or after the call.

The Budget Every Feature Shares

A call has a latency budget before any AI arrives. ITU-T Recommendation G.114, the standard reference for one-way delay, says most applications experience essentially transparent interactivity below 150 ms and recommends not exceeding 400 ms. Capture, encoding, network, jitter buffering and decoding already spend part of it; our breakdown of where a call's latency actually goes shows how quickly it fills.

So the question for any AI feature is simple: does the call wait for it?

Three Places an AI Feature Can Sit

Only the first position can add latency to the call. The other two can be slow without anyone's voice arriving late; their delay shows up in how late the captions or insights appear, not in the conversation.

In the Path: Audio Is Cheap

Noise suppression has to run on every chunk of audio, so it is the strictest case. It is also the one that fits most easily.

The RNNoise design, described in Jean-Marc Valin's paper, processes audio in 20 ms windows with a 10 ms step and uses about 40 million floating-point operations per second. A plain C implementation needed around 1.3% of a single core on a 2013 Intel laptop processor, and 14% of one core on a Raspberry Pi 3. Many newer suppressors use larger models, but the class of problem is clear: audio enhancement can live inside the budget on almost any device.

In the Path: Video Eats a Frame

Video is harder, because each frame is a much larger input and the deadline is the frame interval: 33.3 ms at 30 frames per second.

Google's MediaPipe segmentation guide publishes average latencies on a Pixel 6. Its selfie segmenter, the model behind background blur and replacement, takes 33.46 ms on the CPU and 35.15 ms on the GPU for a 256 × 256 input. That is the whole frame interval at 30 fps, before the blur or the composite is drawn.

Teams handle this in three ways. They run segmentation on every second frame and reuse the mask, they pipeline it so frames keep flowing at full rate while each one arrives a frame later, or they drop the frame rate. Each is a trade: a slightly lagging mask, about one frame of added delay, or less smooth video. On phones older than the benchmark device, the numbers get worse.

That is the honest counterweight to "without adding latency": background replacement on a phone usually adds some, and users accept it because privacy is worth a frame. It also shows why device limits shape what AI can run at the edge, the same reason why edge AI alone can't carry a fleet.

Beside the Path: Captions Choose Their Delay

Speech-to-text does not need to sit in the media path. A copy of the audio goes to the model, and the call never waits for it. What the model controls is how far captions trail the speech.

Streaming models make that delay an explicit design choice. Kyutai's open speech-to-text models, per its model card, come in two versions: a ~1-billion-parameter English and French model with a 0.5-second delay, and a ~2.6-billion-parameter English model with a 2.5-second delay. Waiting longer lets the model hear more context before committing to words. These are the developer's own figures for its own models, but they show the trade every captioning system makes between delay and accuracy.

Running it is a server workload. Kyutai's repository says an H100 can process 400 streams in real time, and that it serves 64 simultaneous connections on an L40S GPU at three times real-time speed. That makes transcription a capacity-planning question, not a call-latency question.

After the Call: Summaries Have Minutes

Summaries, action items and meeting-wide sentiment work on the whole conversation, so they run on the recording or the transcript after the call, or periodically during it. Their latency matters to the person waiting for the summary, not to the call. They are also the heaviest models in the list, which is fine: nothing live depends on them.

The Rule That Falls Out

Put the cheap, per-frame work in the path and on the device; put everything that needs a server beside the path or after the call. Routing live media through an inference server before forwarding it adds a network hop plus model time to every packet, which spends the call's budget on a feature the user may not even be looking at. Forking a copy to that server spends nothing.

That leaves one question this post doesn't answer: when the model runs on a server, whose server is it, and what leaves your network? That is the next post.

The Bottom Line

Real-time AI video is four different deadlines under one label. Noise suppression fits in milliseconds on almost any device. Background replacement takes about a frame on a phone and usually adds a little delay. Captions and translation sit beside the call and choose how far they trail. Summaries run after it. Keep the media path for the cheap, local work and fork everything else.

What's Next

Once inference needs a server, the question becomes ownership. Next: where the inference runs and what leaves your network.

Frequently Asked Questions

Does real-time AI video add latency to calls?

Only features that sit in the media path, where every frame waits for the model. Noise suppression adds very little; background replacement on a phone can add about a frame. Captions, translation and summaries run on a copy of the stream or the recording, so the call itself never waits for them.

How fast does AI noise suppression need to be?

Fast enough to process each small chunk of audio before the next arrives, typically every 10 to 20 ms. The RNNoise design uses 20 ms windows with a 10 ms step and needed about 1.3% of one laptop CPU core, so it fits comfortably.

Why does background blur slow down video on some phones?

Segmenting a person from the background takes about 33–35 ms per frame on a Pixel 6 with Google's MediaPipe selfie model, which is the entire frame interval at 30 fps. Apps compensate by skipping frames, pipelining or lowering the frame rate.

How much delay do live captions have?

It is a design choice. Streaming models trade delay for accuracy; Kyutai's open models, for example, use 0.5 seconds and 2.5 seconds. Because captions are produced from a copy of the audio, that delay affects when text appears, not the call.

Where should AI features run on a video platform?

Per-frame enhancement such as noise suppression and background replacement belongs on the user's device. Transcription, summaries and sentiment need a server and should run beside the call or after it. Samvyo's architecture follows that split: noise cancellation and background replacement are designed to run on the device with no server, while transcription, summaries and sentiment run on servers.

Can AI processing on calls stay inside our own network?

It depends on where the server-side models run. On-device features never leave the device. For server-side features, Samvyo's design allows the media servers and AI inference servers to run in the customer's own cloud or on-premise under its licensing plan, which keeps that processing inside the customer's network; this does not apply to its pay-per-use plan.

Turning on live captions can send every word of a board meeting to another company's servers. So can meeting summaries, sentiment cues and translation. The video platform may run entirely on your infrastructure, and the AI on top of it may not.

On-prem AI video means keeping that inference inside your own network. Whether you need it, and what it costs, comes down to one question for each feature: where does the model run? Our post on which AI features can run without adding latency sorted features by deadline. This one sorts them by what leaves the building.

Three Places Inference Can Run

On-device features are private by construction: the audio or frame is processed where it was captured. They are also limited to small models, so the heavier features land on a server. Which server is the decision that matters.

What a Third-Party API Actually Keeps

Sending audio to an AI API is not the same as giving it away. The terms are detailed, and they are getting better. Take OpenAI's API data policy as it read on 14 October 2026:

• API data is not used to train its models unless you opt in.
• Abuse-monitoring logs are kept for up to 30 days by default on most endpoints, including the Realtime API; the audio transcription endpoint keeps none.
• Zero data retention is available for eligible endpoints, including transcription and Realtime, but requires approval.
• Data storage can be kept in several regions, including India, but regional processing is listed only for the US, the EU and the UAE.

That last line is the kind of detail a security review catches. A company in India can keep stored data in India and still have its meeting audio processed abroad. Other providers' terms differ, so read the endpoint-level detail for the provider you use, not the headline policy.

Even with the best terms, the data still leaves your network and the provider becomes a processor of it. For many organisations that is acceptable with the right agreement. For others, the rules about where your media legally has to live make it a non-starter.

Shrink What Leaves Before You Decide Where

The choice isn't all or nothing. Most AI features need far less than the full media:

A design that runs transcription in-house and sends only text to an external summariser exposes far less than one that streams the full call to an API. Removing names or account numbers from the transcript before it leaves narrows it further. Decide the minimum each feature needs, then decide where that minimum is processed.

Running Inference Yourself: What It Costs

Keeping server-side AI in-house turns a per-minute API bill into a capacity plan. Transcription is a GPU workload. Kyutai's open speech-to-text project, in its repository, reports serving 64 simultaneous connections on one L40S GPU at three times real-time speed, and says an H100 can process 400 streams in real time. These are the developer's own figures for its own models.

On those figures, 200 concurrent captioned streams need four L40S GPUs, or one H100 at the higher figure, before redundancy. Peaks matter here as much as for the media servers: if the all-hands is captioned, the GPUs have to cover it.

The other costs are less visible. Someone has to choose, update and evaluate the models. Quality may trail the newest commercial APIs. Summaries and sentiment need language models, which bring their own hardware and tuning. In exchange, nothing leaves, which for some deployments is the only acceptable answer: a deployment with zero internet cannot call an external API at all.

The Condition That Makes "Never Leaves" True

"Video never leaves your network" is a strong claim, and it is only true when every piece that touches the media is inside:

• The media servers. If calls route through a vendor's cloud, the media has already left, whatever the AI does.
• The AI inference servers. Every server-side model, including transcription, summaries and sentiment.
• Recording and transcript storage. Where the output lands matters as much as where it was produced.
• Client-side features. On-device processing keeps them local by design.

If any one of these is a third-party service, the claim no longer holds. When a vendor says media never leaves, ask which deployment and which plan that applies to. It is rarely all of them.

The counterweight belongs here too. For most organisations, a third-party API with zero data retention, regional processing and a processing agreement is a reasonable choice, and often the better model. On-prem AI video is for the cases where the data itself must not leave: regulated industries, government, sovereignty requirements and air-gapped sites.

The Bottom Line

On-prem AI video is a question of where inference runs, feature by feature. On-device work never leaves. Server-side work stays inside only if both the media servers and the inference servers are yours. Third-party APIs send data out under terms that are better than they used to be but still terms. Shrink what each feature needs, then put it where your rules allow.

What's Next

Where the AI runs is one part of a broader deployment choice. Next: on-prem, managed cloud or SaaS, and what each does to your data story.

Frequently Asked Questions

What is on-prem AI video?

Running the AI features of a video platform, such as transcription, summaries and sentiment, on servers inside your own network instead of sending media to an external AI service. It keeps meeting content inside, at the cost of running the GPUs and models yourself.

Does using an AI API for transcription send my meeting audio outside?

Yes. The audio goes to the provider for processing. Terms vary by provider and endpoint. OpenAI, for example, does not train on API data by default; its Realtime API keeps abuse-monitoring logs for up to 30 days unless you are approved for zero data retention, and regional processing is listed only for the US, EU and UAE.

Which AI features can run without any server?

Per-frame features like noise suppression and background replacement run on the user's device, so nothing leaves it. Transcription, summaries and sentiment need server-side models. Samvyo's architecture follows this split: noise cancellation and background replacement are designed to run on the device, while transcription, summaries and sentiment run on servers.

Can a video platform guarantee that video never leaves our network for AI?

Only if the media servers, the AI inference servers and storage all run in your environment. With Samvyo, that claim applies only on its licensing plan, where the customer runs both the media servers and the AI inference servers in its own cloud or on-premise. It does not apply to pay-per-use customers.

How many GPUs does in-house transcription need?

It depends on the model and concurrency. One open-source project reports 64 simultaneous streams on an L40S GPU and 400 real-time streams on an H100. Size for your peak, including large captioned meetings, and add redundancy.

Is a third-party AI API with zero data retention enough?

For many organisations, yes, combined with regional processing and a data processing agreement. Where rules require that media never leaves your control, or the deployment is air-gapped, inference has to run on infrastructure you operate.

"The call was bad" is the whole bug report, most of the time. No timestamp, no network, no idea whether the problem was the user's Wi-Fi, a relay, the server or the camera.

The browser already knows. Every WebRTC session continuously measures packet loss, jitter, round-trip time, frozen video, why the sender lowered quality and whether media is being relayed. getStats() is how you read it. Collecting it across real users in production, rather than in a debugging tab, is what turns a complaint into evidence.

What getStats actually returns

Calling getStats() on a peer connection returns a report: a map of stats objects, each with a type, an ID and a timestamp, and IDs that link related objects together. The W3C specification, a Candidate Recommendation Draft dated 25 September 2025, defines the types, including:

The fields that answer real questions

Most of the report is noise for monitoring. A short list answers the questions incidents actually ask:

qualityLimitationReason is the most underused field. When a user's outgoing video drops to a low resolution, it tells you whether their CPU or their network made that call. That one value usually decides whether the fix is on your side or theirs.

Counters, not rates

Most of these values are running totals since the stream started. A packetsLost of 1,200 means nothing on its own; it might be the first ten seconds or the last ten minutes.

The specification is explicit about how to use them: compute averages "by calling getStats() twice, taking the difference of the two sums and dividing by the difference of the two counts", and for time-based values such as byte counts, divide by the difference in timestamps. In practice that means every sample is compared with the previous one for the same object ID:

const prev = new Map();

async function sample(pc) {

  const report = await pc.getStats();

  report.forEach(s => {

    if (s.type !== 'inbound-rtp' || s.kind !== 'video') return;

    const p = prev.get(s.id);

    if (p) {

      const lost = s.packetsLost - p.packetsLost;

      const recv = s.packetsReceived - p.packetsReceived;

      const lossRate = lost / Math.max(1, lost + recv);

      const kbps = 8 * (s.bytesReceived - p.bytesReceived) / (s.timestamp - p.timestamp);

      emit({ id: s.id, lossRate, kbps, freezes: s.freezeCount - p.freezeCount });

    }

    prev.set(s.id, s);

  });

}

Two details matter. Objects come and go, so a stream ID you saw last time may be gone and a new one may appear. Treat a missing previous sample as "no rate yet", not as zero. And a counter that goes down means the object was replaced; reset rather than recording a negative.

Designing a WebRTC getStats production collector

None of what follows is in a standard. These are design choices, and the right values depend on your traffic and budget.

• Sample on a fixed interval, summarise on the client. Polling every few seconds and sending a compact summary keeps payloads small. Send raw reports only for a small sample of sessions, or on demand.
• Tag every record. Session ID, your own participant ID, browser and version, SDK version, platform and network type. Without tags, evidence cannot be compared.
• Keep a per-session summary. Relayed or not, worst round-trip time, total loss rate, seconds frozen, and the share of time each quality-limitation reason was active. That summary is what support and incident reviews actually read.
• Leave addresses out. Candidate stats include IP addresses. Record the candidate type, not the address, unless you have a specific, documented reason.
• Expect missing fields. Implementations differ, and the spec itself says fields that reveal hardware "MUST NOT exist unless exposing hardware is allowed". A collector that breaks on a missing field will break on the first unfamiliar browser.

If your collector predates Chrome 117

Chrome removed the old callback-based getStats() in version 117, with an origin trial extending it to version 121. Collectors written against it need porting. Chrome's migration guide maps the old names to the standard ones:

One change catches people out: with simulcast, the standard API reports a separate outbound-rtp object for each layer, where the legacy API showed one. A collector that assumes one outbound video stream per sender will under-count what is actually being sent.

What client stats cannot tell you

getStats sees one side of one connection. It cannot see inside your media server, it cannot see another user's network, and on a call through an SFU, a remote participant's problem shows up in your stats only as its effect on the streams you receive. Pair client evidence with server-side metrics and logs before deciding where a problem sits, and treat any single metric as a clue, not a root cause.

The Bottom Line

Every WebRTC session already measures what you need to diagnose it. getStats exposes it as typed, linked objects defined by the W3C spec; most values are cumulative, so rates come from deltas between samples. Collect a small set of fields, sample on an interval, tag everything, leave addresses out, and keep a summary per session. Then "the call was bad" arrives with evidence attached.

What's Next

Evidence matters most at 2am. For what happens on each path when video fails, see who gets paged when video fails.

Frequently Asked Questions

How do I use WebRTC getStats in production?

Sample getStats() on a fixed interval, compute rates from the difference between consecutive samples, summarise on the client and send compact records tagged with session, browser and SDK version. Keep raw reports for a small sample of sessions only.

How can I tell if a WebRTC call is using TURN?

Find the selected candidate pair in the stats report and check the candidate type of its local or remote candidate. A type of "relay" means media is going through a TURN server.

Why are getStats values so large?

Most are cumulative counters since the stream started, such as packets lost or bytes received. Subtract the previous sample from the current one and divide by the time between them to get a rate.

What does qualityLimitationReason mean?

It reports why the sender is limiting its outgoing video quality: none, cpu, bandwidth or other. It is the quickest way to tell whether a low-quality stream is caused by the sender's device or its network.

Does the old getStats API still work?

Not in current Chrome. The legacy callback-based getStats() was removed in Chrome 117, with an origin trial extending it to 121. Collectors using goog-prefixed names need to move to the standard stats objects.

Can I see server-side problems in getStats?

Only indirectly. getStats describes the browser's own connections, so media-server or relay problems appear as their effects on the streams you send and receive. Platforms that keep the media path and TURN on infrastructure you control, such as Samvyo, which is based on SFU architecture, let you put server-side metrics next to client stats for the same session.

On 12 June 2025, for two hours and 28 minutes, Cloudflare's TURN service failed almost every request. Its SFU could not create new sessions, although calls already running carried on. Traffic fell to 20% of normal. The cause, in Cloudflare's own postmortem, was a failure in a third-party storage service underneath one of its internal systems.

Now picture that night three ways: you built your video stack, you bought a cloud API, or you embedded a commercial platform on your own infrastructure. Every path fails sometimes. What the choice actually decides is who gets woken up, whether they can fix it, and what recovery waits on. The architecture differences are in the technical decision guide; this post is about the pager.

Video infrastructure failure modes, in three kinds

Most video incidents fall into one of three groups, and each path owns a different share of them:

• Service failures: the media servers, relays or signalling stop working.
• Dependency failures: something underneath fails, such as the cloud region, a storage service or DNS.
• Change failures: a patch, a security fix or a browser release breaks something that worked yesterday.

Buy: you get paged, they fix it

When a cloud video API fails, your on-call engineer is paged by your own alerts or your customers, and then mostly waits. They can confirm it is the provider, update your status page, and tell customers. They cannot fix it.

The Cloudflare incident shows the shape of a typical failure. Existing calls survived; new ones could not start; the relay layer failed outright for users who needed it. A dashboard that only counts active sessions would have looked half-fine for the first hour. Alerting on join success rate is what catches this kind of outage early.

Then there is the contract. Twilio's API service level agreement commits to 99.95% availability for standard services, which allows about 21.6 minutes of downtime in a 30-day month. Only unavailability of five or more continuous minutes counts, the remedy is a 10% credit on that service's monthly fee, and credits are described as the "sole and exclusive remedy". The document does not name Programmable Video, so check what your own video product is covered by before relying on it.

Buying hands the fixing to people who do it all day, which is usually worth a lot. What it does not hand over is the night itself: your customers still call you.

Build: you get paged, you fix it

Run the stack yourself and every failure is yours to diagnose and fix, including the ones that are not really about video.

• Your cloud fails. From 11:48 PM PDT on 19 October to 2:20 PM PDT on 20 October 2025, about 14.5 hours, AWS us-east-1 suffered a disruption that started with an empty DNS record for DynamoDB and spread to services including EC2 and Network Load Balancer. A video stack built in that region inherited it.
• Your relays need patching. coturn, the standard open-source TURN server, had a published access-control bypass in versions 4.5.1.x, announced 11 January 2021 and fixed in 4.5.2. Finding, testing and rolling out that patch across every relay is your job.
• Browsers change underneath you. Chrome removed the legacy callback-based getStats API in version 117. Any monitoring built on it stopped returning data unless someone on your team had migrated it first.

The upside is real: you can see everything, change anything, and fail over on your own terms. Recovery time is set by your team's depth, which is the part that has to be staffed around the clock.

Embed: the pager is split

Running a commercial platform on your own infrastructure divides the work. You own the infrastructure, so cloud failures, capacity and networking are yours to see and act on immediately. The vendor owns the software, so a bug in the media server or SDK waits on their fix, delivered as a release you then roll out.

This is reasoning about responsibility, not a measured result, and the details depend on the support contract. The questions to ask a vendor are concrete: who is on call for software defects, what the response time is at 2am in your time zone, and how emergency fixes reach infrastructure they do not operate.

What to watch, whichever path you take

Some failure modes exist on every path: client networks, blocked ports, bad Wi-Fi. Monitoring should separate those from platform failures. A starting set, offered as design choices rather than standards:

• Join success rate. The fastest signal for outages like Cloudflare's, where existing calls hide the problem.
• Signalling connected versus media connected. A session that joins but never gets media points at the media path or relay, not at login.
• Relay share. A sudden rise usually means something changed in the network path, not in your users.
• Client-side quality. Round-trip time, loss, freezes and why the sender reduced quality, collected from the browser across real sessions.

The honest counterweight

For most teams, buying is the more reliable option in practice. A provider running video for thousands of customers has more people, more regions and more incident practice than a small team can staff. Handing them the pager is often exactly right.

What you give up is control of the timeline. When the provider is down, you wait; when their priorities change, you adapt. A failure you cannot fix is one of the few good reasons to leave a provider, and it is worth knowing in advance what you would rewrite to leave.

The Bottom Line

Video infrastructure failure modes are the same on every path: services fail, dependencies fail, and changes break things. Build, buy and embed decide who is paged, who can fix it and what recovery waits on. Buying hands over the fixing but not the night; building gives you every lever and every pager; embedding splits them at the line between infrastructure and software. Alert on join success, read the SLA's remedy clause, and decide which of those trades your team can actually staff.

What's Next

Every incident starts with evidence from real sessions. Collecting getStats evidence in production covers how to gather it from the browser before you need it.

Frequently Asked Questions

What are the main video infrastructure failure modes?

Three kinds: service failures in media servers, relays or signalling; dependency failures in the cloud, storage or DNS underneath; and change failures from patches, security fixes and browser releases. Client network problems sit on top of all three and exist on every path.

What happens to my app when my video API provider has an outage?

Usually you cannot fix it, only detect it and communicate. In Cloudflare's 12 June 2025 incident, calls already running continued while new sessions failed, so monitoring join success rather than active sessions is what shows the outage early.

What does a 99.95% SLA actually allow?

About 21.6 minutes of unavailability in a 30-day month. Under Twilio's API SLA, only outages of five or more continuous minutes count, and the remedy is a 10% service credit described as the sole and exclusive remedy.

Is self-hosted video less reliable than a cloud API?

Not inherently, but reliability depends on your team. You inherit your cloud's failures, every security patch and every browser change, and recovery time is set by how many people can respond at 2am.

Who is responsible for incidents with an embedded video platform?

Usually split: you own the infrastructure it runs on, the vendor owns software defects. With Samvyo, which is based on SFU architecture and resilient by design, the media path, TURN and recording run on infrastructure you control, so infrastructure incidents are visible to your team directly; agree software support terms before go-live.

What should a video on-call engineer monitor?

Join success rate, signalling versus media connection, relay share, and client-side quality metrics such as round-trip time, loss and freezes. Thresholds should come from your own baseline rather than a generic number.

Two posts on this blog give the same advice in a single sentence. Wrap the SDK so "join", "publish" and "record" are your verbs, and a future migration becomes an adapter swap. Put a thin layer of your own in front of it, and it turns a re-platform from a rewrite into a swap of one adapter.

Both are right, and neither shows how. A video SDK abstraction layer that actually holds is more than a wrapper class around the vendor's client. It has four sides, and the one most teams skip is the one that makes leaving expensive.

What a video SDK abstraction layer is, and what it is not

The pattern has a name. Alistair Cockburn described it in 2005 as ports and adapters, with the aim of letting an application be "developed and tested in isolation from its eventual run-time devices and databases". Your product talks to a port it defines. Each provider gets an adapter that implements that port. The provider's types never cross into the rest of your code.

What it is not: a promise that switching becomes free, or a lowest-common-denominator API that hides every useful feature. The goal is narrower. When you do switch, the change should be one adapter and its tests, not every file that touches video.

The four sides of the seam

The layers of what a provider switch rewrites tell you where the seam has to run:

Most "wrap the SDK" advice covers only side one. Sides three and four are what turn a migration into an archive project.

Side 1: the client interface

Start from what your product does, not from what the SDK offers. An illustrative interface, in TypeScript:

interface VideoSession {

  join(room: RoomId, token: SessionToken): Promise<void>;

  leave(): Promise<void>;

  publish(source: 'camera' | 'microphone' | 'screen'): Promise<LocalTrack>;

  subscribe(who: ParticipantId, quality: QualityHint): Promise<RemoteTrack>;

  on<E extends SessionEvent>(event: E, handler: Handler<E>): Unsubscribe;

  capabilities(): Capabilities;

}

Four rules make it hold:

• Your IDs, not theirs. RoomId and ParticipantId are your types. The adapter maps them to whatever the vendor uses.
• Subscription is in the interface, with a quality hint. On some providers what each user receives is a pricing decision: Agora, for example, bills on the total resolution each user subscribes to. If subscription control lives inside the vendor's UI kit, so does your bill.
• Limits are declared, not discovered. capabilities() reports what this adapter can do: maximum rendered videos, maximum resolution, screen share support. Zoom's web SDK, for instance, renders up to 25 videos on desktop and 4 on mobile. Your layout code reads the number instead of assuming it.
• No vendor types in UI state. If a vendor's participant object ends up in your state store, the seam has a hole in it, and every component that reads that store is now part of the migration.

Side 1, continued: your events, your meanings

Events are where seams leak. Define your own vocabulary (participantJoined, participantLeft, trackAvailable, activeSpeakerChanged) and decide what each one means in your product.

Then make the adapter responsible for that meaning, not just the name. Zoom's active-speaker event fires once someone has been talking for more than a second; another provider's may use a different rule. If your product needs a specific behaviour, such as a 1.5-second hold before the speaker view switches, implement it in your layer, once, so it stays the same when the adapter changes.

Side 2: one server-side seam

Every provider needs a backend to issue credentials, and each issues a different kind. Put all of it behind one service you own:

• One token endpoint. Your client asks your backend for a session token for a RoomId. Which vendor format comes back is the adapter's business.
• One room lifecycle. Create, end and look up rooms through your API, keyed on your IDs.
• One webhook intake. Vendor callbacks arrive at an adapter that translates them into your own events and writes them to your own store. The rest of your backend never parses a vendor payload.

Sides 3 and 4: identity and recordings

These are the sides that make leaving expensive, and the cheapest to get right on day one.

Identity. Keep a mapping table from your room and participant IDs to each vendor's, with timestamps. Support tickets, analytics and audit trails reference your IDs. When the provider changes, the history still resolves.

Recordings. Write them to storage you own from the first recording. Twilio can send recordings to your own S3 bucket instead of its cloud; Daily can write directly to your bucket without storing them at all. Reference recordings by your own IDs and paths. Then a provider switch changes where new recordings come from, not where old ones live.

Proving the seam

A seam with one adapter is a hypothesis. Two things turn it into a fact.

• A contract test suite written against the interface, not the vendor: join, publish, subscribe at each quality hint, receive each event, leave. Every adapter must pass it.
• A second adapter. It does not have to be a second provider. An in-memory fake that passes the same contract tests proves that nothing outside the adapter depends on the vendor, and it is exactly the "tested in isolation" that ports and adapters were described for.

If the fake cannot pass without changes elsewhere in your code, you have found the leak before a migration did.

What the seam costs

The honest part: an abstraction layer is a component you maintain, and it has real costs.

• It lags the vendor. A new SDK feature is not available to your product until someone exposes it through the interface.
• It can flatten useful differences. The fix is capabilities, not a smaller interface: expose provider-specific features as optional capabilities your UI can check for.
• Prebuilt UI kits sit outside it. A vendor's drop-in meeting UI is the fastest way to ship, and it puts the vendor's components straight into your interface. When Dyte became RealtimeKit, its UI kits were renamed along with everything else. If you use one, accept that the UI is part of any migration.

So the seam is not always worth building. A product that embeds a vendor UI on one screen, at low volume, may be better off shipping and accepting the rewrite risk. The seam earns its cost when video is core to the product, when the integration is custom, or when your provider could be acquired, deprecated or shut down on a timeline you do not control.

Where to draw the line

The Bottom Line

A video SDK abstraction layer is a port your product owns and an adapter per provider. To hold, it has to cover four sides: client verbs and events, the server that issues tokens and receives webhooks, your own identity, and recordings in your own storage. Prove it with contract tests and a second adapter, accept that it costs maintenance, and build it before the code spreads, because afterwards it is a migration of its own.

What's Next

A seam decides how expensive it is to leave. The other half of the decision is who gets paged when it fails under each path, and how long recovery takes.

Frequently Asked Questions

What is a video SDK abstraction layer?

An interface your application owns for joining calls, publishing and subscribing to media, handling events and recording, with one adapter per video provider that implements it. The provider's types stay inside the adapter, so changing provider means changing one adapter rather than every file that touches video.

Does an abstraction layer make switching video providers free?

No. It turns the switch into writing and testing one new adapter, plus whatever provider-specific capabilities your product relies on. It also helps most when identity and recordings are already under your control, since those are the parts code changes cannot fix.

What should a video SDK interface include?

At minimum: join, leave, publish, subscribe with a quality hint, an event subscription using your own event names, and a capabilities call that reports limits such as maximum rendered videos. On the server side: one token endpoint, room lifecycle and webhook intake.

How do I test a video abstraction layer?

Write contract tests against your interface, not the vendor, and run every adapter through them. An in-memory fake adapter that passes the same tests proves that nothing outside the adapter depends on the provider.

Should I use a video provider's prebuilt UI kit?

It is the fastest way to ship, but it puts the vendor's components directly into your product, outside any abstraction layer. If you use one, treat the UI as part of any future migration.

Does Samvyo work behind an abstraction layer?

Yes, the same way as any provider. Samvyo, based on SFU architecture, ships embeddable SDKs like a cloud video API, with the media path, TURN and recording kept on infrastructure you control, which means the recording side of the seam is already in your own storage.

When Dyte became Cloudflare RealtimeKit, its customers did not choose a new provider. Their provider changed its name. Every package, every class prefix and every HTML tag in their code changed anyway, and the old SDKs went into maintenance mode, which in Dyte's own words means they "will no longer receive feature updates or bug fixes".

If a rename forces a rewrite, a real switch does more. This post is the inventory of what changes, layer by layer, taken from three migration guides the vendors wrote themselves. Whether to switch at all, and why providers exit, is covered in what happens when a video API provider is acquired or shuts down. This is about the work once you have decided.

Where video provider migration cost actually sits

The media itself is the easy part. Every provider moves WebRTC audio and video in broadly the same way. What you rewrite is everything your product built around one vendor's version of it:

Layer 1: the object model

Providers agree on the idea of rooms, tokens and tracks and disagree on almost everything else. Vonage calls the room a Session and gives clients publisher or subscriber roles. LiveKit has a Room, Participants and Tracks. Twilio has Rooms, Participants and Tracks too, but Zoom's Video SDK does not.

Zoom's own Twilio migration guide treats the move from Twilio's track-based model to Zoom's stream-based one as a fundamental architectural change, not a rename. There is no participant object; the current user comes from a function call. Code that loops over each video track to stop a camera becomes one call to stopVideo(). A single connect() becomes init() followed by join().

None of this is hard individually. The cost is that it is everywhere your product touches video, which is usually more places than anyone listed.

Layer 2: tokens and the server that mints them

Every provider needs your backend to issue credentials, and no two issue the same kind. Moving from Twilio to Zoom replaces Twilio's JWT with a Zoom JWT whose payload is different, and whose session-name claim has to match the session the client joins. Moving from Twilio to Amazon Kinesis Video Streams, in AWS's own guide, replaces the access token with temporary IAM credentials, Twilio's video grant with channel permissions, and the backend's room-creation endpoint with a signaling-channel endpoint.

So a provider switch is a backend change, not just a client one. Your token service, room creation, permissions model and any webhook handlers all move with it.

Layer 3: events, the part that breaks quietly

Event names change, and the mapping is rarely one to one:

Renaming is the easy part. The risk is meaning. Zoom's guide notes that its speaker event fires when someone has been talking for more than a second, a rule worth checking against whatever your current provider does. A speaker-view layout tuned against one trigger can feel wrong against another, with no error anywhere. This is the layer where migrations pass every test and still generate support tickets.

Layer 4: rendering limits that change the product

Some differences are not code at all. The Zoom guide states that its web SDK "can render up to 25 videos at a time on desktop browsers, and 4 videos on mobile browsers", with 720p as the maximum rendering quality on web.

If your product shows a larger gallery, or relies on higher resolution, the migration is now a product decision. A provider's limits become your feature set, and sales finds out when a customer asks why the 30-person view disappeared.

Layer 5: the data you already hold

Code can be rewritten in a sprint. History cannot. By default, Twilio stores recordings in its own cloud; you can switch new recordings to your own S3 bucket, after which "Twilio will stop storing" them in its cloud, but recordings made before the switch stay where they were. Daily offers the same choice up front: with a custom bucket, it does not store the recording on its own servers at any point.

That one setting decides whether migration includes an archive project. Recordings, their metadata, the room and participant IDs your support and compliance teams reference: all of it has to be exported, re-linked and kept for as long as your retention policy says, in a format the new provider did not create. This is the part of what integrating a video SDK commits you to that arrives last and lasts longest.

Even a rename is a migration

Back to Dyte. Its RealtimeKit migration guide lists nine package replacements, from @dytesdk/web-core to @cloudflare/realtimekit and down through the UI kits, React Native, virtual background and recording SDKs. Class names lose the Dyte prefix for RealtimeKit or RTK; every dyte- HTML tag becomes rtk-.

This is the mildest migration there is: same team, same product, same concepts. It still touches every file that imports the SDK, and the maintenance-mode notice sets the deadline for you. That is the general shape of a forced move: the scope is yours, but the timeline is someone else's.

The honest counterweight

Not every migration is expensive, and not every one is necessary.

The work scales with how much of your product touches the SDK. A product that embeds a vendor's prebuilt meeting UI in one screen migrates in a fraction of the time of one that built custom layouts, moderation and recording workflows on raw tracks. And the reason to move can disappear: Twilio announced Programmable Video would end on 5 December 2024, extended that to December 2026, then on 21 October 2024 reversed the decision entirely. Teams that migrated early paid for a move that turned out to be optional.

The lesson is not "never depend on a provider". It is that the cost of leaving is decided long before you leave, by how far the provider's objects spread through your code.

Estimating your own video provider migration cost

• Count the touchpoints. Search the codebase for every import of the SDK and every provider type that crosses into your own state or UI.
• List the server endpoints. Token minting, room creation, webhooks, recording controls, analytics.
• Map every event you listen to, and write down what it means today, not just its name.
• Check the new provider's limits against your largest layout, highest resolution and platforms.
• Inventory the data: recordings, where they are, how long you must keep them, and how they are referenced.

The answer to each is your migration scope. If the first item returns hundreds of files, the problem is not the provider. It is that there is no seam between the provider and your product.

The Bottom Line

Moving video providers rarely rewrites the media. It rewrites the object model, the token service, the event handling and the UI limits your product was built around, and it leaves an archive of recordings in the old provider's place and format. Even a rename touches every import. The cost of leaving is set on the day you integrate, by how far the provider's objects reach into your code.

What's Next

This is the problem; the prevention is a seam. The Seam shows how to put video behind your own interface on day one, so the next switch is an adapter rather than a rewrite.

Frequently Asked Questions

What does it cost to migrate between video providers?

There is no public benchmark in time or money, because it depends on how much of your product touches the SDK. The work falls into five layers: the SDK object model, the token service, event handling, rendering limits, and the recordings and IDs you already hold. Counting your touchpoints in each is the most reliable estimate.

What has to be rewritten when switching video SDKs?

Client code that uses the provider's room, participant and track objects; the backend that issues tokens and creates rooms; every event handler; and any UI built around the provider's rendering limits. Zoom's Twilio migration guide, for example, lists nine separate changes for the web SDK alone.

What happens to my recordings if I change video providers?

They stay where the old provider stored them unless you move them. If recordings were written to the provider's cloud, migration includes exporting them and keeping them for your retention period. Writing recordings to your own storage from the start avoids this.

Is Twilio Video shutting down?

No. Twilio announced an end date for Programmable Video, extended it to December 2026, and on 21 October 2024 reversed the decision, saying Twilio Video will remain a standalone product.

How can I reduce video provider migration cost?

Keep the provider's objects behind an interface your product owns, issue tokens from one service, normalise events into your own vocabulary, and store recordings in your own bucket. Platforms that keep the media path, TURN and recording on infrastructure you control, such as Samvyo, which is based on SFU architecture, also keep the archive under your ownership rather than a provider's.

Does renaming an SDK count as a migration?

In practice, yes. Dyte's move to Cloudflare RealtimeKit replaced nine packages and renamed classes and HTML tags, and the old SDKs stopped receiving bug fixes, which sets the deadline for you.

The price page says $4,224 a month. Record every room and the same workload bills $11,088 before a single file is stored.

That gap is why a video infrastructure cost breakdown needs more than a rate card. Every video bill has five lines: minutes, egress, relay, recording and storage. Each one already has its own post on this blog. This one does the thing those posts do not: puts all five into one total for one workload, both bought per minute and run yourself.

The workload

One example, used for every line:

That is 1,056,000 participant-minutes, 17,600 participant-hours and 4,400 room-hours a month. The same workload runs through every line below.

Line 1: minutes

On per-minute pricing this is the headline: 1,056,000 participant-minutes at $0.004 is $4,224 a month. Why the count is participants rather than meetings, and where it multiplies further, is covered in what each participant-minute actually counts.

If you run the media yourself there is no minute meter. The cost moves into the lines below, and into servers. That trade is where a flat licence would cross over.

Line 2: egress

Every participant receives three streams. At 600 kbps each, that is 0.81 GB per participant-hour, and 14,256 GB a month leaving the media servers. Outbound traffic, not inbound, is what is billed, which is why SFU bandwidth cost grows with viewers, not publishers.

At AWS list rates ($0.09/GB for the first 10 TB, $0.085 for the next 40), that is about $1,260 a month when you run it. On per-minute pricing it is inside the $4,224.

Line 3: TURN

Some participants cannot reach the media server directly and go through a relay, and a relayed stream leaves your infrastructure twice. The only public measurement, 22% of conferences from callstats.io in 2015–16, is an upper bound, not a forecast for traffic that goes through an SFU, so treat this line as a ceiling.

At 22%, the relay carries about 3,140 GB a month. What that costs depends entirely on who runs it:

Same traffic, a spread of nearly eight times. Why this line is missing from most self-hosting models is the subject of the self-hosted cost nobody forecasts.

Line 4: recording

Recording is the line that changes the shape of the bill. On Twilio's published rates, recording each participant's tracks costs the same as the call ($0.004 per participant-minute) and composing them into one file adds $0.01 per room-minute:

With recording, the Twilio-priced workload goes from $4,224 to $11,088 a month, 2.6 times the headline. Run it yourself and recording becomes compute for recording workers instead of a meter, plus the storage below.

Line 5: storage

A composite file at 2 Mbps is 0.9 GB per room-hour, so this workload adds 3,960 GB of recordings every month. Storage is the only line that grows by itself: each month's files sit on top of the last.

Two choices move this line more than any rate: the retention period, and the storage class. Both are worked through in the bill your retention policy controls. Where the files live is a choice too: Twilio, for example, can write recordings to your own S3 bucket instead of its cloud.

The lines with no rate card

Run the media yourself and two more lines appear that no price page covers: the servers (media servers, TURN, recording workers, all with headroom for peaks) and the people who run them. We have not priced servers here, because instance sizing depends on the media server and the workload. Both lines are worked through in what running it yourself actually costs.

The video infrastructure cost breakdown, in one table

Read it carefully, because it is easy to misread. The self-run column is not cheaper; it is incomplete, and the missing lines are the expensive ones. What the table does show is where the money goes in each model: on per-minute pricing, recording more than doubles the bill; when you run it, egress and storage are modest and the open question is the servers and the team.

And the counterweight: drop recording and the per-minute bill is $4,224 with no operations burden at all. For a lot of teams that is the right answer.

The Bottom Line

A video bill is five lines, not one rate. For 100 people in calls all working day, minutes are $4,224 a month at list price; recording every room takes that to about $11,000, and storage then grows every month you keep the files. Run it yourself and the metered lines shrink to about $1,500 to $1,600, while servers and people become the bill. Price all five lines, in both models, before comparing anything.

What's Next

Cost is one half of the decision; control is the other. For how the three paths compare on speed, unit economics and white-label rights, see build, buy or embed.

Frequently Asked Questions

What does a video infrastructure cost breakdown include?

Five metered lines: participant-minutes, egress, relay (TURN), recording and storage. If you run the media yourself, add servers and the people who operate them. Per-minute platforms bundle egress and usually relay into the minute rate, but meter recording and storage separately.

How much does recording add to a video bill?

On per-minute platforms, often more than the calls. On Twilio's list prices, recording every participant costs the same as the call, and composing a single file adds $0.01 per room-minute, which takes a $4,224 workload to $11,088 a month before storage.

How much does video egress cost?

It depends on what each participant receives. Three 600 kbps streams per person is 0.81 GB per participant-hour; 100 people for 8 hours a day, 22 days a month is about 14,256 GB, roughly $1,260 at AWS list rates.

How much does a TURN server add to video costs?

A relayed stream leaves your infrastructure twice, so relay adds the relayed share of your egress again. At the 22% upper bound, that is about $160 to $270 a month in this example on managed or self-run relays, and around $1,250 at $0.40/GB.

Why does video recording storage keep getting more expensive?

Because storage accumulates. Each month's recordings are added to those you are still retaining, so with a 12-month policy the twelfth month stores twelve months of files. Retention period and storage class matter more than the per-GB rate.

Is self-hosting video cheaper than per-minute pricing?

The metered lines usually are, but they are not the whole bill. Servers and the engineers who run them are lines no price page covers, and they have to be added before the comparison is fair. Samvyo, based on SFU architecture, is offered with flat licensing and keeps the media path, TURN and recording on infrastructure you control, so the egress and storage lines above become your cloud bill rather than a per-minute meter.

$42.24. That is what one seat costs a month on per-minute pricing if someone is in a call eight hours a day, 22 working days a month, at $0.004 a participant-minute. Every flat vs usage video pricing decision comes down to that number, multiplied by how many seats are busy at once, compared with a quote.

The usual advice is that flat licensing gets cheaper somewhere around 100 to 200 concurrent users. That can be true, but stated like that it cannot be checked. This post does the arithmetic from published prices, compares the main buying models at identical usage, and shows what moves the line.

Five ways video infrastructure is sold

That last row matters. Because flat prices are quoted rather than published, the honest way to compare them is backwards: work out what your usage costs on each meter, and that is the number a flat quote has to beat.

Flat vs usage video pricing: the one equation

A per-minute bill is participant-minutes × rate, and what the meter actually counts matters before any comparison. For a steady workload, it is easier to think in concurrent seats: one person continuously in a call.

One seat, eight hours a day for 22 days, is 10,560 participant-minutes a month. At $0.004 that is $42.24. A flat licence at fee F breaks even at F ÷ $42.24 concurrent seats. Everything else is that equation with different inputs.

So "flat gets cheaper at 100 to 200 concurrent" really means: flat wins if the quote is below roughly $4,200 to $8,400 a month at list price, or below $1,600 to $3,200 once a per-minute provider's deepest discount applies. If someone quotes you a crossover in users, ask for the fee behind it and run the division yourself.

Crossover one: per minute vs per user

Per-MAU pricing charges for a person once a month, however much they use it. At $0.99 per MAU against $0.004 per participant-minute, the crossover is:

$0.99 ÷ $0.004 = 247.5 minutes per user per month, a little over four hours.

This one depends on how each person uses the product, not on total volume. An employee in three one-hour meetings a week uses about 13 hours a month: $3.12 per-minute against $0.99 per user, so per-user wins by three times. A patient with one 20-minute consultation a month costs $0.08 per-minute against $0.99 per user, so per-minute wins by twelve times. Same total minutes can go either way depending on whether they come from a few heavy users or many light ones.

Crossover two: per minute vs per gigabyte

Per-gigabyte pricing charges for data leaving the platform, not for people. That makes the crossover depend on how many streams each person receives and how heavy they are.

Assume 600 kbps per received video stream, a typical forwarded bitrate used in our TURN cost model. That is 0.0045 GB per stream-minute, or $0.000225 at $0.05/GB. Against $0.004 per participant-minute:

$0.004 ÷ $0.000225 ≈ 18 received streams per participant.

Below about 18 streams per person, per-gigabyte is cheaper. A four-person call (three streams each) costs about $0.0007 per participant-minute instead of $0.004, close to six times less. A webinar viewer receiving one stream is cheaper still. A 25-tile gallery view is past the line. The assumption carries the result, though: at 1.5 Mbps per stream the crossover falls to about 7 streams. On per-gigabyte pricing, resolution and layout are pricing decisions, the same lesson as resolution-tiered per-minute plans.

Crossover three: a platform fee with minutes included

Hybrid plans sell a block of usage for a fixed fee, then meter what is above it. LiveKit's $50 plan includes 150,000 WebRTC participant-minutes, which would cost $600 at a $0.004 list rate; its $500 plan includes 1.5 million, worth $6,000 at that rate.

Against pure per-minute pricing, the $50 plan pays for itself after 12,500 minutes. Two caveats keep it honest: these plans also meter downstream bandwidth beyond an allowance ($0.12/GB after 250 GB on the $50 plan), and overage minutes are cheap ($0.0005), which makes the comparison above the included block mostly a bandwidth question.

Four things that move the line

Every crossover above is a clean division. Real decisions are messier in four predictable ways.

• Peak versus average. Per-minute bills follow average usage; flat licences and capacity are usually sized for peak. A system that peaks at 200 concurrent but averages 60 runs a per-minute bill of about $2,530 a month, not $8,450. Compare the quote with the average-driven bill, not the peak.
• Discounts. List rates are rarely what large customers pay. Daily's published tiers go to 63% off, which moves every per-minute crossover up by about 2.7 times.
• What the flat price leaves you to run. A flat licence for software you host still leaves servers, egress, relay and storage on your bill. Compare like with like, using what running it yourself actually costs.
• Add-on meters. Recording, composition and transcription are usually metered separately on per-minute plans and may or may not be included in a flat licence. Put them on both sides of the comparison.

And the counterweight: if usage is low, spiky or unproven, per-minute pricing is usually right, whatever the crossover says. There is no idle cost, and you are not committing to capacity you might not need.

Running it on your own numbers

• Measure average concurrent participants and the hours they are active. Note the peak separately.
• Convert to participant-minutes a month, and to monthly active users if per-user pricing is an option.
• Price that usage on each meter at your negotiated rate, adding the add-ons you actually use.
• Put the flat quote next to it, plus whatever the flat option leaves you to run.
• Repeat at your expected volume a year from now. The crossover that matters is the one you are heading towards.

The Bottom Line

Flat vs usage video pricing has no universal crossover, only an equation: a flat fee breaks even at the fee divided by what one busy seat costs on the meter, $42.24 a month at $0.004 for eight hours a day. Per-user pricing wins above about four hours per person per month, and per-gigabyte pricing wins while each person receives fewer than about 18 streams at 600 kbps. Run the division with your own average usage, not your peak, before believing any quoted threshold.

What's Next

Minutes are only one line of the bill. What your video bill actually adds up to puts minutes, egress, recording, relay and storage into one total for one worked example.

Frequently Asked Questions

Is flat licensing cheaper than per-minute video pricing?

Only above a certain usage. At $0.004 per participant-minute, one participant in calls eight hours a day for 22 days costs $42.24 a month, so a flat licence is cheaper once your average concurrent participants exceed the licence fee divided by $42.24. Below that, per-minute is cheaper.

At what point does flat vs usage video pricing cross over?

Divide the flat monthly fee by the per-minute cost of one busy seat. At list price, 100 average concurrent participants cost $4,224 a month and 200 cost $8,448, so a flat quote below those figures wins at that usage. Volume discounts raise the crossover.

What is per-MAU pricing for video?

Per monthly active user pricing charges once for each person who joins at least one call in a month, regardless of how long they use it. At $0.99 per MAU against $0.004 per minute, it is cheaper for anyone using more than 247.5 minutes a month.

Is per-GB video pricing cheaper than per-minute?

For small calls and broadcasts, usually yes. At $0.05/GB and 600 kbps per stream, per-gigabyte pricing is cheaper until each participant receives about 18 streams. Higher bitrates bring that point down, so large high-resolution galleries can be cheaper per minute.

Should I compare a flat licence against peak or average usage?

Against average. Per-minute bills follow average usage, while a flat licence is a fixed cost whatever the usage. Comparing a flat quote with a peak-based per-minute estimate overstates the savings.

What does flat licensing for video usually include?

It varies, so ask. A flat licence for software you deploy may cover the media platform but not the servers, egress, relay or storage it runs on. Samvyo, based on SFU architecture, is offered with flat licensing and keeps the media path, TURN and recording on infrastructure you control, so those running costs sit on your own cloud bill and should be added to the comparison.

The gap is not the rate. It is what each provider counts. Per participant minute pricing looks like one small number, usually around $0.004, but the bill is that number multiplied by a count, and the count grows faster than the meeting does. This post takes the meter apart. For what it adds up to over a month at enterprise scale, see what enterprise teams actually pay per minute at scale.

What per participant minute pricing actually counts

The unit is simple once it is written down. Twilio defines a participant-minute as "the time that a participant remains connected to a Video Room, measured in minutes". Daily puts it as the number of participants multiplied by the meeting length.

So the first multiplier is the number of people. A thirty-minute meeting with four people is 120 billable minutes. The meeting lasts half an hour; the bill counts two hours. Add a fifth person and the same meeting is 150.

Most published rates sit in a narrow band once you line them up:

If the count stopped at people, budgeting would be easy. It does not.

Multiplier two: what each person receives

Some providers do not bill the person at all. They bill what the person subscribes to.

Agora says plainly that it calculates usage "based solely on a user's subscriptions in the channels they join. Whether they publish streams does not matter." The rate then depends on the aggregate resolution of everything that user is watching at once, the total pixels across every video tile on their screen. Under Agora's published rules, up to 921,600 pixels (one 720p stream) is billed as HD; up to 3,686,400 is billed as 2K.

Now take the four-person call in a gallery view. Each person watches the other three. If those three tiles are sent at 720p, each viewer is receiving 2,764,800 pixels, which is the 2K tier at $15.99 per 1,000 minutes. Send the same tiles at 360p and the total is 691,200 pixels, billed as HD at $3.99. Same call, same people, four times the rate, decided by a layout setting.

ZEGOCLOUD shows the other version of the same idea. Its former billing method counted every stream each user subscribed to: "total service minutes = N × (N-1) × M". Five people talking for ten minutes was 200 service minutes under that rule, against 50 under the per-user method it uses now.

Streams are the number to watch, because they grow much faster than people:

Even where your provider bills per person, this quadratic is still in the system. It is the reason media server bandwidth scales with viewers, not publishers, and someone pays for it somewhere.

The practical consequence for a buyer: on subscription-based pricing, decisions that look like product design, such as the default gallery size, the tile resolution or whether screen share is on, are pricing decisions.

Multiplier three: every add-on runs its own meter

The base rate covers people being connected. Almost everything else is metered separately, and the meters do not share a unit.

• Per participant. Twilio charges $0.004 per participant-minute to record individual tracks, the same rate as the call itself. Daily bills real-time transcription at $0.0059 per unmuted participant-minute.
• Per room. Twilio charges $0.01 per composed minute to turn those tracks into one video file. Daily charges $0.01349 per recorded minute; Vonage $0.0363 per minute for an HD composed archive.
• Per gigabyte or per day. Storage, egress and relay traffic sit outside the minute meter entirely.

On the same four-person, thirty-minute call on Twilio's list prices: the call is $0.48, recording every participant adds $0.48, and composing one file adds $0.30. Recording alone takes the bill from $0.48 to $1.26, more than 2.6 times the headline. Storage, egress and relay come on top; they are priced line by line in what your video bill actually adds up to.

One call, seven price lists

Put the three multipliers together and the same thirty minutes looks like this at list price, before free tiers or volume discounts:

None of these numbers is large. That is the trap. Per participant minute pricing is designed to look like a rounding error per call, and it is one. The bill is what happens when every multiplier above is applied to every call, every day.

When per participant minute pricing is the right deal

This is not an argument against the model. For a lot of products it is the best one available.

There is no idle cost: a month with no calls costs nothing, and most providers include free minutes (Daily and Agora each list 10,000 a month). Volume discounts are real; Daily's graduated pricing reaches 63% off list. And relay, scaling and operations are bundled into the rate rather than becoming your team's job. For low, irregular or early-stage volume, that is hard to beat.

The trap is narrower than the model. It is budgeting with meeting-minutes × rate, when the real formula is:

participants × minutes × rate for the billing unit, plus every add-on on its own meter.

What to check on a per participant minute price page

Six questions turn a headline rate into a forecast:

• What is the billable unit? A connected participant, a subscribed stream, or the aggregate resolution a user receives?
• Is audio-only cheaper? Some providers charge less for it (RealtimeKit, Daily); some charge the same (Azure, Chime).
• What is the rounding increment? Chime bills in six-second increments; check whether others round up to the minute.
• Which add-ons are per participant and which per room? Recording, composition and transcription rarely share a unit.
• Is relay traffic included? Twilio lists TURN relay as included; on per-gigabyte models, relay traffic is a cost of its own.
• Where do discounts start? List price is rarely the price at volume, so ask for the tier table, not the headline.

The Bottom Line

Per participant minute pricing bills people, and sometimes the streams between them, not meetings. Every extra person multiplies the minutes, subscription-based models multiply them again by what each person watches, and recording and transcription each run their own meter. Model the count before the rate, and the bill stops being a surprise.

What's Next

Once you can count the minutes, the next question is when paying for them stops making sense. The crossover math compares per-minute, per-user, per-gigabyte and flat pricing at the same usage.

Frequently Asked Questions

How does per participant minute pricing work?

You are billed for each participant for each minute they are connected. A 30-minute call with four people is 120 participant-minutes; at $0.004 that is $0.48. Some providers instead bill what each participant subscribes to, which can raise the count further.

Why is my video API bill higher than I expected?

Usually because the forecast multiplied meeting length by the rate. The real count is participants × minutes, sometimes multiplied again by subscribed streams or resolution tiers, plus recording, composition and transcription on separate meters.

Is audio billed the same as video?

It depends on the provider. Azure Communication Services bills audio and video at the same rate, and Amazon Chime SDK bills per attendee regardless of media. Others publish lower audio-only rates, such as Cloudflare RealtimeKit at $0.0005 against $0.002 for video.

Does video resolution change the per-minute price?

On some pricing models, yes. Agora bills each user on the total resolution of all the streams they receive, so three 720p tiles fall in its 2K tier at $15.99 per 1,000 minutes, while three 360p tiles are billed as HD at $3.99.

Are recordings billed per participant?

Sometimes. Twilio bills individual track recording per participant-minute, then charges again per minute to compose a single file. Others bill per recorded minute of the room. Check which unit applies before estimating.

Is per-minute pricing or flat licensing cheaper?

Per-minute is cheaper at low or irregular volume because there is no idle cost. Flat licensing becomes cheaper once steady usage pushes the per-minute bill above the licence fee. Samvyo, based on SFU architecture, is offered with flat licensing rather than per-minute billing, so it is worth comparing against your measured participant-minutes rather than meeting-minutes.

What is a TURN server? It is a relay on the public internet that carries a call's media when the two ends cannot reach each other directly. The client asks it for a relayed address, every packet of the call flows through it, and it forwards them on. The protocol is defined in RFC 8656, and it is built to be the last resort: WebRTC tries every direct path first and falls back to TURN only when none of them works.

The usual follow-up, "you need TURN for users behind NAT", was written for calls that go peer to peer. Most video products now send media through a server instead, and that changes when a call actually needs a relay.

What is a TURN server, exactly?

A TURN server does one job: it gives a client an address on the public internet that it can use as its own, and forwards whatever arrives there.

The client starts with an Allocate request. The server answers with a relayed transport address, an IP and port on the server that now belongs to that client. The client then grants permission for specific peers to send to it, and the server forwards traffic both ways. Permissions expire after five minutes unless refreshed, and the allocation itself after ten. For a steady media stream, the client can bind a channel, which shrinks the per-packet header to four bytes.

TURN can run over UDP, TCP, TLS or DTLS. The defaults are port 3478, and 5349 for the encrypted versions, though production deployments usually also listen on 443 because almost nothing blocks it.

That is the whole protocol. What makes it expensive, and easy to confuse with its sibling, is what it carries.

What is a TURN server versus a STUN server?

The two get named together because ICE uses both, but they do opposite amounts of work:

Because TURN carries everything, it is the one part of connectivity that shows up on a bill, and what that relay costs once it carries real traffic is a line most self-hosting models leave out.