WebRTC was built from the ground up on a unicast model, in which data travels directly between devices, one-to-one. That’s a sharp contrast to multicast, which is typically used for broadcasting the same stream to many users at once, as in live sports streaming. Unicast, by contrast, is better suited for two-way conversations like video calls or collaborative apps, in which each connection requires a dedicated stream. This architectural choice helped WebRTC excel in privacy, low latency, and peer-to-peer performance – all critical for real-time, interactive communication.

Let’s explore the origins of WebRTC, how real-time media evolved on the internet, and why the decision to go all-in on unicast shaped the technology’s success.

The Early Days of Real-Time Media

Long before WebRTC, developers had begun exploring how to send audio and video over the internet, but the early efforts were far from seamless. Tools like nv (Network Video), introduced in 1992 by Ron Frederick, allowed users to stream live video using IP multicast, which broadcast the same data to multiple recipients at once. Around the same time, researchers were laying the groundwork with protocols like RTP and RTCP, which helped manage time-sensitive media streams like voice and video.

The goal was bold: to create a low-latency, broadcast-style system for real-time media, built on open internet standards. But in practice, these early technologies were difficult to implement, unreliable across different networks, and inaccessible to everyday users. Real-time communication remained mostly the domain of researchers and specialized tools, not something built into the fabric of the web. WebRTC would change that.

Enter WebRTC

Despite early progress with multicast and RTP, real-time communication remained niche and difficult to use. Most video calls required special software, browser plugins like Flash, or custom-built apps, all prone to bugs, security risks, and poor user experience. What the internet needed was a simpler, browser-native solution.

By the 2010s, that possibility was finally within reach. Browsers had become more powerful, JavaScript engines were faster, and users expected voice and video chat to work without extra downloads. Google’s early Gmail video chat, which was built with technologies like GIPS for audio, Vidyo for video, and libjingle for networking, hinted at what was possible, but it was still proprietary and brittle.

The industry needed a consistent, open standard. In 2011, that standard arrived: WebRTC. Its goals were straightforward – enable browsers to send and receive real-time audio, video, and data; make it secure and peer-to-peer; and eliminate the need for extra software.

Standardization and Early Adoption

To become a true web standard, WebRTC needed more than Google’s support. It needed global consensus. That effort was led by two key organizations. The Internet Engineering Task Force (IETF) handled the underlying transport protocols, working to ensure that WebRTC could connect devices securely and reliably, even across the complex realities of the internet. That included getting through firewalls and Network Address Translators (NAT), which are common in home and corporate networks and often block direct peer-to-peer connections. The IETF’s work led to the adoption of several foundational technologies: ICE, for negotiating connections; STUN and TURN, for navigating NATs and firewalls; and DTLS-SRTP, for encrypting media streams.

Meanwhile, the World Wide Web Consortium (W3C) defined the JavaScript APIs, which are the browser-facing tools developers use to access webcams, microphones, and data channels. These APIs made it possible to build real-time, peer-to-peer communication directly into web applications, with no plugins or extra software required.

The road to standardization wasn’t entirely smooth. Browser vendors and telecom companies had different ideas about how signaling – the process of coordinating connections – should work. WebRTC sidestepped this debate by leaving signaling out of the spec, allowing developers to choose their own methods, whether WebSockets, SIP, or custom solutions. That flexibility helped speed adoption but also meant more work upfront.

Despite the challenges, the collaboration paid off. By the mid-2010s, Chrome, Firefox, and Opera had released versions of their browsers that included built-in support for WebRTC, with Safari and Edge joining later. Today, WebRTC is supported on billions of devices and remains the backbone of real-time communication on the modern web.

Final thoughts

WebRTC began as a mix of strategic acquisitions and open-source ideals, and has since evolved into a global standard for real-time communication across browsers, mobile apps, and connected devices. Its influence extends far beyond video calls, powering everything from IoT and remote monitoring to multiplayer gaming and live collaboration tools.

By enabling peer-to-peer communication through unicast connections, WebRTC sidestepped the need for centralized servers in many scenarios, helping reduce latency and improve privacy. At the same time, it sparked important conversations about what web communication should look like: built on open standards, secure by design, and usable by anyone with a modern browser.

As technology continues to evolve, WebRTC remains a cornerstone of real-time interaction on the internet. Whether you’re streaming video, exchanging data, or enabling smart devices to communicate, WebRTC is still doing the work, which is a testament to what open collaboration across the tech community can achieve.

Read our other resources

We’ve published a range of resources for our community, including:

• An introduction to WebRTC in video streaming
• Top use cases for WebRTC in IoT
• Our RTC explainer, which highlights the benefits of real-time communication

Scalable Video Coding (SVC) offers an efficient way to solve that problem, especially in WebRTC environments where users might be on high-speed desktops, unstable mobile networks or embedded devices with limited processing power.

WebRTC allows real-time audio, video and data streaming directly between browsers and devices – no plugins or external apps required. But it often has to work in less-than-ideal conditions. Some users may be on spotty Wi-Fi. Others might be using mobile data or sitting behind strict firewalls. That’s where SVC helps. It allows a single video stream to adjust in real time to each participant’s connection and device. The result: smoother playback, less wasted bandwidth, and no need to re-encode or send multiple versions of the same video.

But what exactly is SVC, how does it work, and how can you use it in your own applications? Let’s break it down.

The Basics: What Is Scalable Video Coding?

Scalable Video Coding, or SVC, is a method of compressing video that makes it easier to adjust the quality depending on how the video is being watched. Instead of creating separate versions of the same video, SVC lets you encode a single stream in layers. These layers can be added or removed based on the viewer’s internet speed or device performance. That makes streaming more efficient – especially in real-time applications like WebRTC, in which conditions can vary widely from user to user.

SVC isn’t its own video format. It’s a feature built into widely used video codecs which compress and decompress video so it can be stored and streamed more efficiently. Two of the most common codecs are H.264 (Advanced Video Coding) and H.265 (High Efficiency Video Coding). H.264 is popular because it works across most browsers, devices, and platforms. H.265 compresses video even more – about twice as efficiently – but it requires more processing power and not all browsers, devices or media platforms can use it reliably.

SVC builds on these codecs by introducing a layered structure within a single encoded video stream. Here’s how it works:

The base layer contains a minimal version of the video – lower resolution, lower frame rate, or lower quality – but it’s enough to provide a basic viewing experience.

One or more enhancement layers are stacked on top. These layers add extra detail, such as higher resolution, smoother frame rates or improved visual clarity.

The key benefit to SVC is that receivers, such as browsers, embedded devices or apps, can selectively decode only the layers they can handle. For example, a smartphone on a congested mobile network might only download and play the base layer, while a desktop on a high-speed connection can process the full set of layers for a higher-quality stream.

In practical terms, SVC enables smoother video delivery. If the network becomes unreliable or device performance drops, the viewer doesn’t experience buffering or a total quality drop – they just receive fewer enhancement layers. The video keeps playing, albeit at a reduced quality, and can improve again when conditions allow.

For developers building video applications, SVC offers a scalable, resource-efficient way to deliver consistent quality across diverse viewing conditions.

Types of Scalability in SVC

SVC supports three main types of scalability, each offering a different way to adapt video quality:

• Temporal scalability: Adjusts the frame rate. Lower layers might deliver 15 fps, while higher layers add frames to reach 30 or 60 fps. This is useful when conserving bandwidth during network congestion.
• Spatial scalability: Adjusts resolution. A base layer may be 480p, with enhancement layers adding up to 720p or 1080p.
• Quality scalability: Adjusts the level of detail and clarity without changing resolution or frame rate. This is useful for fine-tuning video quality based on available resources.

These scalability types can be used individually or combined, giving developers flexibility to tailor video streams for a wide range of use cases.

SVC in WebRTC

WebRTC is a popular choice for real-time video, but support for SVC in WebRTC is still evolving. Earlier versions of WebRTC relied on the VP8 codec, which doesn’t support true SVC. Instead, it uses simulcast – a method that sends multiple full copies of a video stream at different resolutions. Simulcast works, but it can be inefficient, especially when many users are connected or bandwidth is limited.

Newer codecs like VP9 and AV1 offer better support for SVC. They allow WebRTC to send a single video stream in layers, which can adapt in real time to each viewer’s connection and device. That makes them a better fit for group video calls, live broadcasts, and any situation in which participants have widely varying network quality.

If you’re building a WebRTC app, it’s worth testing VP9 with SVC. You can reduce bandwidth use while improving video quality – particularly in peer-to-peer setups where each user streams video directly to others.

Is SVC Right for You?

If your application only serves a small number of users, or you’re using older media infrastructure that doesn’t yet support SVC, you may be better off sticking with simulcast. Simulcast is well-supported across most browsers and media servers, and although it uses more upstream bandwidth by sending multiple full video streams, it’s relatively simple to implement and reliable in one-to-few scenarios like small group video chats. Plus, smart cameras don’t always support the newer codecs that are necessary for SVC.

On the other hand, SVC becomes especially useful when your application needs to scale. If you’re supporting large groups, broadcasting to many users, or serving clients with a wide range of network speeds and device capabilities, SVC can help. It lets you send a single video stream that adapts to each viewer, rather than generating and transmitting multiple separate streams. That saves both bandwidth and CPU resources on the server or sender side.

This makes SVC especially appealing for:

• Video conferencing platforms with variable group sizes
• IoT or smart camera applications in which efficient bandwidth use is critical and the camera supports newer codecs and SVC
• Mesh-based peer-to-peer networks, in which each client sends video to multiple peers
• Hybrid edge/cloud video applications, in which flexibility in decoding and rendering is important

That said, SVC’s real-world usefulness still depends on browser and server support. While Chrome and Firefox offer promising VP9 SVC functionality, full support across browsers is still a work in progress.

In short: if you’re building a modern, scalable WebRTC application in which performance, efficiency, and adaptability matter, SVC is worth serious consideration. Just be sure to test thoroughly and keep an eye on ongoing updates to browser and server capabilities. It’s an evolving space, but one with a lot of potential.

Final Thoughts

In an era when real-time video is central to everything from security systems to smart home apps, SVC offers a path to smarter, more adaptable video delivery. It reduces resource consumption, improves user experience, and provides a foundation for building applications that can scale more gracefully.

If you’re building WebRTC or low-latency video streaming systems with the latest codecs, now is the time to get familiar with SVC. Start experimenting with VP9 scalability, follow progress on AV1 support, and keep an eye on how media servers are evolving to support layered encoding.

Read our other resources

We’ve published a range of resources for our community, including:

• Choosing an audio codec for your IoT project
• Which streaming protocol is right for you?
• An explainer on WebRTC security architecture

A key technology that makes this possible is Web Real-Time Communication (WebRTC), an open-source protocol that allows browsers and devices to share video, audio, and data directly, without needing third-party plugins or software.

In an ideal scenario, WebRTC enables two devices to communicate directly using a peer-to-peer (P2P) connection. However, in real-world networks, factors like firewalls and corporate network restrictions can obstruct direct communication.

When a direct connection isn’t possible, WebRTC relies on what are called Traversal Using Relays Around NAT (TURN) servers to act as intermediaries, ensuring a stable and reliable connection. By transmitting all data between peers, TURN becomes a critical fallback mechanism for real-time communication applications.

TURN acts as a sort of mail delivery service – one device sends the package to a central server, which then sends the message to another device. Here, I’ll explain more about how this works and why it matters in WebRTC.

CTA Video Demo

What is TURN?

If you’ve ever joined a video call from a network with strict security settings – like those often found in corporate offices – or streamed a multiplayer game over hotel Wi-Fi, or used a remote desktop app over a mobile network, there’s a good chance a TURN server was working behind the scenes to keep your connection stable.

To understand how TURN fits into the WebRTC ecosystem, it helps to look at how these real-time connections are established. When two peers try to start a WebRTC session – whether it’s a video call, a sensor stream from an IoT device, or a screen-sharing session – WebRTC uses a process called ICE (Interactive Connectivity Establishment) to find the most effective path between them.

ICE first tries to create a direct, peer-to-peer link using STUN (Session Traversal Utilities for NAT). This lightweight protocol helps each device discover its public-facing IP address and port as seen from the outside network – information that’s critical for routing traffic through NATs and firewalls. NAT, or Network Address Translation, is a common networking technique that allows multiple devices on a private network to share a single public IP address, but it can also block direct peer-to-peer connections. If a direct connection isn’t possible, because of restrictive network settings, firewalls, or symmetric NATs, ICE turns to TURN.

In a TURN-based connection, one or both devices contact a TURN server to request a relay address. The TURN server assigns a temporary public address and begins acting as an intermediary, forwarding all packets between the two endpoints. This keeps the session alive even in locked-down environments in which direct links aren’t an option.

Unlike STUN, which is used only during setup, TURN remains active throughout the session. It handles every packet – voice, video, or data – requiring a persistent connection and robust infrastructure to avoid performance bottlenecks.

Because TURN servers do the heavy lifting – receiving, processing, and relaying all traffic – they consume more resources and can introduce additional latency. But for many real-time applications, including enterprise video conferencing, cloud-based gaming, telehealth, and remote collaboration, that trade-off is worth it. TURN ensures these apps remain usable, even under challenging network conditions when other connection methods fail.

When Is TURN Necessary?

TURN is not used in every WebRTC session – only when required. Some common scenarios where TURN becomes essential include:

• Symmetric NATs or restrictive firewalls that prevent STUN from functioning.
• Corporate or enterprise networks with locked-down configurations.
• Mobile networks with complex routing paths.
• Cross-geography connections in which network paths aren’t optimized for direct links.

In these cases, TURN ensures that communication continues uninterrupted, even if at the cost of higher latency or bandwidth usage.

Security and TURN Servers

TURN servers are not just about maintaining connectivity – they’re also a critical line of defense in securing real-time communications. Because they handle the entire stream of data between peers, TURN servers have full visibility into all transmitted content. That makes them a sensitive part of the WebRTC architecture and a potential target for misuse, so they must be protected accordingly.

To ensure data is secure during transmission, TURN servers typically use encryption protocols such as TLS (Transport Layer Security) or DTLS (Datagram Transport Layer Security). These protocols encrypt the media and data streams, making it difficult for unauthorized parties to intercept or tamper with the information in transit.

Authentication is another important layer of protection. TURN servers usually employ long-term credential mechanisms, requiring the connecting application (or client device) to provide a valid username and password before allocating a relay address. This helps ensure that only authorized users and systems can access the server’s resources.

Administrators can further strengthen security through access control measures, such as IP whitelisting or the use of Access Control Lists (ACLs). These configurations restrict server access to known or trusted networks, reducing the risk of abuse or unauthorized traffic.

In environments in which data sensitivity is paramount – such as in healthcare, finance, or enterprise communications – these security features are essential. They ensure that TURN servers do more than relay data – they help preserve the integrity, confidentiality, and trustworthiness of every real-time session.

Optimizing TURN Deployment

Because TURN servers are resource-intensive, it’s important to deploy them thoughtfully to balance reliability and cost. One key strategy is geographic distribution – placing TURN servers in multiple regions reduces latency by bringing the relay point closer to the communicating peers. This is particularly useful for applications with a global user base. In addition, using load balancing and autoscaling ensures that TURN infrastructure can handle varying traffic volumes without performance degradation or manual intervention.

Another key factor is maintaining a high peer-to-peer (P2P) connection ratio. WebRTC applications try to establish as many direct connections using Session Traversal Utilities for NAT (STUN) as possible. A high P2P ratio reduces the need for relaying traffic through TURN servers, which helps cut down on bandwidth costs and improves performance. However, the algorithms inside modern browsers determine whether a direct connection is possible, meaning developers have limited control over the actual P2P ratio achieved. Still, designing systems with this goal in mind—favoring STUN-first connectivity—can help reduce unnecessary reliance on TURN.

To keep costs under control, developers should configure WebRTC applications to use TURN only when necessary. The system should first attempt to establish a direct connection using STUN and only fall back to TURN when firewalls or NAT types make that impossible. Monitoring bandwidth usage is also essential, as TURN traffic can grow rapidly in data-heavy applications like video streaming or high-frequency IoT data relays. With careful planning, developers can ensure TURN enhances reliability without introducing unnecessary overhead.

TURN Supports IoT

TURN is widely used in WebRTC applications, but its significance extends beyond traditional video conferencing. It plays a crucial role in IoT deployments that rely on consistent, real-time data transmission across complex or restricted networks.

In smart security systems, IP-based surveillance cameras in office buildings, warehouses, and retail environments often encounter restrictive NAT configurations that block direct peer-to-peer connections. TURN servers help these cameras relay live video feeds to remote monitoring centers without interruption.

In medical IoT, connected health devices – such as continuous glucose monitors, cardiac telemetry tools, and other remote patient monitoring systems – must comply with strict hospital network security policies. When direct communication is blocked, TURN ensures that sensitive health data reliably reaches centralized clinical dashboards or care coordination platforms.

In industrial automation, facilities use IoT sensors to monitor everything from equipment wear and vibration to temperature, humidity, and inventory flow. TURN enables these systems to maintain real-time communication with analytics platforms and control systems, even in environments where internal network restrictions might otherwise disrupt data flow.

Final Thoughts

TURN servers are an indispensable part of the WebRTC ecosystem, acting as the reliable safety net when direct peer-to-peer connections are not feasible. In many real-world network environments, devices are protected behind NATs, firewalls, or stringent corporate security policies that effectively block or complicate direct communication. Without TURN, these restrictions could severely degrade the user experience or even prevent real-time communication altogether.

For developers and network architects, understanding TURN’s role within WebRTC is key to designing systems that balance performance, cost, and user experience. By carefully evaluating when and how TURN is used – favoring direct peer-to-peer links whenever possible but gracefully falling back to TURN when necessary – applications can deliver the best possible connectivity to users worldwide.

In short, TURN servers aren’t just a fallback mechanism. They are a foundational technology that enables the resilient, secure, and real-time interactions that modern digital communications demand.

Read Our Other Resources

We’ve published a range of resources for our community, including:

• Top WebRTC use cases in IoT
• What is WebRTC in video streaming?
• What is NAT traversal in WebRTC?

Most devices – whether laptops, smartphones, or IoT gadgets – don’t have public-facing IP addresses. Instead, they’re tucked behind routers or firewalls using network address translation (NAT). NAT is a common technique that lets multiple devices share a single public IP address, which helps with security and conserves address space, but it also creates a challenge for peer-to-peer (P2P) communication.

While NAT improves security and helps conserve the limited number of available IP addresses, it also creates challenges for peer-to-peer (P2P) communication. Since devices behind NAT don’t have publicly reachable IP addresses, they can’t easily establish direct connections with other devices on the internet. This is a major hurdle for real-time communication technologies like WebRTC, which rely on low-latency, direct connections for video calls, voice chats, and data streaming.

To address this issue, WebRTC uses session traversal utilities for NAT (STUN) servers to help devices discover their public IP addresses. Whether you’re building a telehealth platform, a connected security camera, or a multiplayer gaming service, understanding how STUN works is key to enabling direct, low-latency connections between devices – and optimizing the performance of your application.

What is a STUN Server?

A STUN server is a network service that helps devices behind NAT learn the public IP address and port number that their network is using to communicate with the outside world. This step is necessary in WebRTC applications, in which two devices need to exchange network details in order to attempt a direct peer-to-peer connection. Without that information, the devices wouldn’t know how to reach each other over the internet.

When a device sends a request to a STUN server, the server responds with the public IP address and port number it sees in the request. The device then uses this information to inform its communication partner – typically through a signaling process – so they can try to connect directly. STUN servers don’t transmit any actual media or data between devices; they simply help set up the connection by navigating NAT restrictions.

How Does a STUN Server Work?

When a WebRTC-enabled device – for instance, a smart doorbell – wants to begin communicating with a user’s phone or app, it first gathers its own local IP address. Because the doorbell is typically behind a home router using NAT, it then sends a request to a STUN server to find out the public IP address and port that the router has assigned for its outbound traffic.

The STUN server responds with this public-facing information, which the smart doorbell can then share with the mobile app through a signaling server. With both the doorbell and the app now aware of each other’s network details, they can assess whether a direct peer-to-peer connection is possible.

This process is crucial because NAT obscures a device’s true external IP address from the outside world. By using a STUN server to reveal that information, the smart doorbell enables a direct connection with the user’s app, allowing for low-latency video, real-time alerts, and efficient data transfer without relying on a cloud relay server.

However, the success of a STUN-based connection depends on the type of NAT in use. Some NAT types allow external communication with minimal restrictions, while others impose stricter rules that can block direct peer-to-peer (P2P) connections entirely. This can have a direct effect on how reliably your application functions. The most common NAT types behave differently when it comes to accepting incoming traffic. Here’s how they compare:

• Full-Cone NAT: The least restrictive type. Once the device establishes an outbound connection, any external host can send data back through the same mapping. STUN works well in this setup, which is often found in home networks – ideal for consumer-facing projects like smart doorbells or in-home video monitors, where smooth direct connections enhance responsiveness.
• Restricted-Cone NAT and Port-Restricted NAT: These introduce limitations by allowing incoming traffic only from IP addresses (and in the latter case, specific ports) that the device has already contacted. STUN can often still succeed in these environments, which are common in small offices or managed home networks. This is relevant for projects like remote collaboration tools or basic telehealth applications, in which connections may still be established but with a slightly higher risk of fallback.
• Symmetric NAT: The most restrictive, typically used in enterprise or corporate networks. Symmetric NAT assigns a different public IP and port for each outbound connection, making it difficult for other devices to connect back through the same mapping. In these cases, STUN alone won’t work – projects that require reliable connectivity in such environments, like corporate conferencing platforms or industrial IoT systems, will likely need to use TURN servers for data relay.

To determine which NAT type a WebRTC-enabled device is dealing with, it may send multiple STUN requests to different servers and compare the results. If the responses suggest that direct P2P communication isn’t feasible, the interactive connectivity establishment (ICE) framework will switch to a fallback approach using TURN servers to ensure the connection goes through.

Choosing and Configuring STUN Servers

For developers working on WebRTC-enabled IoT applications, properly configuring STUN servers is critical to performance. Here are a few best practices:

• Use multiple STUN servers: For better reliability and accuracy, configure your application to use multiple STUN servers in different geographic regions. If one server is slow to respond or unavailable, the others can provide backup – helping to avoid failed connection attempts and reduce latency.
• Leverage public STUN services for prototyping: During development and testing, developers often use public STUN services like Google’s public STUN servers (stun.l.google.com:19302). For production deployments, however, it’s best to rely on self-hosted or commercial STUN servers to maintain better control over uptime, performance, and security.
• Ensure security compliance: While STUN itself doesn’t transmit sensitive data, it can reveal the public IP and port mappings of a device. In sensitive IoT use cases – especially in healthcare or critical infrastructure – developers should carefully protect this information with encrypted signaling channels and strong access controls.
• Monitor and log connection behavior: Because NAT behavior can vary widely across networks, maintaining logs of connection attempts, ICE candidate selection, and fallback scenarios can help in debugging and optimizing performance.

Real-World Applications of STUN Servers

Once properly configured, STUN servers play a critical behind-the-scenes role in making real-time connectivity more efficient and responsive. From consumer devices to enterprise platforms, STUN supports a wide range of projects that rely on direct, low-latency peer-to-peer connections.

The following examples show how different industries use STUN to improve performance, reduce server load, and deliver a smoother user experience – even when devices are operating behind NAT:

• In video conferencing platforms like Zoom, Microsoft Teams, and Google Meet, STUN helps users connect directly whenever possible, improving call quality while easing the burden on central servers.
• In online gaming, in which split-second responsiveness is key, STUN enables fast peer-to-peer connections between players, reducing lag in fast-paced or competitive environments.
• Smart home devices such as video doorbells, smart locks, and IP cameras use STUN to connect directly with mobile apps or hubs, allowing for real-time alerts, live video, and quicker response times without routing all traffic through the cloud.
• In IoT security systems, STUN helps surveillance cameras connect to monitoring centers with minimal delay, ensuring smooth video streams and reducing reliance on bandwidth-heavy relays.

Final Thoughts

STUN is a fundamental part of WebRTC and plays a vital role in enabling efficient peer-to-peer communication across various applications. By helping devices discover their public IPs and navigate NAT barriers, STUN reduces reliance on relay servers, improving performance and lowering costs. However, in cases where NAT restrictions prevent direct connections, TURN servers serve as a necessary fallback to ensure reliable communication.

For developers working on IoT applications, understanding this dynamic – and configuring STUN properly – can significantly enhance reliability, reduce latency, and create better user experiences.

Read our other resources

We’ve published a range of resources for our community, including:

• What is a WebRTC signaling server?
• Understanding latency in IoT
• Why Use P2P for IoT Video Streaming?, a guide explaining why P2P is often the best option for IoT video application

But while both Amazon Kinesis and Nabto rely on WebRTC for real-time communication, the way this technology is implemented – and the problems it’s meant to solve – can vary dramatically. Amazon Kinesis, a cloud-based service from Amazon Web Services (AWS), is designed for organizations that need to ingest, store, and analyze massive volumes of streaming data – such as video feeds from security systems, patient monitoring in hospitals, or customer behavior tracking in retail environments. In contrast, Nabto uses WebRTC to enable secure, direct communication with individual IoT devices, making it ideal for applications like remotely unlocking a smart door, adjusting a connected thermostat, or checking a live feed from a home surveillance camera – without routing any data through the cloud.

This article compares how Amazon Kinesis and Nabto use WebRTC to serve very different goals: large-scale data processing versus decentralized, real-time device control.

CTA Video Demo

Understanding WebRTC and Amazon Kinesis

WebRTC is an open-source protocol that enables real-time audio, video, and data sharing directly between web browsers or mobile apps. It’s what makes video calls, live chats, and collaborative tools feel instantaneous. But while WebRTC excels at low-latency, peer-to-peer communication, it wasn’t built to handle large-scale storage, analysis, or long-term processing of media streams.

That’s where Amazon Kinesis Video Streams steps in. As part of AWS’s cloud infrastructure, Kinesis lets businesses go beyond basic real-time exchange by capturing, storing, and analyzing live video feeds from IoT devices, surveillance cameras, and other sources. When paired with WebRTC, Kinesis allows organizations not only to stream video in real-time but also to retain those streams for future review, integrate them with machine learning tools, or analyze patterns across multiple data sources.

This combined approach opens the door to advanced use cases—from patient video monitoring in hospitals, to multi-location security systems, to customer behavior analytics in retail environments.

Advantages of Amazon Kinesis with WebRTC

While WebRTC is excellent for real-time, peer-to-peer video communication, deploying it at scale – especially across many users or devices – comes with infrastructure challenges. For instance, devices need a way to find each other and establish a connection (known as signaling), and many networks use firewalls or routers that block direct communication (NAT traversal). To overcome these barriers, developers often need to set up additional components like signaling servers and media relays, which can be complex and time-consuming to manage.

Amazon Kinesis Video Streams with WebRTC simplifies all of this by offering a fully managed service. AWS takes care of the signaling, provides TURN and STUN servers to handle NAT traversal, and supplies media relay services when direct connections aren’t possible. That means developers can focus on building their real-time video applications – like customer support tools, remote health monitoring systems, or security dashboards – without worrying about the technical plumbing behind the scenes.

Beyond just making WebRTC easier to deploy, AWS also offers tools to enhance and extend video capabilities. With Kinesis and its broader ecosystem, businesses can:

• Store video streams in Amazon S3 for long-term playback or auditing
• Analyze video content using AWS’s AI and machine learning tools (e.g., for motion detection or facial recognition)
• Secure video access with AWS Identity and Access Management (IAM) controls
• Respond to video data in real-time using Amazon Kinesis Data Streams and AWS Lambda functions

By using Kinesis Video Streams with WebRTC, organizations get the best of both worlds: real-time communication combined with powerful cloud storage, analytics, and security tools.

Understanding Nabto with WebRTC

While Amazon Kinesis is built to support large-scale, cloud-based video processing and long-term data analysis, Nabto takes a very different approach. It uses WebRTC to enable direct, peer-to-peer communication between IoT devices and client applications – without routing any data through a cloud server.

This model is especially well-suited to IoT environments in which immediate control, privacy, and simplicity matter more than large-scale storage or analytics. For example, with Nabto, a user can unlock a smart door, adjust a thermostat, or view a live security camera feed in real time, without sending that data to the cloud or relying on a third-party platform to relay the information.

Nabto’s architecture is ideal for:

• Smart homes – Remotely controlling locks, lights, or thermostats with a direct device-to-user connection
• Industrial IoT – Monitoring and managing on-site equipment in real time, even in environments with strict data privacy requirements
• Remote field service – Offering support and diagnostics for devices deployed in the field, without requiring cloud-based access layers

By eliminating the need for intermediary cloud services, Nabto reduces infrastructure complexity, strengthens security, and ensures that data stays within the local network or between trusted endpoints. This makes it an appealing option for businesses that prioritize real-time responsiveness and data privacy over centralized processing and analysis.

The Nabto Difference

Amazon Kinesis is built for scale – streaming, storing, and analyzing video and data in the cloud across thousands of sources. Nabto, by contrast, is designed for simplicity and security at the device level. Instead of sending data to a central cloud platform, Nabto enables direct, peer-to-peer communication between IoT devices and end users.

This decentralized architecture offers several advantages for businesses managing connected devices:

• Lower risk of data exposure – Since information doesn’t pass through a third-party cloud server, there’s less surface area for breaches.
• Reduced complexity – No need to maintain cloud infrastructure or manage backend analytics pipelines.
• Real-time responsiveness – Direct communication means faster interactions without the delay of routing through the cloud.

For IoT companies, this means more control and greater flexibility. Nabto’s WebRTC-based approach is especially valuable in use cases where privacy is critical, infrastructure needs to remain lightweight, or latency must be minimized – such as in home automation, remote equipment control, or offline-capable environments.

Amazon Kinesis vs. Nabto WebRTC security and privacy

One of the key reasons businesses choose Nabto over cloud-based platforms like Amazon Kinesis is its emphasis on privacy and control. For applications in which IoT devices operate in remote, personal, or high-stakes environments – such as home security systems, industrial equipment, or healthcare monitors – the ability to maintain secure, real-time communication without involving cloud servers is more than a convenience; it’s a necessity.

Because Nabto uses peer-to-peer WebRTC connections, data stays between the device and the user, never passing through third-party servers. This means sensitive information – whether it’s a video feed from a baby monitor or performance data from a factory machine – remains within a trusted environment. The result is reduced exposure to external threats, fewer regulatory hurdles, and stronger guarantees of confidentiality.

This architecture also simplifies compliance for industries like healthcare and finance, where strict data privacy standards apply. And since there’s no need to pay for cloud storage or ongoing infrastructure management, Nabto can significantly lower operational costs while increasing security.

In contrast, Amazon Kinesis offers robust tools for managing and analyzing video data at scale – but because that data is stored and processed in the cloud, businesses must implement additional safeguards, such as encryption, access controls, and regular audits, to mitigate risk. For organizations with strict privacy requirements or limited budgets for cloud infrastructure, this added complexity can be a barrier.

By eliminating the need for centralized processing and keeping communication local, Nabto delivers both stronger security and greater cost-efficiency – two priorities that are increasingly top-of-mind for businesses managing distributed IoT systems.

Will You Ever Need to Choose Between the Two?

While Nabto and Amazon Kinesis are built for different architectural approaches, there are situations in which a developer or business might consider both. For example, if you’re building an IoT application with video capabilities, you may be deciding between a cloud-based system that stores and analyzes video data (Kinesis) and a lightweight, peer-to-peer setup that prioritizes direct device control and privacy (Nabto).

The right choice depends on your priorities: choose Kinesis if you need centralized storage, analytics, and integration with other AWS services; choose Nabto if you need real-time responsiveness, reduced complexity, and full control over your data flow. Understanding the trade-offs helps ensure you’re building a system that aligns with your performance, cost, and privacy goals.

Final Thoughts

For businesses building IoT systems with real-time video or data streaming, choosing the right architecture matters. Amazon Kinesis offers robust tools for managing large-scale, cloud-based video analytics, but that power comes with complexity, cost, and cloud dependency. Nabto, by contrast, provides a lightweight, peer-to-peer alternative that prioritizes privacy, responsiveness, and control.

If your priority is secure, direct communication between devices – without the need for cloud infrastructure – Nabto offers a compelling option. It’s especially well-suited for applications in smart homes, industrial IoT, and remote service, where simplicity and data ownership are key. In an environment in which real-time control and privacy are increasingly valued, Nabto gives businesses a streamlined, cloud-free path forward.

Read our other resources

We’ve published a range of resources for our community, including:

• What is WebRTC in video streaming?
• Learn more about P2P from the developer perspective
• What are the top WebRTC use cases in IoT?

If you’ve ever streamed a live event and noticed the quality suddenly drop, that was ABR in action. To avoid buffering and pauses, the stream lowers its resolution temporarily. The quality adjusts to keep the video playing smoothly.

The quality of a video stream is determined by the bitrate – the amount of data transmitted per second. ABR manages this rate by dynamically adjusting the data flow based on network conditions and device capabilities. This ensures smooth playback with minimal buffering, even when internet speeds fluctuate.

How does adaptive bitrate streaming work?

How does adaptive bitrate streaming work? ABR relies on solving two key challenges:

• Offering multiple quality levels of the video stream.
• Choosing the best quality level based on real-time conditions.

n traditional HTTP-based streaming protocols like HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (MPEG-DASH), ABR works by pre-encoding video content at several resolutions and bitrates and storing those versions on a server. The video player then selects which version to stream depending on network conditions and device capability. If bandwidth drops, it switches to a lower bitrate version to prevent buffering. When conditions improve, it upgrades the stream quality.

This two-part strategy allows for smooth, responsive playback that adjusts in real time. Because ABR runs over standard HTTP infrastructure, it’s also highly scalable and works across a wide range of devices and geographic locations.

How is ABR used in WebRTC?

Since many of our video applications at Nabto use Web Real-Time Communication (WebRTC), it’s important to understand how adaptive bitrate streaming works specifically in real-time, peer-to-peer scenarios.

Unlike HTTP-based streaming, WebRTC does not rely on pre-encoded and segmented video. Instead, it must adapt on the fly, which makes some traditional ABR mechanisms unsuitable. But the core goal remains the same: offer multiple quality levels and dynamically select the best one.

Essentially, WebRTC uses different techniques to solve those same two key challenges.

1. Mechanisms for offering multiple quality levels:

• Simulcast: The sender transmits multiple streams of the same video at different bitrates and resolutions.
• Scalable Video Coding (SVC): The sender transmits a single stream composed of layers (base and enhancement layers), which the receiver can selectively decode to adjust quality.

These approaches give the receiver or media server flexibility to downshift or upshift quality based on conditions.

2. Mechanisms for determining the optimal bitrate:

The first of the two mechanisms in this category is RTCP (Real-Time Control Protocol) feedback, which provides ongoing reports about packet loss, round-trip time, and jitter. The second mechanism is congestion control algorithms, including:

• Google Congestion Control (GCC): Used in many Chrome-based WebRTC implementations.
• Scalable and Controlled Real-time Media Communication (ScReAM): Focuses on low-delay, congestion-aware media transmission.
• TCP-Friendly Rate Control (TFRC): Maintains compatibility with TCP flows by controlling the send rate based on loss events.

These tools monitor real-time network conditions and instruct the sender to adjust video parameters, such as resolution, frame rate, and bitrate, accordingly.

For example, in a poor network environment, a WebRTC application may use RTCP feedback and congestion control to automatically reduce bitrate and frame rate, possibly switching to a lower layer in an SVC stream or a lower stream in a simulcast setup. When conditions improve, the system reverses the adjustments to enhance video quality.

By combining these mechanisms, WebRTC enables real-time adaptive streaming that doesn’t require pre-encoded segments. The result is a responsive, low-latency video experience that works well even in fluctuating network conditions, whether you’re on a call in a remote area or monitoring an IoT device from across the world.

How does this relate to IoT?

Adaptive bitrate streaming plays a critical role in many Internet of Things (IoT) applications that depend on consistent video quality. Security cameras and surveillance systems use ABR to deliver stable streams, allowing a business owner to monitor their premises remotely without glitches or buffering.

Similarly, in WebRTC-based IoT scenarios like remote-controlled drones, robotic systems, or even doorbell cameras, some level of adaptive streaming is essential. These systems often stream video in real time over unstable wireless networks. By adjusting resolution and bitrate on the fly, WebRTC ensures that operators still receive continuous visual feedback even in poor connectivity conditions.

In industrial IoT, ABR enables real-time video streaming from remote locations, such as checking the condition of pipelines on oil rigs, inspecting irrigation systems on farms, or monitoring factory machinery in areas with spotty connectivity. By adjusting video quality based on network conditions, ABR helps critical systems stay online and accessible, even in places where connections can be unpredictable.

Connected vehicles and telematics systems – which collect and transmit data from vehicles in real time – also benefit from ABR by streaming dashcam footage and real-time navigation data. For example, a rideshare driver’s dashcam can continue recording and uploading footage even as the vehicle moves through areas with weaker coverage. Navigation apps can also update maps and traffic information smoothly, helping drivers avoid delays without losing connection.

In healthcare and telemedicine, IoT-enabled medical devices use ABR to support video consultations. A doctor can conduct a virtual appointment with a patient in a rural area, with the video adjusting quality automatically to stay connected even when bandwidth drops. Remote monitoring devices in hospitals can also stream video updates to specialists, ensuring clear communication without overwhelming the network. By optimizing video delivery across diverse environments, ABR makes real-time video streaming more reliable and practical for critical uses.

Best bit rates

Choosing the right bitrate is essential for ensuring smooth, high-quality video streaming. Bitrate determines how much data is transmitted per second in a stream, directly impacting video quality and bandwidth usage. Remember that ABR dynamically adjusts the bitrate based on network conditions and device capabilities, making it preferable to fixed bitrates.

Here are the ideal bitrates for different video resolutions and frame rates:

1080p at 60fps (Full HD):

• Bitrate: 4,500 – 6,000 Kbps
• This range delivers high-quality video with clear details and smooth motion, perfect for viewers with strong internet connections.

720p at 30fps (HD):

• Bitrate: 2,500 – 4,000 Kbps
• A suitable range for moderate internet speeds, providing clear video without overloading bandwidth.

480p at 30fps (Standard Definition):

• Bitrate: 1,000 – 2,500 Kbps
• Ideal for slower connections, offering smooth playback while minimizing data usage and maintaining basic video quality.

The key to a seamless streaming experience lies in finding the right balance. A high bitrate can cause buffering on slower connections, while a low bitrate may lead to poor video quality. ABR technology ensures these adjustments happen automatically, maintaining smooth playback even when network speeds fluctuate.

ABR also enhances the viewing experience across different devices. Whether you’re streaming on a smartphone, tablet, or smart TV, ABR adapts the video quality to the device and network, ensuring the best experience. In areas with limited bandwidth, ABR lowers the bitrate to avoid buffering, and when the connection improves, it increases the quality for a sharper, smoother video.

By dynamically adjusting to real-time conditions, ABR optimizes both video quality and bandwidth efficiency, ensuring users have the best streaming experience, no matter where they are or what device they’re using.

Note that in WebRTC, however, bitrates may vary more frequently than in traditional streaming since the system adapts in real time based on conditions like CPU load and network congestion. The goal isn’t fixed quality, but rather a continuous balance between visual clarity and uninterrupted delivery.

Future trajectory with AI

As internet speeds and device capabilities continue to improve, developers are finding new ways to make ABR even smarter by combining it with AI. Although ABR has already made streaming smooth by adjusting video quality to fit available bandwidth, upcoming advancements are pushing this technology even further to deliver personalized, seamless, and highly optimized video experiences.

AI can enhance ABR by predicting network fluctuations and device performance more accurately. Traditional ABR systems adjust quality in real-time based on immediate network conditions, but with AI, these systems can look ahead, anticipating potential bottlenecks or connectivity issues before they even happen. This predictive approach ensures that the user experience remains uninterrupted, even during sudden spikes or drops in network performance.

For example, AI-driven ABR systems could monitor historical data from a user’s internet connection and predict the optimal bitrate ahead of time, adjusting the stream for the best possible quality based on patterns, time of day, or even the type of content the user is watching. If someone regularly experiences network slowdowns during evening hours, the system could proactively lower the stream’s quality slightly before a buffering event occurs. Whether the user is watching a live sports game, participating in a virtual class, or attending an important video meeting, the experience would stay smooth and uninterrupted.

In the context of IoT, AI-enhanced ABR would be particularly beneficial. For instance, in industries like healthcare, in which video consultations are becoming more prevalent, AI could ensure that video quality is consistently clear even during peak usage times or in remote areas with fluctuating network availability. AI could also assess the quality of real-time video feeds from security cameras, drones, or remote industrial machines, adjusting the video quality based on the importance of the content being streamed.

Final thoughts

ABR has redefined how we consume video, becoming a cornerstone of both entertainment and IoT applications. By dynamically adjusting video quality based on network conditions and device capabilities, tools like ABR and WebRTC’s adaptive features help to ensure a flawless viewing experience, even when connectivity is unpredictable.

As the demand for high-quality, on-demand content grows and IoT systems continue to play a pivotal role in industries worldwide, adaptive streaming will remain essential, driving not only better video experiences but also more intelligent systems.

Read our other resources

We’ve published a range of resources for our community, including:

• What are IoT networks?
• Our guide to IoT latency levels
• Understanding regulatory compliance in IoT

WebRTC is designed for real-time, two-way interaction. It supports ultra-low latency and peer-to-peer connections, making it ideal for video conferencing, online gaming, remote device control, and other interactive applications. RTMP, by contrast, is built for stable, high-quality broadcasting to large audiences. It typically introduces a few seconds of delay, which is usually acceptable for livestreaming events on platforms like YouTube Live, Twitch, or Facebook Live – in which the focus is on reliable delivery rather than real-time interaction.

In this post, we’ll break down the technical differences, ideal use cases, and decision factors that can help you choose the best protocol for your streaming needs.

CTA Video Demo

Key technical differences between WebRTC and RTMP

One of the biggest differences between WebRTC and RTMP is how they transmit data. WebRTC uses the User Datagram Protocol (UDP), while RTMP uses the Transmission Control Protocol (TCP). This affects both speed and reliability.

UDP is optimized for low latency. It sends packets without waiting for confirmation that they’ve been received, which speeds up transmission but can result in occasional data loss. That tradeoff makes it ideal for real-time communication, in which brief glitches are better than retransmission of outdated information.

TCP, on the other hand, ensures all data arrives in the correct order by confirming each packet’s delivery. This improves stability and video quality, but introduces more delay – which is usually acceptable in broadcasting contexts.

The protocols also differ in structure. WebRTC uses a peer-to-peer model, allowing direct communication between devices, while RTMP follows a client-server approach, sending the stream to a media server before distribution. This makes WebRTC lightweight and fast, while RTMP excels at scale.

WebRTC also includes a built-in feature called the datachannel, which enables real-time, bidirectional data transfer between peers. Developers use this not just for audio and video, but for sending control signals, telemetry, or supplemental data — making it especially powerful for interactive use cases like remote robotics, multiplayer gaming, and IoT dashboards.

Side-by-side comparison

[wptb id=”19189” not found ]

Use Cases: When to Use WebRTC vs. RTMP

Let’s go into more detail on which uses cases are ideal for these protocols.

Choose WebRTC if you’re building:

1. A video conferencing platform in which every millisecond counts

Use WebRTC when building apps like Zoom, Google Meet, or Microsoft Teams alternatives. These tools depend on ultra-low latency (typically <500ms) so participants can speak, react, and collaborate naturally. WebRTC supports bidirectional, encrypted media exchange directly between users’ browsers, minimizing delay and creating a more lifelike experience.

2. A browser-based multiplayer game with real-time interaction

If your game involves quick reflexes, fast updates, or synchronized action (think virtual card games, real-time strategy, or competitive arcade games), WebRTC allows players to share position data, actions, and voice chat with minimal delay. Unlike polling-based APIs or traditional HTTP, WebRTC maintains a persistent connection ideal for seamless peer-to-peer communication.

3. A smart home application that needs low-latency sensor feedback

Smart home applications using WebRTC can enable near-instantaneous communication between devices. For example, if a motion sensor detects movement, a WebRTC connection can immediately trigger a video feed or alarm with negligible delay. This is critical for time-sensitive systems like doorbell cameras, baby monitors, or live environmental monitoring.

4. A remote robotics interface or IoT dashboard

WebRTC’s low latency makes it perfect for controlling remote machines or robots in real time, such as guiding a drone, steering a rover, or adjusting settings on industrial IoT devices. Engineers and operators need immediate feedback to make precise adjustments. WebRTC can also be used to stream telemetry data or camera feeds for responsive monitoring.

Choose RTMP if you’re delivering:

1. A livestreamed concert, sports match, or gaming event to thousands

RTMP shines in scenarios where a single source broadcasts to a large audience, like a Twitch stream or YouTube Live event. The protocol feeds into a CDN (Content Delivery Network) for scalable delivery, allowing thousands of viewers to watch the event smoothly, even if there’s a short 5–30 second delay.

2. A webinar during which reliability matters more than interactivity

For lectures, corporate events, or training sessions where audience participation is limited and predictable, RTMP offers stable performance. Since you’re not depending on real-time interaction, a slight delay is acceptable — and the format benefits from mature infrastructure and robust compatibility with streaming platforms.

3. A broadcast that uses encoders and CDNs for mass distribution

RTMP works well with hardware encoders, software like OBS, and CDNs like Akamai or Cloudflare Stream. It’s ideal when you need to push a high-quality video stream from a fixed source (like a production studio) to a wide audience without worrying about peer-to-peer complexity. The protocol’s compatibility and mature ecosystem make it a go-to choice for professional-grade broadcasts.

Final thoughts

WebRTC and RTMP each serve different priorities. If your application demands speed, responsiveness, and real-time engagement, WebRTC is likely the better fit. If your goal is to broadcast high-quality content to a wide audience with consistent performance, RTMP remains a proven choice. Understanding your use case – and what matters most to your users – will guide you to the right protocol.

Read our other resources

We’ve published a range of resources for our community, including:

• Our guide to the Real Time Streaming Protocol (RTSP)
• An explainer on WebRTC security architecture
• Why Use P2P for IoT Video Streaming?

In 2017, Gartner estimated that by 2025, 75 percent of all data would be processed outside of traditional data centers. While that shift hasn’t fully materialized yet, the growing number of connected devices and IoT sensors is accelerating the move toward edge-based computing models. By keeping processing close to where data is generated – in homes, vehicles, factories, or smart city infrastructure – companies can respond more quickly and securely to real-time events.

Shifting from cloud to the edge

As businesses generate and process vast amounts of data, many are realizing that traditional cloud storage models come with inherent limitations. The cloud, while scalable and convenient, introduces latency issues, security vulnerabilities, and high bandwidth costs, making it less suitable for applications requiring real-time data analysis and immediate decision-making.

One major challenge is latency – the delay that occurs when data travels between the source – such as IoT sensors or enterprise applications – and cloud data centers, which may be located thousands of miles away. This lag can be detrimental in applications in which split-second decision-making is required, such as autonomous vehicles, financial trading, and industrial automation. Even a slight delay in transmitting and processing data in these areas can result in inefficiencies, operational downtime, or safety risks.

Security is another pressing concern. Centralized cloud infrastructure creates a single point of failure, making it an attractive target for cyberattacks, increasing the risk of data breaches, ransomware attacks, and unauthorized access. Additionally, strict data privacy regulations – such as GDPR in Europe and CCPA in California – are making it more challenging for companies to store and process sensitive information in public cloud environments.

Edge computing allows companies to process and store data locally, closer to where it’s generated. Instead of sending everything to a remote cloud server, companies can use nearby devices or small on-site data centers to handle computing tasks. This approach improves speed, boosts reliability and security, and helps cut the costs tied to cloud storage and data transfers.

Top trends in edge computing

Edge computing is on a strong growth trajectory, with businesses increasingly recognizing its advantages over traditional cloud systems. One forecast predicts that global spending on edge computing will reach $378 billion by 2028, driven by the demand for real-time analytics, peer-to-peer communication, AI-driven automation, and improved customer experiences. Several key trends will shape the future of edge computing. Here are some of my predictions for edge computing trends.

1. Increased AI adoption at the edge

In the coming months, I expect to see more businesses running AI directly on edge devices – enabling faster, automated decisions without relying on cloud processing. This will be especially impactful in IoT use cases, in which devices need to analyze and act on data in real time. As models become more efficient and easier to deploy, edge-based AI will play a bigger role in areas like autonomous vehicles, industrial sensors, and smart surveillance systems.

2. Stronger data privacy regulations

As edge computing spreads, it will bring data processing to more locations – often outside the traditional boundaries of centralized IT. I expect this growing complexity to prompt tighter regulations around how and where sensitive data is handled. Governments will likely introduce new rules to address the risks of decentralized data storage, especially in sectors like healthcare, finance, and critical infrastructure. In response, companies will need to strengthen encryption, tighten access controls, and update their compliance strategies. P2P communication at the edge is often more secure than cloud-based computing, especially with end-to-end encryption like what Nabto provides.

3. Improved sustainability and green computing

As more companies move to edge computing, I expect we’ll see measurable gains in energy efficiency simply as a result of this shift. Processing data closer to where it’s generated reduces reliance on large, power-hungry data centers and cuts down on the energy costs of data transmission. While many businesses may adopt edge computing for performance or security reasons, the environmental benefits will follow.

Final thoughts

The shift toward decentralized, intelligent, and secure computing environments is accelerating. Edge computing has become a critical pillar of modern IT infrastructure, enabling faster processing, enhanced security, and cost-effective scalability. This is especially true in IoT-heavy sectors, in which businesses need to manage and analyze data from thousands of distributed devices in real time.

Companies that embrace these technologies will gain a competitive advantage by improving operational efficiency, reducing latency, and ensuring greater control over their data in the years ahead.

Read our other resources

We’ve published a range of resources for our community, including:

• A guide to IoT and edge computing
• Understanding low latency in IoT
• The challenge of regulatory compliance in IoT

From picking the right hardware to choosing communication protocols, from setting up edge computing to securing your network, each piece plays a role in creating a reliable and future-ready IoT system. In this guide, we’ll walk you through the key steps to building a strong, scalable IoT framework that’s built for performance, security, and real-world use.

CTA IoT Expert Consult

What are the components of an IoT framework?

The IoT framework consists of a variety of hardware, software, and communication protocols. These components work together to create a functional and scalable IoT ecosystem.

The four main components of an IoT framework are:

1. Devices/sensors – These are the physical objects or endpoints that collect data from the environment, such as temperature sensors, cameras, GPS trackers, or embedded sensors in industrial equipment. They are responsible for gathering real-world information
2. Connectivity/network – IoT devices need a way to transmit data, which happens through network protocols like Wi-Fi, Bluetooth, 5G, LPWAN, or satellite connections. These protocols ensure reliable communication between devices and central systems.
3. Data processing/edge and cloud computing – After IoT devices collect and transmit data, the system needs to process it efficiently. In cloud-based IoT frameworks, cloud computing handles large-scale storage, analysis, and advanced processing. However, in peer-to-peer (P2P) architectures like those using Web Real-Time Communication (WebRTC) through the Nabto platform, the cloud acts only as a coordinator to establish direct device-to-device connections. Data flows directly between endpoints, enabling low-latency communication and reducing reliance on centralized infrastructure. Edge computing supports this model by processing data directly on the devices themselves, enabling faster response times and reducing the load on cloud services.
4. User interface and applications – This is the front-end system that allows users to monitor, control, and interact with IoT devices. It can be a mobile app, web dashboard, or automated system that provides insights and triggers actions based on collected data.

How to build IoT frameworks

Building a robust IoT framework requires integrating smart devices, connectivity, and security to create a seamless system. Whether you’re developing a smart home system or an industrial monitoring system, here’s a step-by-step guide to designing a scalable and secure IoT ecosystem.

1. Define your use case

Start by identifying the problem you want to solve. Are you tracking assets in a warehouse? Monitoring home security? Optimizing energy consumption? Clearly defining your IoT use case will guide your hardware, software, and network choices and tell you whether P2P or cloud-based frameworks are the best option.

2. Choose the right hardware

The hardware consists of the IoT devices that collect real-world data. This includes sensors, edge devices, and power supply. Sensors capture key metrics such as temperature, energy usage, and motion. Edge devices – including microcontrollers like Arduino and ESP32 or single-board computers like Raspberry Pi – process data locally before transmitting it to the cloud or to other devices through P2P connections.

Power supply is another critical decision, as it directly influences your deployment options and maintenance. Battery-powered devices are great for flexibility and remote environments but may limit processing capabilities and require power-saving communication protocols. Wired power offers continuous operation and higher performance, especially in static or industrial settings.

Many real-world applications use split systems, where the sensor device is battery-operated for flexibility, and a nearby gateway (such as a wired hub or router) handles communication and power-intensive tasks. This setup balances energy efficiency, range, and performance.

3. Select the best communication protocol

Efficient connectivity is crucial for IoT devices to transmit data reliably while optimizing power consumption and range. The choice of network depends on the application’s needs, balancing factors like coverage, bandwidth, and energy efficiency.

Short-range connectivity options such as Wi-Fi, Bluetooth, and Zigbee are ideal for smart home devices, wearables, and consumer IoT applications that operate within a limited physical area. These protocols offer high data transfer rates but typically require more power and have shorter communication distances.

For broader coverage, long-range networks like LoRaWAN, NB-IoT, LTE-M, and 5G can support industrial IoT, smart cities, and remote monitoring systems. LoRaWAN is well-suited for low-power, long-range applications such as environmental sensors, while NB-IoT and LTE-M provide cellular-based coverage for asset tracking and large-scale deployments. 5G enables ultra-fast, low-latency communication, making it suitable for real-time applications.

4. Implement edge computing

Edge computing reduces latency by processing data close to the source instead of transmitting it to the cloud. Edge platforms like AWS Greengrass, Azure IoT Edge, and Google Edge TPU enhance real-time decision-making and responsiveness.

5. Develop a user-friendly application layer

A well-designed interface ensures that users can monitor, control, and interact with IoT devices effortlessly. Depending on the application, you can build mobile apps, web dashboards, or voice-enabled assistants to provide real-time insights and remote management.

6. Secure your IoT framework

Cybersecurity is critical in IoT. Protect your devices and data with end-to-end encryption (TLS/SSL), device authentication, and regular firmware updates to patch vulnerabilities.

Final thoughts

Building a strong IoT framework is essential for ensuring the success, scalability, and security of your application. A well-structured system integrates reliable hardware, efficient connectivity, edge computing, a user-friendly interface, and robust security measures to create a cohesive and future-proof IoT ecosystem.

As IoT technology continues to evolve, prioritizing interoperability, data privacy, and real-time processing will help your application stay competitive and adaptable to new advancements. By following these best practices, you can develop an IoT system that not only meets current needs but is also prepared for the future.

Read our other resources

We’ve published a range of resources for our community, including:

• Our guide to IoT latency and real-time communication
• Best practices for IoT data security
• Buying versus building your own IoT platform

However, there are many network options for transmitting the data. I’ll explain the network architecture and the four leading types of IoT networks.

IoT network architecture

Before diving into specific network types, it’s important to understand how IoT networks are structured to enable seamless communication. IoT network architecture consists of four key layers that work together to capture, transmit, and process data efficiently:

• Perception Layer: The foundation of IoT networks, consisting of sensors and actuators that collect data from the physical world, such as temperature, motion, or humidity.
• Edge Layer: Includes gateways and edge computing devices that process data closer to the source, reducing latency and enabling real-time decision-making in applications like industrial automation.
• Network Layer: Responsible for transmitting data, usually via technologies like Wi-Fi, Bluetooth, LPWAN, and cellular (3G, 4G,and 5G IoT networks), while balancing range, speed, and power efficiency. Radio wave-based wireless networks are the most common, but wired networks, typically in the form of ethernet, are also used in IoT.
• Cloud Layer: Provides data storage, analysis, and remote access, leveraging AI and big data to support predictive maintenance and large-scale IoT management.

A well-structured IoT network ensures secure, scalable, and efficient data flow, making it easier to build reliable IoT applications. Now, let’s explore the different types of IoT networks and their specific use cases. For the purposes of this article, the focus will be on wireless radio-based networks, since these are the most common in IoT.

The four types of IoT networks

The four main types of IoT networks are personal area networks (PAN), local area networks (LAN), wide area networks (WAN), and low-power wide area networks (LPWAN). These all work to transmit data captured by IoT sensors, but each network has its own pros and cons.

PAN

A personal area network (PAN) connects devices within a short range, typically a few meters. This type of network is designed for low-power, short-range communication and is commonly used for wearable devices, smart home gadgets, and health monitoring systems. Technologies like Bluetooth and Zigbee enable seamless connectivity among smartphones, smartwatches, fitness trackers, and other IoT devices. PANs are ideal for personal use cases that require direct device-to-device communication but that don’t need extensive infrastructure.

LAN

A local area network (LAN) provides connectivity within a limited geographical area, such as a home, office, or factory. Wi-Fi and ethernet are the most common LAN technologies in IoT applications. LANs offer higher data transfer speeds and better reliability than PANs, making them suitable for smart homes, industrial automation, and connected office environments. IoT devices on a LAN can communicate with each other and the internet through a central router or gateway, enabling efficient data exchange and remote monitoring.

WAN

A wide area network (WAN) extends connectivity over large distances, enabling IoT devices to communicate across cities, countries, or even globally. Cellular networks – such as 3G, 4G, and 5G – are the most widely used WAN technologies in IoT, offering reliable and scalable connectivity for applications like smart cars, GPS tracking, and mobile healthcare. WANs make it possible for devices to stay connected even when they move between different locations.

One of the trade-offs of WAN technology is that it typically requires more power and comes with higher operational costs than other network types. However, newer WAN technologies, such as 5G, offer significant advantages. With ultra-fast speeds, low latency, and the ability to connect a vast number of devices simultaneously, 5G IoT networks are particularly suited for advanced applications that rely on real-time data transmission. These include autonomous vehicles, smart cities, industrial automation, and remote healthcare.

LPWAN

A low-power wide area network (LPWAN) is specifically designed for long-range, low-power communication, making it ideal for large-scale IoT deployments. Technologies like long range wide area network (LoRaWAN), Sigfox, and NB-IoT allow devices to transmit small amounts of data over vast distances while consuming minimal power. LPWANs are commonly used in smart agriculture, environmental monitoring, and industrial IoT, where devices need to operate for years on a single battery. These networks provide cost-effective connectivity for IoT applications that require intermittent data transmission but don’t need high bandwidth.

The best IoT networks for P2P

Peer-to-peer (P2P) devices communicate directly with each other without relying on a central server or cloud-based intermediary. These devices exchange data in real-time, making them ideal for applications like smart home automation, surveillance, file sharing, and industrial machine-to-machine (M2M) communication. Since P2P communication requires direct and efficient data transfer, PANs and LANs are the best-suited IoT networks for these devices.

PAN for P2P Devices

PANs, such as Bluetooth and Zigbee, enable short-range communication between P2P devices, making them ideal for wearables, smart home gadgets, and medical devices. For example, common PAN-based P2P applications include a fitness tracker syncing data with a smartphone or smart lights responding to voice commands via a mobile app. These networks offer low power consumption, fast response times, and direct connectivity, making them efficient for small-scale P2P interactions.

LAN for P2P Devices

LANs, particularly Wi-Fi, supports higher data transfer speeds and can connect multiple devices over a wider range compared to PANs. In P2P applications, LANs enable seamless device-to-device communication within homes, offices, or industrial settings without requiring an internet connection. Examples include a smart TV streaming content from a local media server, or two industrial robots coordinating tasks within a factory floor.

Final thoughts

When it comes to IoT, it’s all about the data – capture, transmission, and storage. So, choosing the correct IoT network is an essential part of the development process. How data gets from one place to another can make or break an IoT application. Choose wisely.

Read our other resources

We’ve published a range of resources for our community, including:

• What are the best audio codecs for your IoT design?
• Our guide to IoT latency levels
• Understanding regulatory compliance in IoT