WebRTC is almost exclusively used for which scenario?

WebRTC is almost exclusively used for which scenario?

• A. Public REST API calls
• B. Peer-to-peer audio/video calling and conferencing
• C. Server-side batch processing
• D. CDN edge caching.

Answer: (B)

WebRTC is designed for real-time, browser-to-browser communication, especially for audio and video. It provides APIs that capture media, negotiate connections, and send streams and even arbitrary data directly between peers. This makes it ideal for scenarios like one-to-one or small group calls and conferencing where low latency and direct media transmission matter. For larger conferences, media can be routed through a server (an SFU or MCU) to manage many streams, but the core idea remains real-time peer communication rather than relying on servers for batch tasks or caching. It isn’t meant for public REST API calls, server-side batch processing, or CDN edge caching, which are different workloads focused on request/response APIs, long-running non-interactive tasks, or distributing static content, respectively.

WebRTC is designed for real-time, browser-to-browser communication, especially for audio and video. It provides APIs that capture media, negotiate connections, and send streams and even arbitrary data directly between peers. This makes it ideal for scenarios like one-to-one or small group calls and conferencing where low latency and direct media transmission matter. For larger conferences, media can be routed through a server (an SFU or MCU) to manage many streams, but the core idea remains real-time peer communication rather than relying on servers for batch tasks or caching.

It isn’t meant for public REST API calls, server-side batch processing, or CDN edge caching, which are different workloads focused on request/response APIs, long-running non-interactive tasks, or distributing static content, respectively.