A camera supplier says its product uses P2P, so the video does not go through the cloud. That sounds reassuring. But the camera may still contact a server to find the phone, authenticate the session, or fall back to a relay when a direct connection cannot be established.
P2P does not necessarily mean server-free. In a direct P2P session, video can travel between the camera and viewing device without a media relay. Servers may still help establish the connection. If a direct route is unavailable, some systems send the live video through a relay instead. The actual route depends on the implementation and network conditions.
For a consumer, the distinction is mostly invisible. They open an app, tap a camera, and see a live image.
For a brand developing a connected camera, however, the distinction affects operating costs, video performance, privacy claims, reliability, technical support and dependence on third-party services.
The practical question is not simply whether a camera supports P2P. It is: which systems are involved when someone starts watching, and which of those systems actually carry the video?
Two live-view paths that can look identical in the app
Consider an indoor camera connected to a home router. The owner opens the viewing app while away from home.
Two possible outcomes are shown below. Both may display the same live video. They do not necessarily use the same network route.
The video packets travel between endpoints without a dedicated media relay. The route can still traverse the public internet, routers and ISP infrastructure.
The video packets pass through an intermediary server that forwards them between the endpoints. This may be a fallback when direct connectivity is unavailable.
FIG. 01 — Conceptual architectures. The actual route depends on the camera, SDK, networking protocol and selected connection path. A proprietary implementation need not use WebRTC or TURN.
The diagram exposes an important difference: connection setup, video transport and video storage are separate functions.
A camera may use a server to initiate a direct session without sending the subsequent video through that server. Another camera may route all remote sessions through a relay. A third may record clips in cloud storage while using a direct path for live viewing.
Therefore, a statement such as “supports P2P” does not describe the complete system architecture.
STUN, TURN and ICE are not interchangeable
In standards-based real-time communication systems, three technologies help explain how devices behind home routers establish connections.
STUN
STUN can help a device discover the public-facing address and port assigned by a network address translator, and can support connectivity checks. A STUN server does not, by that role alone, carry the ongoing video stream.
ICE
ICE collects candidate connection paths, checks which pairs work and selects a viable route. That route may be direct or relayed, depending on the available candidates and implementation.
TURN
TURN allows an intermediary server to relay packets between endpoints. In a TURN-relayed media session, those packets pass through the relay even though the user may still see a normal live view.
These are established internet networking standards, not a universal description of every commercial camera SDK. Proprietary P2P solutions may use different discovery, authentication and relay mechanisms.
The standards are useful because they make the roles clearer. STUN is not the same as TURN. A signaling service is not automatically a media relay. And a successful direct connection is not proof that the same path will work on every network.
What happens before the first video frame?
For a remote camera session, there may be several operations between tapping “Live View” and receiving video.
Identify and authorize the viewer
The system determines which user or application is requesting access and whether that user is permitted to view the device. Depending on the product, this may involve a local pairing mechanism, an app account or a remote authentication service.
Discover possible connection routes
The endpoints need information about how they might reach one another. In an ICE-based design, this can involve local addresses, server-reflexive candidates and relay candidates.
Establish the usable media path
The connection system determines which available path can carry the session. A direct route may work. Under other network conditions, a relayed route may be selected if the implementation supports it.
Deliver the live video
The camera encodes the video, sends it across the selected transport, and the viewing device decodes it. Session quality may change with bandwidth, congestion, packet loss, device processing and the selected route.
A product brochure usually describes the final step. A buyer evaluating an OEM/ODM platform should also understand the first three.
If the authentication service becomes unavailable, a new remote session may fail even when the camera and phone both have working internet connections. If the relay service is unavailable, remote viewing may fail on networks that cannot establish a direct path.
The exact failure behavior must be verified for the proposed implementation. It cannot be derived from the word “P2P” alone.
Local viewing, remote viewing and cloud recording are three different requirements
Camera discussions often combine these functions under the general label “cloud camera.” This hides useful engineering distinctions.
| Requirement | Technical question | What a buyer should verify |
|---|---|---|
| Local viewing | Can the camera send video to a local screen or app within the same premises? | Whether viewing is independent of internet access, remote authentication and vendor services. |
| Remote P2P viewing | Can endpoints establish a direct media path over the available networks? | Actual connection type, session setup dependencies and supported network conditions. |
| Relayed remote viewing | Does the system forward live video through an intermediary? | Relay operator, server locations, security controls and ongoing bandwidth costs. |
| Cloud recording | Are video recordings or snapshots uploaded to a remote storage service? | Storage architecture, retention, access rights and deletion responsibilities. |
TABLE 01 — These functions can coexist, but none automatically proves the presence or absence of another.
A system can use a direct P2P path for live view while also offering cloud recording. Conversely, a system may relay live video without retaining a recording of that session.
Relaying is not the same as storing. Both need to be documented independently.
This also explains why a dedicated no-WiFi camera-and-display system belongs in a separate category. Its local radio link is not the same as a Wi-Fi camera that uses P2P for remote internet viewing.
For products with both a dedicated local display and a phone app, the two viewing paths should be specified and tested separately. See the Camera & Video Monitoring OEM/ODM architectures for how these project categories differ.
How to test a supplier’s P2P claim
One successful video demonstration proves that the tested connection worked under those conditions. It does not prove which route was used or what happens on a different network.
The test plan should deliberately change the network environment and capture the selected media path, rather than relying only on what appears on the screen.
| Test condition | What it reveals | Evidence to request |
|---|---|---|
| Phone and camera on the same LAN | Whether local viewing is supported and whether the app still depends on an external service. | Video demonstration, connection status and documented endpoints. |
| Phone on mobile data | Whether remote viewing works and which media path is selected. | Session logs showing direct or relay transport where available. |
| Restrictive NAT or firewall environment | Whether direct connectivity fails and whether a relay fallback is available. | Connection outcome, candidate or transport selection and failure details. |
| Camera internet disconnected | Which local functions, if any, operate without the external connection. | Demonstration of promised offline functions and recovery. |
| Remote service deliberately unavailable | Whether login, session setup or relay dependence affects viewing. | Controlled test results and documented service dependencies. |
| Network changes during live view | Whether the session reconnects, changes transport or requires user intervention. | Time-stamped logs, user-visible behavior and reconnection records. |
TABLE 02 — A proposed validation matrix, not test results for a particular True Bond product or third-party SDK.
For a WebRTC-based implementation, connection statistics can help identify the active candidate pair and whether a relay candidate is involved. For a proprietary SDK, the supplier may need to provide equivalent diagnostic information.
The buyer should not assume that a consumer app exposes this detail. Diagnostic access may require a development build, SDK console or engineering log.
Important: A network test should be performed with an authorized device and test environment. Raw logs may contain device identifiers, network addresses, access tokens or other sensitive information. Share redacted evidence where appropriate.
P2P does not automatically mean private, encrypted or server-independent
Network architecture is only one part of security.
A direct media path may reduce reliance on a video relay, but that does not establish whether the camera uses adequate authentication, how encryption keys are handled, or who can authorize another viewer.
Similarly, relayed traffic does not automatically mean the relay operator can view the video content. If the media remains protected end to end, an intermediary may forward encrypted packets without having the keys needed to decrypt them.
Whether that protection actually exists depends on the implemented protocols and key-management design.
Routing and encryption answer different questions
Which systems carry the video packets between the camera and viewer?
Which parties have the technical ability to decrypt the video, and where are the necessary keys held?
A meaningful camera security review should therefore ask four separate questions:
- Authentication: Who can register a camera and authorize another viewer?
- Transport protection: How is live video protected while it moves between endpoints?
- Key management: Which systems or parties can access the keys needed to decrypt the content?
- Service visibility: What metadata, logs and diagnostic information are accessible to the manufacturer or SDK provider?
Those answers are more informative than labels such as “secure P2P,” “bank-grade encryption” or “100% private.”
If the product is sold as end-to-end encrypted, the brand should obtain technical evidence supporting the actual encryption and key-management design.
Relay usage can change the economics of a camera product
When video travels directly between endpoints, there may be no third-party media relay carrying that particular session.
When video is relayed through an external service, that service must handle the traffic generated by the supported sessions.
The operating cost depends on factors such as the amount of relayed traffic, concurrent sessions, server location, provider pricing and the commercial contract.
A supplier quoting a low camera unit price may be using an SDK or service arrangement with separate recurring charges. That is not necessarily unreasonable, but it should be explicit.
Useful cost model: Relay traffic depends on the actual stream bit rate, the time spent using relayed connections, and the number of sessions. Provider charges may introduce additional terms. Do not use an assumed P2P success rate as a substitute for measured usage data.
The more important question is not “How much does the cloud cost?” but “Which services are required to keep the product functioning, and who remains responsible for them?”
A brand should also understand what happens if a vendor changes pricing, discontinues an SDK, restricts a service region or ends support for an older integration.
These questions connect directly to the six decisions to make before camera OEM/ODM tooling : a technically working connection is not the same thing as a sustainable commercial architecture.
Ten questions for a camera SDK or OEM supplier
The answers to these questions should be specific to the platform offered, not generic descriptions of what P2P technology can do.
P2P Camera Supplier Review
Use this checklist during technical evaluation and RFQ discussions.
- What does “P2P” mean in your specific platform? Direct media, server-assisted connection setup, or a broader proprietary service?
- Which servers are contacted before live view starts? Identify their functions rather than describing all of them as “cloud.”
- Under what conditions does video use a relay? Ask how the selected connection is determined.
- How can we verify the active media path? Request development logs, SDK diagnostics or equivalent technical evidence.
- Who operates the signaling, authentication and relay services? Include third-party providers where applicable.
- Where are the services hosted, and can their locations change? Define the scope needed for the intended markets.
- How is live video encrypted, and who controls the keys? Distinguish transport encryption from claims of end-to-end encryption.
- Is video recorded or retained anywhere? Separate optional cloud recording from live-view relay traffic.
- What are the recurring commercial terms? Check license fees, relay traffic charges, account limits and maintenance obligations.
- What happens when a required service is unavailable or discontinued? Document offline behavior, recovery and the possible transition path.
A useful supplier response should include a system architecture diagram, a dependency list, a description of encryption and account responsibilities, and test evidence for the proposed connection behavior.
Not every project requires a custom video transport system. Many brands will choose an established platform rather than commission new connection technology. The critical step is understanding what that platform provides and what it depends on.
What this means for a hybrid baby monitor or connected camera project
Consider a proposed dual-view baby monitor: a dedicated display for watching at home, and a mobile app for remote access.
If the local display uses a separate dedicated wireless link, its intended operation can be independent of internet-based remote viewing.
The app path has different requirements. Its ability to connect, route video and authorize a viewer depends on the selected software architecture.
The engineering brief should therefore contain at least two independent acceptance scenarios:
One product, two sets of connection requirements
Specify independent pairing, local video, reception behavior and what happens when the home internet is unavailable.
Specify remote authentication, direct or relayed media, service dependencies, reconnection and ownership of associated accounts.
The example is a design framework, not a verified feature claim for an existing True Bond model.
At True Bond, the initial architecture review for camera OEM/ODM work distinguishes dedicated local links from Wi-Fi/app and hybrid project requirements.
The selected SDK, video transport, application functions and service ownership must be defined for each project rather than assumed from a category label.
Buyers considering a custom integration can review our OEM/ODM solutions and engineering and production process before preparing an RFQ.
Engineering standards behind the explanation
The distinctions between connectivity checks, direct media and relayed media are supported by the following primary technical references.
RFC 8445 — ICE: Describes candidate gathering, connectivity checks and selection of working communication paths. Read the RFC .
RFC 8489 — STUN: Describes mechanisms used in NAT traversal, including address discovery and connectivity checking. Read the RFC .
RFC 8656 — TURN: Defines a protocol that enables an intermediary to relay packets between communicating endpoints. Read the RFC .
MDN WebRTC Connectivity: Explains ICE candidate types, including direct and relay candidates, for WebRTC-based connections. Read the technical guide .
These references explain general networking mechanisms. They do not establish which protocols, SDKs or security controls are present in a specific True Bond product or supplier platform.
P2P Camera FAQ
Does a P2P security camera use a server?
It may. A P2P camera can use servers for device discovery, authentication or connection setup. Depending on the network and implementation, it may also use a relay to transport the video. The supplier should document these roles separately.
Is a STUN server the same as a TURN relay?
No. STUN supports functions such as discovering the mapped network address and checking connectivity. TURN enables packets to be forwarded through a relay server when the selected connection uses that route.
Is P2P always faster than a cloud relay?
No universal performance guarantee follows from the connection label. A direct path avoids a dedicated media relay, but actual delay depends on network routing, congestion, device processing, encoding and decoding. Compare both paths using the same test conditions.
Does cloud relay mean the video is stored?
Not necessarily. Relaying means an intermediary forwards traffic. Recording means video is retained in storage. A product may implement one, both or neither. Buyers should verify the actual behavior.
Can a camera use P2P without internet access?
Some products support local viewing over the same network without internet access. Remote viewing between separate networks generally requires external connectivity. Whether a particular app can operate locally without remote services must be tested.
Is P2P automatically more private or secure?
No. P2P describes an aspect of the connection architecture. Privacy and security also depend on authentication, encryption, key management, SDK behavior and data handling. A direct route alone does not verify those protections.
Building a camera product with remote viewing?
A clear specification should describe more than the camera resolution and the app interface. Tell us your intended use, local and remote viewing requirements, target markets and software expectations.
True Bond supports camera hardware, PCBA, wireless integration and firmware development for OEM/ODM projects. Video SDK and connected-service requirements are reviewed as part of the project scope before a solution is committed.
Discuss Your Camera Project →