The RTCConfiguration dictionary's bundlePolicy property is a string value indicating which SDP bundling policy, if any, to use for the underlying RTP streams used by an RTCPeerConnection.

The configuration object is used as an input to the RTCPeerConnection() constructor.


let rtcConfiguration = {
  bundlePolicy: policy

rtcConfiguration.bundlePolicy = policy;


A DOMString identifying the SDP bundling policy to use for the RTP streams used by the RTCPeerConnection. This string, which must be a member of the RTCBundlePolicy enumeration, has the following possible values:

The ICE agent begins by creating one RTCDtlsTransport to handle each type of content added: one for audio, one for video, and one for the RTC data channel, if applicable. If the remote peer isn't BUNDLE-aware, the ICE agent chooses one audio track and one video track and those two tracks are each assigned to the corresponding RTCDtlsTransport. All other tracks are ignored by the connection. This is the default, and most compatible, policy.
The ICE agent intially creates one RTCDtlsTransport for each media track and a separate one for the RTCDataChannel, if one is created. If the remote endpoint can't handle bundling, each media track is negotiated on its own separate transport. This introduces bundling but will fall back to not bundling if the remote peer can't handle it.
The ICE agent starts by creating a single RTCDtlsTransport to handle all of the connection's media. If the remote peer isn't bundle-compatible, only one media track is negotiated and the rest are ignored. This maximizes bundling at the risk of losing tracks if the remote peer can't do bundling.

If any other value is specified, no configuration is specified when creating the RTCPeerConnection, or if the bundlePolicy property isn't included in the RTCConfiguration object specified when creating the connection, balanced is assumed.


The bundlePolicy configuration option for an RTCPeerConnection specifies how the ICE agent should handle negotiation if the remote peer isn't compatible with the SDP BUNDLE standard. If the remote peer is bundle compatible, the policy is moot and all media tracks and the data channel are bundled onto a single RTCDtlsTransport at the completion of the negotiation process. Any other transports that were used during negotiation are then closed.

In technical terms, an SDP BUNDLE lets all of the media tracks (identified in the SDP from the m= lines) stream between two peers across a single 5-tuple, that is, from a single IP and port on one peer to a single IP and port on another peer, all using the same RTCDtlsTransport.

The goal of bundling is to optimize performance by reducing the overhead of having multiple transports in play. The fewer RTP transports or bundles of RTP streams you have, the better the network performance will be.

All current major browsers are BUNDLE compatible.


The following example creates a new RTCPeerConnection with a configuration setting the connection's bundlePolicy to max-compat to maximize compatibility while attempting to optimize network use. It also specifies stun:stun.example.com as the STUN server for ICE to use during negotiation.

let config = {
  iceServers: [
      urls: [ "stun:stun.example.com" ]
  bundlePolicy: "max-compat"

let pc = new RTCPeerConnection(config);


WebRTC 1.0: Real-Time Communication Between Browsers (WebRTC 1.0)
# dom-rtcconfiguration-bundlepolicy

Browser compatibility

BCD tables only load in the browser

See also