--- title: RTCConfiguration slug: Web/API/RTCConfiguration translation_of: Web/API/RTCConfiguration ---
{{APIRef("WebRTC")}}{{draft}}
The RTCConfiguration
dictionary is used to provide configuration options for an {{domxref("RTCPeerConnection")}}. It may be passed into the constructor when instantiating a connection, or used with the {{domxref("RTCPeerConnection.getConfiguration()")}} and {{domxref("RTCPeerConnection.setConfiguration()")}} methods, which allow inspecting and changing the configuration while a connection is established.
The options include ICE server and transport settings and identity information.
bundlePolicy
{{optional_inline}}RTCBundlePolicy
. If this value isn't included in the dictionary, "balanced"
is assumed.certificates
{{optional_inline}}iceCandidatePoolSize
{{optional_inline}}iceServers
{{optional_inline}}iceTransportPolicy
{{optional_inline}}RTCIceTransportPolicy
enum. If this isn't specified, "all"
is assumed.peerIdentity
{{optional_inline}}null
), the RTCPeerConnection
will not connect to a remote peer unless it can successfully authenticate with the given name.rtcpMuxPolicy
{{optional_inline}}RTCRtcpMuxPolicy
enum. The default is "require"
.{{page("/en-US/docs/Web/API/RTCPeerConnection", "RTCBundlePolicy enum", 0, 1)}}
{{page("/en-US/docs/Web/API/RTCPeerConnection", "RTCIceTransportPolicy enum", 0, 1)}}
{{page("/en-US/docs/Web/API/RTCPeerConnection", "RTCRtcpMuxPolicy enum", 0, 1)}}
When you wish to provide your own certificates for use by an {{domxref("RTCPeerConnection")}} instead of having the RTCPeerConnection
generate them automatically, you do so through calls to {{domxref("RTCPeerConnection.generateCertificate()")}}.
This attribute supports providing multiple certificates because even though a given DTLS connection uses only one certificate, providing multiple certificates allows support for multiple encryption algorithms. The implementation of RTCPeerConnection
will choose which certificate to use based on the algorithms it and the remote peer support, as determined during DTLS handshake.
If you don't provide certificates, new ones are generated automatically. One obvious benefit to providing your own is identity key continuity—if you use the same certificate for subsequent calls, the remote peer can tell you're the same caller. This also avoids the cost of generating new keys.
<<<link to added info on identity>>>
The configuration below establishes two ICE servers. The first one, stun:stun.services.mozilla.com
, requires authentication, so the username and password are provided. The second server has two URLs: stun:stun.example.com
and stun:stun-1.example.com
.
var configuration = { iceServers: [{ urls: "stun:stun.services.mozilla.com", username: "louis@mozilla.com", credential: "webrtcdemo" }, { urls: ["stun:stun.example.com", "stun:stun-1.example.com"] }] }; var pc = new RTCPeerConnection(configuration);