BUNDLE is an SDP feature used, among others, in WebRTC. The idea is simple; send all media flows (those m= lines in the SDP) using the same “5 tuple”, meaning from the same IP and port, to the same IP and port, and over the same transport protocol.
One obvious benefit of doing this is reducing the ICE negotiation time as the number of ICE candidates is reduced.
While there are clear benefits to using one single BUNDLE for all media flows when possible, there are sometimes requirements to separate media flows. For example: to separate audio from video and bundle each media type. In this example this would result in 2 SDP BUNDLEs.
Discussions at IETF 92 were around the need (or lack thereof) to allow for multiple BUNDLEs and how bandwidth parameters in SDP should be calculated.
In the Details section below we explain the different configuration options. You should define the best settings based on your application requirements and preference.
In progress.
In the JavaScript APIs for WebRTC, there is a configuration parameter called RTCConfiguration that is passed into the constructor when a new Peer Connection is created. This object has properties for setting the STUN and TURN servers (iceServers), for indicating which paths to use for transport (iceTransportPolicy), for setting the peer identity policy (peerIdentity), and for controlling how BUNDLE is to be used (bundlePolicy). Here is an example use of bundlePolicy:
myConfig = {bundlePolicy: “max-bundle”};
pc = new RTCPeerConnection(myConfig);
There are three valid values that can be set for this policy: max-bundle, max-compat, and balanced. In all cases the browser will attempt to bundle all tracks together over one connection (meaning a specific local IP/port and remote IP/port). The different policy values affect what happens if the peer does not support BUNDLE.
So, if the peer does not support BUNDLE:
- max-bundle instructs the browser to pick one media track to negotiate and will only send that one
- max-compat instructs the browser to separate each track into its own connection
- balanced instructs the browser to pick two tracks to send — one audio and one video. This is the default
Note that max-compat is the most likely to be backwards compatible with non-BUNDLE-aware legacy devices.
Two separate BUNDLE discussions of relevance to WebRTC happened at IETF 92:
- One long-standing question is whether it should be a) possible, and b) mandatory to allow for there to be multiple BUNDLE groups or, alternatively, only one. The use case for allowing multiple BUNDLE groups is that there might be traffic control benefits to sending audio and video via separate ports, for example. Although discussion is still ongoing here, there was agreement at the meeting that WebRTC browsers would not be required to support multiple (separate) BUNDLE groups.
- In SDP there are various parameters that can be set. One area of increasing interest to implementers (not an API issue, at least not yet) is the control over bandwidth used. In SDP the b= parameter can be used to set total bandwidth (b=CT), bandwidth per media flow (b=AS), and bandwidth for RTCP reports (SR and RR). There was discussion, but no final decisions, as to how BUNDLE would affect how these values are interpreted. Most interestingly, it was obvious that there is limited agreement as to exactly what these values are supposed to represent and how they are to be calculated. The plan is to be more precise in how they are computed in the context of BUNDLE, and specifically in the context of WebRTC’s likely use of BUNDLE.