WebRTC
WebRTC (Web Real-Time Communication) is the technology behind most in-browser and app-based real-time communication: video calls, voice calls, screen sharing, remote-control tools and peer-to-peer data transfer. When two devices have a WebRTC session, they are exchanging live media (audio and/or video) and/or application data directly with each other.
WebRTC is built on top of the NAT-traversal protocols described on the STUN, ICE & TURN page: those protocols establish the connection, and WebRTC is what flows through it. Nzyme uses the STUN/ICE negotiation to recognize a WebRTC connection, then inspects the traffic on that connection to determine what it is carrying.
How Nzyme identifies WebRTC
A WebRTC session multiplexes several different kinds of traffic over the same network path. Nzyme distinguishes them by inspecting the traffic and looks for three signals:
- STUN/ICE: the connectivity negotiation (see STUN, ICE & TURN). This is what tells Nzyme the connection is WebRTC in the first place.
- RTP: the protocol that carries live audio and video media.
- DTLS: the encryption layer, which also carries the WebRTC data channel (arbitrary application data, such as file transfers, chat, game state or remote-control input).
A connection that shows STUN/ICE plus RTP or DTLS is recognized as a WebRTC session. RTP on its own could belong to other protocols (such as SIP telephony), and DTLS on its own is used by some VPNs. The association with an ICE negotiation makes it WebRTC.
You can find all recorded WebRTC sessions on the WebRTC tab under Streams in the sidebar of your Nzyme web interface.
Media vs. data channel
Not all WebRTC is a video call. The two things a WebRTC session can carry are different:
| Carried traffic | Detected as | What it means |
|---|---|---|
| Media (RTP) | RTP | Live audio and/or video (a call, a camera feed, a screen share) |
| Data channel (DTLS/SCTP) | DTLS | Arbitrary application data (file transfer, chat, game state, remote-control input, etc.) |
A single session can carry both at once (for example, a video call with a side data channel). The WebRTC view shows, per session, whether it has RTP, DTLS, audio and video.
Note
The contents of a data channel are encrypted and cannot be inspected. Nzyme can tell you a data channel is present and active, but not what is being sent through it. Likewise, RTP media payloads are encrypted (SRTP) — but the RTP headers are readable, which is what allows Nzyme to detect and characterize the media streams.
Media streams
Each media stream in a WebRTC session is identified by its SSRC (a numeric stream identifier) and carries:
- A direction (which peer is sending it).
- A suspected media kind — audio or video (see the note on this below).
- Packet counts
A typical two-way video call has multiple streams (each participant's audio and video are separate streams, each with its own SSRC). A one-way stream (a camera, a screen being shared to a viewer) will show media flowing in a single direction.
Media kind is a best-effort guess
Nzyme infers whether a stream is audio or video from observable traffic characteristics (packet sizes and frame markers), because the actual codec is negotiated in signaling that Nzyme never sees, and the media itself is encrypted. The audio/video classification is therefore a strong suspicion, not a guarantee.
How peers are oriented
As with the underlying STUN connection, WebRTC is peer-to-peer and has no inherent client/server or source/destination roles. Nzyme orients each session by which peer is sending the most data. For asymmetric media (a camera, a remote-control tool, a screen share) this reliably identifies the media source. See A note on source and destination on the STUN page for the full explanation.
Sessions and sub-sessions
A single WebRTC session (one negotiation key) can be spread across more than one underlying network flow. For example, audio and video may travel on separate flows that still belong to the same negotiation. The WebRTC view summarizes all of these into a single session row. The session detail page can break a session back down into its individual underlying flows (sub-sessions) when there is more than one.
Some applications instead negotiate each media component (audio, video, data channel) as an entirely separate negotiation. In that case each appears as its own WebRTC session, because there is no shared identifier that would let Nzyme know they belong together.
Analyzing WebRTC activity
The WebRTC view and its charts help answer common questions:
- Is there a video/voice call happening? Look for sessions with RTP and audio/video. Active sessions are flagged.
- When was activity happening? The activity chart shows how many sessions were concurrently active over time. It is designed to stay readable even with many parallel sessions, so it works as well on a busy network as a quiet one.
- Who is talking to whom, and how much? The top peer-pairs view ranks the pairs of devices exchanging the most data over WebRTC. This is useful for spotting the heaviest media flows at a glance.
- Is a peer-to-peer data channel in use? Sessions with DTLS but no RTP are carrying a data channel rather than media. Because a data channel can move arbitrary (and opaque) data, these can be more interesting than a plain video call when investigating where data is going.
Relationship to STUN Connections
Every WebRTC session corresponds to an underlying STUN Connection, linked by the same negotiation key. The STUN view is the right place to understand how the connection was established (direct vs. relayed, successful vs. failed, the mapped/peer/relayed addresses). The WebRTC view is the right place to understand what the connection is carrying (media, data channel, how much, for how long).
Configuration
WebRTC detection is part of Nzyme's UDP analysis and requires no separate configuration beyond having Ethernet monitoring enabled on the relevant interface. See the Ethernet overview for interface configuration.
Additionally, you can tune pipeline performance, but this is rarely required for WebRTC: