Matter 1.5 Cameras: WebRTC Streaming, Privacy Zones, and What Thread 1.4 Changes

The interesting thing about Matter 1.5 cameras is not that video finally arrived. It is where the specification chose to stop. Matter now standardises how a controller asks for a stream, how it negotiates codecs, how it draws a privacy mask, how it aims a lens, and how it points a camera at a cloud bucket. It standardises almost nothing about whether the camera obeys any of that. The privacy boundary that most coverage attributes to the fabric actually sits one layer lower, inside vendor firmware, and the one mechanism that genuinely moves it — SFrame — is optional.

That gap is the most consequential design decision in the release, and it is worth understanding before you commit a product roadmap or an integration to it.

What this covers: how the cluster and endpoint model extends to cameras, the exact WebRTC signalling path and why WebRTC displaced RTSP, two-way audio and PTZ, where detection and privacy zones are really enforced, the local-versus-cloud recording split, the honest bandwidth and power arithmetic for Thread against Wi-Fi and Ethernet, and what mandatory Thread 1.4 certification changed in January 2026.

Context and Background

Cameras were the last big hold-out in Matter. Every other mainstream smart-home category — lighting, locks, thermostats, sensors, appliances, energy — had landed by Matter 1.4. Video did not, because video is not a control problem. It is a media transport problem with a NAT traversal problem bolted to it, and the Connectivity Standards Alliance had no appetite for inventing either.

The incumbents show why. ONVIF plus RTSP is the professional-surveillance answer, and it works well on a flat LAN with a wired NVR. It has no native NAT traversal story, no built-in congestion control, and transport security that has historically been bolted on rather than mandatory. The consumer answer went the other way: Ring, Nest, Arlo and Eufy each built a proprietary cloud relay with a vendor app on the far side, which solved remote access by making the vendor cloud mandatory. Apple’s HomeKit Secure Video sat in between — a genuinely good privacy architecture, but a single-ecosystem one.

Matter 1.5, released on 20 November 2025, took the third option: adopt WebRTC wholesale. The Alliance’s own announcement is explicit that cameras “support live video and audio streaming using established WebRTC technology, enabling two-way communication and both local and remote access via standard STUN and TURN protocols.” The same release added closures, soil sensors, an electrical energy tariff device type, and — quietly important for cameras — full support for operating Matter over TCP transport for large messages.

The follow-up maintenance release, Matter 1.5.1 on 31 March 2026, is almost entirely a camera release. It added multi-stream video and audio delivery in a single structured session, HEIC snapshots, HLS and DASH upload using the CMAF Interface-2 profile, and PTZ fixes for installations where the camera’s home position sits at the edge of its rotation range. If you are reading a 1.5 cluster revision table, check it against 1.5.1 — several camera clusters moved from revision 1 to revision 2 in four months.

For the wider protocol landscape this sits in, our comparison of Thread and Matter as connectivity layers covers the stack underneath everything discussed here.

How Matter’s Cluster and Endpoint Model Extends to Cameras

Matter 1.5 models a camera as an ordinary node with six new camera clusters and nine new device type identifiers. Those clusters describe the camera as a controllable object — streams, zones, settings, signalling and push transport. The video itself never travels over Matter; it leaves on a separate WebRTC path the clusters only negotiate.

That is the whole design in one sentence, and everything else follows from it. A Matter camera exposes endpoints; each endpoint declares a device type; each device type mandates clusters; each cluster carries attributes, commands and events. Video changes none of that plumbing. It simply adds a second plane that the plumbing sets up and then leaves alone.

Figure 1: The Matter 1.5 camera data model. Control lives in clusters on the camera endpoint; media leaves on a separate DTLS-SRTP path that the clusters only set up.

Figure 1 separates the two planes that most diagrams of Matter cameras conflate. Everything above the media plane is ordinary Matter interaction-model traffic — TLV-encoded reads, writes, subscribes and invokes, carried over the operational fabric with per-fabric access control. Everything in the media plane is a standard WebRTC peer connection that Matter does not touch once it is up. The clusters are signalling and policy; they are not a media transport.

The device types tell you what the Alliance actually shipped

Matter 1.5 did not add “a camera”. It added a family, and the identifiers are worth knowing because certification, ACL scoping and ecosystem support all key off them. As tracked in the Matter 1.5.1 delta maintained for Matterbridge, the new device types are Intercom 0x0140, Audio Doorbell 0x0141, Camera 0x0142, Video Doorbell 0x0143, Floodlight Camera 0x0144, Snapshot Camera 0x0145, Chime 0x0146, Camera Controller 0x0147 and Doorbell 0x0148.

Two of those deserve a second look. Snapshot Camera exists so a device that can only produce still images on demand does not have to pretend to be a streaming camera — that is the escape hatch for battery and low-bandwidth designs. Camera Controller is the mirror image: it is a device type for the viewing side, which is what lets a hub or display be certified as a legitimate consumer of streams rather than just an app.

Six clusters, and only two of them touch media

The camera capability set is built from clusters in the 0x055x block plus two TLS clusters on the root node:

Cluster	ID	Role
Zone Management	0x0550	Define 2D cartesian zones for detection or privacy masking
Camera AV Stream Management	0x0551	Allocate, configure and release audio, video and snapshot streams
Camera AV Settings User Level Management	0x0552	User-facing resolution, frame rate, bitrate and PTZ parameters
WebRTC Transport Provider	0x0553	Camera-side signalling — offers, answers, ICE candidates, session teardown
WebRTC Transport Requestor	0x0554	Controller-side signalling counterpart
Push AV Stream Transport	0x0555	Push recorded or event-triggered media to a remote ingest endpoint
TLS Certificate Management	0x0801	Provision root and client certificates for outbound TLS
TLS Client Management	0x0802	Provision the TLS endpoints the device may connect to

Camera AV Stream Management is the gatekeeper. Before any signalling happens, a controller allocates a stream through it, and the camera validates the request against its own hardware — codec support, resolution, frame rate, and whether it has encoder capacity left. Espressif’s engineering write-up on the first MCU-class Matter camera implementation describes this as the cluster that “validates the request, checks for compatible stream configurations, and ensures that sufficient resources are available by querying the underlying camera device hardware.” That resource check is the practical constraint on multi-viewer scenarios, and it is why 1.5.1’s multi-stream work mattered: without it, three viewers meant three independent encodes.

Stream usage is a first-class enum, and it drives policy

Every allocated stream carries a StreamUsage value. In the open-source implementations tracking the specification, the values are Internal = 0, Recording = 1, Analysis = 2 and LiveView = 3. This is not cosmetic. It gives a controller a machine-readable reason for the stream, which is what makes differentiated policy possible: an ecosystem can grant a guest account LiveView and deny Recording, or route Analysis streams to a lower-resolution encode. Matter 1.5.1’s multi-stream capability exists precisely so a camera can serve a high-resolution Recording stream, a mobile-optimised LiveView stream and a downscaled Analysis stream concurrently rather than sequentially.

The access-control story rides on standard Matter ACLs. A camera’s clusters are per-fabric, so a node commissioned into three fabrics maintains three independent privilege sets. That is the same model our write-up on zero-trust architecture for industrial OT and IoT argues for in a plant context, and it holds up well here — with one caveat covered later, which is that the ACL governs who may ask, not what the firmware then does.

The WebRTC Signalling Path: Offer, Answer, ICE, DTLS-SRTP

Matter does not carry video. It carries the Session Description Protocol (SDP) blobs and ICE candidates that let two endpoints build a peer connection, and then it gets out of the way. Understanding that split is the single most useful thing an integrator can internalise about this release.

Figure 2: The ProvideOffer signalling flow. Matter commands carry SDP and ICE candidates; the media path is negotiated by WebRTC and never traverses the Matter fabric.

Figure 2 traces the controller-offers case. The controller first allocates streams through Camera AV Stream Management, then invokes ProvideOffer on WebRTC Transport Provider with its SDP offer, the target StreamUsage, the originating endpoint, optional video and audio stream identifiers, an ICE server list and an ICE transport policy. The camera answers with a session identifier and the allocated stream identifiers, then sends its SDP answer back by invoking Answer on the controller’s WebRTC Transport Requestor cluster. Both sides then trickle ICE candidates at each other. Once ICE completes and the DTLS handshake finishes, media flows directly as SRTP.

There are two flows, not one, and the difference matters for battery devices

The Provider cluster exposes SolicitOffer, ProvideOffer, ProvideAnswer, ProvideICECandidates and EndSession; the Requestor exposes Offer, Answer, ICECandidates and End. That asymmetry gives you two complete signalling sequences.

In the ProvideOffer flow, the controller is the offerer. In the SolicitOffer flow, the controller asks the camera to generate the offer, the camera sends Offer to the Requestor, and the controller replies with ProvideAnswer. SolicitOffer is the flow that suits a sleeping device: the camera controls when it wakes its media engine and builds its description, rather than having to be ready to answer at an arbitrary moment. The Matter SDK’s reference camera application even carries a --camera-deferred-offer switch to exercise exactly this.

ICE servers are provisioned by the controller — that is the quiet win

The ICE server list is a parameter of the offer commands, carried as a struct with URLs and optional credentials. This is the part of the design that most benefits device makers, and it is easy to miss. In the pre-Matter world, every camera vendor had to build, operate and pay for their own STUN and TURN infrastructure to make remote viewing work through carrier-grade NAT. Under Matter 1.5, the ecosystem hands the camera the STUN and TURN endpoints to use. A small manufacturer inherits Google’s, Apple’s, Amazon’s or Samsung’s NAT traversal plumbing rather than renting their own TURN relays.

That is also the point at which the economics of “local-only” get honest. A TURN relay, by construction, sees every packet. If your ecosystem hands the camera a TURN server and the ICE transport policy is relay, your “local” camera is relaying media through infrastructure you do not control. It is still encrypted end to end at the DTLS-SRTP layer, so the relay sees ciphertext — but the metadata, the timing and the fact of the session are all visible there.

Why WebRTC and not RTSP

Four mechanisms explain the choice, and only the first one gets discussed much.

NAT traversal is the obvious one. ICE, with STUN for reflexive candidates and TURN for relay, is the only widely deployed solution to the problem of two endpoints behind different NATs. RTSP has nothing equivalent; the professional world solves it with VPNs, port forwarding or a vendor relay.

Congestion control is the underrated one. The SDK camera app’s own SDP advertises a=rtcp-fb:96 nack, nack pli and goog-remb alongside H.264. Those feedback mechanisms drive Google Congestion Control, which lets the sender adapt bitrate to a degrading Wi-Fi link in real time. RTP over RTSP interleaved in TCP does the opposite: it head-of-line-blocks and buffers, which is why a struggling RTSP camera goes from fluid to a frozen frame rather than from sharp to soft.

Security is mandatory rather than optional. DTLS-SRTP is not a profile you can decline in WebRTC — a peer connection that cannot complete the DTLS handshake does not carry media at all.

Client parity is the fourth. Every phone, every browser and every modern TV stack already ships a hardened WebRTC implementation. An ecosystem adding Matter camera support writes signalling glue, not a media stack.

Two-way audio falls out of the design

Two-way talk needs no separate Matter mechanism. It is an SDP direction attribute. In the SDK camera application’s description, the video section is a=sendonly while the audio section is a=sendrecv — the camera sends video, and audio flows both ways in the same peer connection, negotiated as Opus at 48 kHz stereo with in-band forward error correction enabled. Because it is one bidirectional peer connection rather than two unidirectional streams, echo cancellation and jitter buffering behave the way they do in a normal voice call.

The Intercom device type (0x0140) exists for the case where audio is the whole product, and Matter 1.5.1 clarified its signalling requirements and added support for an integrated chime. The Chime cluster (0x0556) gained the ability for a controller to request a specific installed sound rather than only the default, plus a ChimeStartedPlaying event — which is what makes “different chime per doorbell” and chime-triggered automations possible without vendor extensions.

PTZ, Zones, and Where the Privacy Boundary Actually Sits

This is the section where the marketing and the mechanism diverge, so it is worth being precise.

Figure 3: Zone geometry is negotiated in the Matter fabric. Masking, detection and PTZ limiting are executed in vendor firmware, below the boundary the fabric can observe.

Zone Management (0x0550) gives a controller a standard way to define two-dimensional cartesian regions in the camera’s field of view and associate behaviour with them — motion detection in this rectangle, privacy masking over that one. Camera AV Settings User Level Management (0x0552) carries the PTZ parameters. Both are ordinary clusters: a controller writes geometry, reads it back, and subscribes to events.

What the fabric can and cannot verify

A controller can confirm that the camera accepted a privacy zone, because the attribute reads back. It cannot confirm that the encoder applied it. Nothing in the Matter interaction model gives a controller a cryptographic or structural guarantee that pixels inside a privacy mask were destroyed before encoding rather than merely painted over in a preview, or that the mask was applied to the Recording stream as well as the LiveView one.

The enforcement point is the vendor’s image pipeline. Matter standardises the request; the vendor implements the response. That is not a criticism of the specification — no realistic standard could mandate and test the internals of a proprietary ISP — but it does mean a Matter-certified privacy zone is a contract of intent, not a proof.

There is one place where the specification gives the boundary teeth, and it is worth noting: the WebRTC end-reason enumeration includes a distinct PrivacyMode value alongside ICEFailed, ICETimeout, UserHangup, UserBusy, Replaced, NoUserMedia, InviteTimeout, AnsweredElsewhere, OutOfResources, MediaTimeout, LowPower and UnknownReason. A camera in physical privacy mode terminates sessions with a reason a controller can distinguish from a network failure. That matters for user interfaces — “the camera is off because you turned it off” is a very different message from “the camera is unreachable” — and it is the kind of detail that only shows up when a standards body has real implementers in the room.

SFrame is the mechanism that actually moves the boundary

DTLS-SRTP protects a single hop. In a multi-device ecosystem where a stream is forwarded — to a second family member, to a hub, to a cloud analysis service — SRTP is decrypted and re-encrypted at each forwarding point, which means the forwarder sees plaintext video.

Matter 1.5’s camera design allows Secure Frame (SFrame), which encrypts at the media-frame level rather than the transport level. With SFrame configured, a forwarding node routes frames it cannot read. This is the difference between “encrypted in transit” and “end-to-end encrypted”, and it is the only mechanism in the release that meaningfully relocates the trust boundary away from every intermediary.

It is also optional, and configured as a struct inside the offer. If you are evaluating Matter cameras on privacy grounds, the question to ask a vendor is not “do you support privacy zones” — everyone will — but “do you negotiate SFrame, and on which stream usages”.

Recording: Local, Cloud, and the TLS Clusters Nobody Mentions

Live view is one problem; recording is a different one with different economics. Matter 1.5 handles it with Push AV Stream Transport (0x0555), which lets a controller configure the camera to push media to a remote ingest endpoint on a trigger — continuously, or on motion, or on a doorbell press. Matter 1.5.1 added DoorbellPressed to the trigger activation reasons and augmented the push events with session numbers and event context.

The media format story is deliberately conventional. Recorded upload uses Common Media Application Format (CMAF), with optional encryption, and Matter 1.5.1 added full support for HLS and DASH upload using the CMAF Interface-2 profile. That means the destination can be an ordinary object store and an ordinary media pipeline. Snapshots picked up HEIC alongside JPEG in 1.5.1 — meaningful when a doorbell is pushing a still image over a constrained uplink, since HEIC typically achieves comparable quality at roughly half the bytes.

The clusters that make this work are the ones almost no coverage mentions: TLS Certificate Management (0x0801) and TLS Client Management (0x0802) on the root node. These are how a controller provisions the root certificates and the permitted TLS endpoints the camera may connect to. Architecturally this is the most interesting part of the recording design, because it inverts the usual relationship: the ecosystem, not the manufacturer’s firmware, decides where the camera is allowed to upload.

That is a real improvement over the status quo, in which a camera’s cloud destination is hard-coded by the vendor. It is also the precise mechanism by which a Matter-certified camera can still send every frame to a vendor cloud — the clusters configure the destination, they do not restrict it to one you own. A local recording model in Matter means pointing Push AV Stream Transport at a network video recorder on your own LAN; the protocol supports it, but whether a given product exposes it is a product decision, not a specification one.

Bandwidth and Power: Thread, Wi-Fi, and Ethernet

Here is where a lot of smart-home writing gets vague, so let us do the arithmetic.

Figure 4: Transport capacity against a single 1080p30 stream. Thread is off the scale by more than an order of magnitude; the comparison is not close.

Thread cannot carry video, and the margin is not marginal

Thread runs on IEEE 802.15.4 at 2.4 GHz, which has a raw PHY rate of 250 kbit/s. That is the whole channel, shared by every node in the mesh, before MAC overhead, CSMA backoff, 6LoWPAN header compression, IPv6, UDP and retransmission. Real application-layer goodput on a multi-hop Thread mesh is a fraction of that figure.

Now take the Matter SDK’s own reference camera SDP, which advertises b=AS:3000 on the video section — 3,000 kbit/s for 1080p30 H.264. That is twelve times the entire raw capacity of the 802.15.4 channel, for one stream, ignoring every source of overhead and every other device on the mesh.

Drop the ambition. A heavily compressed 320×240 doorbell-grade stream at 256 kbit/s still exceeds 100% of the raw PHY rate. Drop it further, to audio only: the SDK’s Opus configuration advertises maxaveragebitrate=96000, so a single voice channel consumes roughly 38% of the raw channel — sustained, on a mesh that also has to route everyone else’s traffic.

Even snapshots are painful. 802.15.4 frames carry a maximum 127-byte PHY payload, while IPv6 requires a minimum MTU of 1,280 bytes, so every Matter message above a few dozen bytes is fragmented by 6LoWPAN. A 150 KB HEIC snapshot is roughly 1,900 fragments after headers, and at a realistic 50 kbit/s of effective goodput it takes on the order of 24 seconds to arrive — during which the mesh is carrying essentially nothing else. These figures are straightforward arithmetic from the published PHY rate and the SDK’s own SDP, not measurements, but the conclusion does not depend on precision: the gap is orders of magnitude, not percentages.

This is why every shipping Matter camera is a Wi-Fi or Ethernet device, and why Snapshot Camera exists as a separate device type. It is not a gap in Thread. Thread was designed for a duty-cycled sensor sending a few hundred bytes an hour on a coin cell. Asking it to carry video is a category error, in the same way that asking MQTT to carry deterministic motion control is — a point our comparison of DDS, MQTT and OPC UA for industrial messaging makes about picking transports by workload rather than by familiarity.

Wi-Fi is the realistic floor, and it is tighter than people expect

A single-stream 2.4 GHz 802.11n client at 20 MHz tops out at 72.2 Mbit/s PHY, which in a real home with contention and management overhead lands somewhere in the 20–35 Mbit/s range of actual throughput. At 3 Mbit/s per 1080p stream, eight cameras streaming simultaneously consume 24 Mbit/s — which is within the theoretical number and outside the practical one, particularly when the same band is carrying every Thread-adjacent 2.4 GHz device in the house.

Two design consequences follow. Push 5 GHz or 6 GHz wherever the camera supports it, which is why dual-band silicon appears in modern camera designs. And take Matter 1.5.1’s multi-stream capability seriously: serving three viewers from one structured session with three optimised encodes is materially cheaper on air time than three independent full-resolution sessions.

Power is why battery cameras are architecturally different

A Wi-Fi radio holding an association and an encoder running H.264 at 30 fps are both continuous power draws, which is fundamentally incompatible with a battery product. The interesting engineering response is to split the device.

Espressif’s Matter camera does exactly this: the ESP32-P4 handles MIPI-CSI capture and hardware H.264 encoding for 1080p30 and sits in deep sleep when not streaming, while an ESP32-C5 or C6 runs the Matter application and holds Wi-Fi connectivity in light sleep. The signalling plane stays reachable; the media plane wakes only when a session is actually requested. This is a clean illustration of why the Matter design separates signalling from media at all — the two planes have completely different duty cycles, and a split-SoC design can only exploit that if the standard lets them be separated.

For mains-powered and professional installations, Ethernet with Power over Ethernet remains the least interesting and most reliable option. IEEE 802.3af delivers 15.4 W at the sourcing equipment and guarantees 12.95 W at the powered device, which comfortably covers a camera with an IR illuminator; 802.3at raises that to 30 W and 25.5 W for pan-tilt motors and heaters. One cable, no radio contention, no battery arithmetic.

What Mandatory Thread 1.4 Certification Changed

Thread 1.4 is not a camera feature, but it changed the substrate that Matter cameras are commissioned into, and the deadline landed this year.

Thread Group released the 1.4 specification in September 2024 and opened certification then. The forcing function arrived on 1 January 2026: new Border Router certification applications based on Thread 1.3 are no longer accepted. Separately, the Alliance tightened Matter itself — since Matter 1.4.2, border routers and Network Infrastructure Managers must be Thread 1.4 certified.

Three of the 1.4 changes matter in practice.

One mesh instead of several. The headline problem Thread 1.4 solves is the one every multi-ecosystem household hit: adding an Apple border router, then a Google one, then an Amazon one produced three parallel Thread networks in the same physical space, each with its own credentials, each unable to route for the others, all contending for the same 2.4 GHz channel. Thread 1.4 standardises how devices recognise and trust each other so a new device or border router joins the existing network rather than creating another. Fewer partitions means shorter routes, less contention and better battery life for leaf devices.

A defined path to the Internet. Thread 1.4 border routers gain a standard route to the Internet rather than relying on vendor-specific arrangements. Combined with Thread over Infrastructure — which lets border routers extend the mesh across existing Wi-Fi and Ethernet — this makes the mesh’s edges both longer and more predictable.

Commissioning at scale over TLS. Instead of scanning a physical install code on every device, Thread 1.4 permits authenticated commissioning over TLS with certificates, in proximity over a link such as Bluetooth Low Energy. For a commercial deployment where devices are pre-installed above ceilings, this is the difference between a viable rollout and an unviable one.

The honest caveat: the mandate applies to new certifications, not to installed hardware. Thread 1.3 devices keep working, and a 1.3 border router already on a shelf does not upgrade itself. The multi-network fragmentation problem gets solved as hardware turns over, not on a date. Expect mixed estates for years.

Trade-offs, Gotchas, and What Goes Wrong

The specification is young and implementations disagree. A concrete, current example: an issue filed against the Matter SDK on 19 September 2026 reports that chip-camera-app answers a ProvideOffer with an SDP whose every media section carries a=setup:actpass. RFC 8842 §5.3 defers to RFC 4145 §4.1, which permits an answer to be active, passive or holdconn — never actpass, which is how an offer says “you choose”. A conforming peer rejects it outright, the DTLS role is never resolved, and the session never establishes. Certification cases TC-WEBRTCR-2.4 and 2.5 both fail at that point. Only the ProvideOffer direction is affected; under SolicitOffer the camera is the offerer, where actpass is correct. If you are integrating today, test both flows, because they exercise different code paths and only one of them may work.

Stream allocation fails before signalling does, and the errors look different. Camera AV Stream Management validates against real encoder capacity. A camera that happily serves two viewers may refuse a third with an out-of-resources condition that surfaces at allocation time, not at ICE time. Build your controller to distinguish “the camera said no” from “the network said no” — the end-reason enumeration gives you the vocabulary, so use it rather than collapsing everything into a generic failure.

Privacy zones are advisory across the fabric boundary. Covered above, and it bears repeating as an integration warning: do not build a compliance story on a privacy zone you cannot verify. If you need a hard guarantee in a workplace or a regulated setting, a physical shutter and an auditable local-only recording path are the mechanisms that actually hold.

TURN turns “local” into “relayed”. An ICE transport policy of relay, or a NAT that defeats every reflexive candidate, puts your media through an ecosystem-operated relay. Encrypted, yes — but if your requirement was that video never leaves the premises, ICE policy is the setting that decides it, and it is set by the controller.

Do not plan Thread for anything with a lens. The arithmetic above is not close. Snapshot-only devices on Thread are defensible; streaming devices are not.

Cluster revisions moved in four months. WebRTC Transport Provider, WebRTC Transport Requestor, Push AV Stream Transport and Chime are all at revision 2 as of 1.5.1, largely because of multi-stream support. Code written against the 1.5 revision-1 shapes will need revisiting.

Practical Recommendations

If you are building a Matter camera, start from the transport decision and work backwards. Wi-Fi or Ethernet is not a preference; it is the only option for streaming. If the product must be battery-powered, design the split-SoC architecture early — signalling and media have different duty cycles, and retrofitting that separation into a single-SoC design is painful. Implement SolicitOffer properly, because it is the flow that lets a sleeping camera control when it wakes.

If you are integrating cameras into an ecosystem, treat StreamUsage as the primary policy lever and wire it into your permission model from the start. Use the end-reason enumeration to give users truthful failure messages. And test against more than one camera implementation before you ship, because the specification is one year old and conformance is still settling.

If you are evaluating products, the checklist is short:

• Ask whether SFrame is negotiated, and for which stream usages. This is the real end-to-end encryption question.
• Ask whether Push AV Stream Transport can target a LAN endpoint, not only the vendor’s cloud.
• Ask which ICE transport policy the product defaults to, and whether relay can be disabled.
• Confirm the device is certified against Matter 1.5.1, not 1.5 — the multi-stream and PTZ fixes are substantive.
• For any new border router, confirm Thread 1.4 certification, which has been required for new applications since 1 January 2026.
• Treat privacy zones as a usability feature, and a physical shutter as the security control.

Frequently Asked Questions

Does Matter 1.5 mean my existing camera will work with any smart home app?

No. Matter 1.5 defines how a camera can be built and certified for interoperability; it does not retrofit existing hardware. Most shipping cameras cannot be updated, because the camera device types require clusters, WebRTC signalling and often encoder capabilities that were never in the original firmware design. You need a camera certified against Matter 1.5 or 1.5.1, plus an ecosystem controller that has shipped support for the camera device types.

Can a Matter camera work entirely locally without a cloud?

Architecturally, yes. Live view over WebRTC can complete on a LAN using host candidates without ever contacting a STUN or TURN server, and Push AV Stream Transport can target a local recorder. Whether a specific product exposes those paths is a vendor decision. The two things to check are the ICE transport policy the controller applies and whether the product’s recording configuration accepts a LAN destination rather than only the manufacturer’s cloud.

Why does Matter use WebRTC instead of RTSP or ONVIF?

Four reasons. WebRTC has built-in NAT traversal through ICE, STUN and TURN, which RTSP lacks entirely. It has real-time congestion control through RTCP feedback, so a degrading link produces softer video rather than a frozen frame. DTLS-SRTP encryption is mandatory rather than optional. And every phone, browser and TV platform already ships a hardened WebRTC stack, so ecosystems write signalling glue instead of a media engine.

Do Matter camera privacy zones actually stop the camera recording that area?

They instruct it to. The Zone Management cluster standardises the geometry and the intent, and the camera reports back that it accepted the configuration. But the masking itself happens in vendor firmware below the Matter boundary, and nothing in the interaction model lets a controller verify that pixels were suppressed before encoding, or that the mask applied to the recording stream as well as the live view. Treat it as a strong convenience feature, not an auditable control.

Can Matter cameras run over Thread?

Not for video. Thread’s 802.15.4 radio has a 250 kbit/s raw PHY rate shared across the whole mesh, while a single 1080p30 stream in the Matter SDK’s own reference configuration is advertised at 3,000 kbit/s — twelve times the entire channel. Even audio-only Opus at 96 kbit/s consumes around 38% of the raw rate. Snapshot-only devices on Thread are plausible, which is why Snapshot Camera is a separate device type, but streaming is not.

What is the difference between Matter 1.5 and Matter 1.5.1 for cameras?

Matter 1.5, from November 2025, introduced cameras: WebRTC streaming, two-way audio, PTZ, zones and recording. Matter 1.5.1, from March 2026, is a camera-focused maintenance release. It added multi-stream video and audio in a single structured session, HEIC snapshots, HLS and DASH upload using the CMAF Interface-2 profile, PTZ fixes for cameras whose home position sits at the edge of rotation, recording-configuration validation fixes, and chime and intercom refinements.

Further Reading

• Thread vs Matter: IoT connectivity protocols compared — the network layer underneath everything discussed here, and why the two are complementary rather than competing.
• Zero-trust architecture for industrial OT and IoT — the per-fabric access-control model in a setting where the enforcement boundary matters even more.
• DDS vs MQTT vs OPC UA: industrial messaging protocols — the same “pick the transport by the workload” argument applied to plant-floor data.
• Smart home protocols compared — background on the ecosystem Matter is consolidating.
• Matter 1.5 release announcement and Matter 1.5.1 release announcement — Connectivity Standards Alliance, primary sources for every specification claim above.
• Thread 1.4 specification release — Thread Group, for the credential-sharing and multi-network changes.

By Riju — about