Add Messaging, Voice, and Authentication to your apps with Vonage Communications APIs
Visit the Vonage API Developer PortalUnlock leaner, faster, and more scalable video sessions by funneling all subscriber streams through a single WebRTC peer connection.
As your sessions grow, so does the number of WebRTC peer connections each client has to maintain (one for every subscribed stream). Each connection carries its own ICE negotiation, DTLS handshake, and congestion-control state. That overhead can add up fast, especially on mobile devices.
Single Peer Connection (SPC) reduces the connection setup overhead. When enabled, all subscriber streams for a client are multiplexed over one shared peer connection to the Vonage Video Media Router, regardless of how many different publishers are in the session. The result is a lighter network footprint using fewer ports, smarter bandwidth management, and better scalability across all devices.
The Single Peer Connection feature is only available in routed sessions (sessions that use the Vonage Video Media Router). In sessions using adaptive media routing, SPC does not apply while media flows peer-to-peer between two participants, but it does apply once the session switches to using the Media Router. See The Vonage Video Media Router and media modes.
Enabling Single Peer Connection is one of the highest-impact optimizations you can make for multi-party video. Here is what you get:
Significantly lower resource consumption: Every peer connection comes with its own ports, sockets, ICE candidates, DTLS handshakes, and SRTP contexts. With dozens of subscribers this increases CPU, memory, and file-descriptor usage. SPC collapses all of that into a single connection, freeing up resources for your application.
Smarter, unified rate control: With separate peer connections, each runs its own congestion-control algorithm, competing against the others for the same link capacity. SPC gives the bandwidth estimator a single, unified view of the network for all media streams, which translates to more stable bitrate adaptation and fewer quality oscillations.
Support for larger sessions on mobile: Mobile devices have finite CPU, memory, and network resources, and iOS in particular limits the number of concurrent peer connections. By consolidating all subscriber streams into one peer connection, SPC lets mobile clients comfortably handle more streams in a single session.
Faster subscription setup: Adding a new subscriber no longer requires a full ICE/DTLS negotiation from scratch. The existing connection is reused, so new streams appear faster. This is especially noticeable in sessions where participants join and leave frequently.
Lower battery drain: Fewer active network paths mean fewer keep-alive packets and less radio wake-up on mobile, which ultimately translates to longer battery life for your end users.
Reduced network complexity: One connection means one set of NAT bindings, one TURN allocation (if needed), and one path through corporate firewalls. That simplifies deployment in restrictive network environments and cuts down on connectivity failures.
More predictable quality at scale: Because all media shares a single transport, bandwidth is distributed more fairly across streams. There are no "competing connections" starving each other, leading to a smoother, more consistent experience for every participant.
Applications benefit from Single Peer Connection whenever the number of subscribed streams starts to climb. Here are the scenarios where it makes the biggest difference:
Large interactive sessions: Virtual classrooms, group collaboration, and multi-party video calls can have many participants publishing at the same time. As the number of publishers grows, each subscribing client opens more peer connections. SPC keeps resource usage flat regardless of how many streams a client subscribes to. Keep in mind that your application should still prioritize which video widgets to display and manage which streams to subscribe to, since showing every participant on screen at once is rarely practical.
Mobile-first applications: If your users are on phones and tablets, SPC is highly recommended. Fewer connections mean less CPU churn, less memory pressure, and lower battery drain.
Bandwidth-constrained or variable networks: On congested Wi-Fi, cellular, or satellite links, a single congestion-control loop allocates bandwidth far more efficiently than a large number of competing connections. Users get smoother video with less buffering.
Corporate and restricted networks: Firewalls, proxies, and NATs can fail or add latency when they have to track many concurrent UDP flows. Reducing everything to one connection lowers the chance of connectivity issues behind strict network policies.
Rapid join/leave scenarios: In breakout rooms or any experience where participants frequently shuffle between groups, SPC eliminates the per-stream negotiation overhead, making transitions near-instantaneous.
Hybrid events with screen sharing: When presenters share screens alongside camera feeds, the total stream count per subscriber doubles. SPC keeps the overhead constant regardless of how many mixed streams a client is receiving. Because the unified rate control has visibility over all streams on the same connection, it will intelligently prioritize screen-sharing streams, allocating more bandwidth where sharpness and readability matter most.
SPC is only supported in routed sessions (sessions that use the Vonage Video Media Router). It is not available for relayed sessions because in a relayed session each client connects directly to every other client peer-to-peer. There is no central Media Router to multiplex streams through, so there is nothing to consolidate.
SPC is available starting with version 2.28.0 of the native SDKs and version 2.29.0 of the web SDK.
SPC is disabled by default. You must explicitly enable it when initializing the session on the client side. See Enabling Single Peer Connection.
SPC applies to subscriber connections only. The publisher still uses its own peer connection to send media to the Media Router.
To enable Single Peer Connection, configure it in the client SDK when creating or initializing the session. For a quick overview of SPC in the context of session creation, see the Single Peer Connection section of the Creating a Session guide. The following sections show how to enable it in each supported SDK.
Set the singlePeerConnection property to true in the options object you
pass to OT.initSession():
var session = OT.initSession(apiKey, sessionId, {
singlePeerConnection: true
});
Use the Session.Builder.setSinglePeerConnection() method:
Session session = new Session.Builder(context, apiKey, sessionId)
.setSinglePeerConnection(true)
.build();
Set the singlePeerConnection property on OTSessionSettings:
OTSessionSettings *settings = [[OTSessionSettings alloc] init];
settings.singlePeerConnection = YES;
OTSession *session = [[OTSession alloc] initWithApiKey:apiKey
sessionId:sessionId
delegate:self
settings:settings];
Set the SinglePeerConnection property on the Session.Builder class:
var session = new Session.Builder(Context.Instance, apiKey, sessionId)
{
SinglePeerConnection = true
}.Build();
Use the otc_session_settings_set_single_peer_connection() function:
otc_session_settings *settings = otc_session_settings_new();
otc_session_settings_set_single_peer_connection(settings, OTC_TRUE);
otc_session *session = otc_session_new_with_settings(apiKey, sessionId, &callbacks, settings);
Use the otc_session_settings_set_single_peer_connection() function:
otc_session_settings *settings = otc_session_settings_new();
otc_session_settings_set_single_peer_connection(settings, OTC_TRUE);
otc_session *session = otc_session_new_with_settings(apiKey, sessionId, &callbacks, settings);
Set the enableSinglePeerConnection property to true in the options prop
of the OTSession component:
<OTSession
apiKey={apiKey}
sessionId={sessionId}
token={token}
options={{ enableSinglePeerConnection: true }}
/>
Single Peer Connection works alongside scalable video. When both features are enabled, the Media Router still delivers multi-quality layers to each subscriber through the shared peer connection. Each subscriber can receive a different resolution and frame rate layer as network conditions change, exactly as it would with separate peer connections.
Audio fallback continues to operate normally with SPC enabled. If a subscriber's network degrades, the Media Router can still drop the video component and deliver audio only for the affected stream, independent of the other streams carried on the same peer connection.
When SPC is enabled, the sender-side statistics bandwidth estimation is shared across all subscribers in the single peer connection. The maximum bitrate represents the highest bitrate the peer connection can estimate, while the current bitrate reflects each audio-video bundle's bitrate. When assessing available bandwidth, calculate the total bandwidth estimation by summing the individual bundle estimations.
For more information, see the client observability guide.
End-to-end encryption is compatible with Single Peer Connection. Media streams are encrypted individually before being multiplexed over the shared peer connection.
Enable SPC for sessions with many publishing clients: If your application regularly has sessions with more than a few participants, enabling SPC can noticeably reduce resource consumption and improve stability.
Test on target devices: While SPC reduces resource usage in general, always validate on the specific devices and network conditions your users will encounter.
Monitor bandwidth with sender-side statistics: Because all subscriber streams share a single transport, use sender-side statistics to understand the total available bandwidth and adapt your application accordingly.