Draft
This page is not complete.
The RTCConfiguration
dictionary is used to provide configuration options for an RTCPeerConnection
. It may be passed into the constructor when instantiating a connection, or used with the RTCPeerConnection.getConfiguration()
and 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
RTCBundlePolicy
. If this value isn't included in the dictionary, "balanced"
is assumed.certificates
Optional
Array
of objects of type RTCCertificate
which are used by the connection for authentication. If this property isn't specified, a set of certificates is generated automatically for each RTCPeerConnection
instance. Although only one certificate is used by a given connection, providing certificates for multiple algorithms may improve the odds of successfully connecting in some circumstances. See Using certificates below for additional information. RTCPeerConnection.setConfiguration()
.iceCandidatePoolSize
Optional
RTCPeerConnection.setLocalDescription()
is called. iceServers
Optional
RTCIceServer
objects, each describing one server which may be used by the ICE agent; these are typically STUN and/or TURN servers. If this isn't specified, the ICE agent may choose to use its own ICE servers; otherwise, the connection attempt will be made with no STUN or TURN server available, which limits the connection to local peers.iceTransportPolicy
Optional
RTCIceTransportPolicy
enum. If this isn't specified, "all"
is assumed.peerIdentity
Optional
DOMString
which specifies the target peer identity for the RTCPeerConnection
. If this value is set (it defaults to null
), the RTCPeerConnection
will not connect to a remote peer unless it can successfully authenticate with the given name.rtcpMuxPolicy
Optional
RTCRtcpMuxPolicy
enum. The default is "require"
.The RTCBundlePolicy
enum defines string constants which are used to request a specific policy for gathering ICE candidates if the remote peer isn't compatible with the SDP BUNDLE standard for bundling multiple media streams on a single transport link.
In technical terms, a BUNDLE lets all media flows between two peers flow across a single 5-tuple; that is, from the same IP and port on one peer to the same IP and port on the other peer, using the same transport protocol.
Constant | Description |
---|---|
"balanced" | On BUNDLE-aware connections, the ICE agent should gather candidates for all of the media types in use (audio, video, and data). Otherwise, the ICE agent should only negotiate one audio and video track on separate transports. |
"max-compat" | The ICE agent should gather candidates for each track, using separate transports to negotiate all media tracks for connections which aren't BUNDLE-compatible. |
"max-bundle" | The ICE agent should gather candidates for just one track. If the connection isn't BUNDLE-compatible, then the ICE agent should negotiate just one media track. |
The RTCIceTransportPolicy
enum defines string constants which can be used to limit the transport policies of the ICE candidates to be considered during the connection process.
Constant | Description |
---|---|
"all" | All ICE candidates will be considered. |
"public"
| Only ICE candidates with public IP addresses will be considered. Removed from the specification's May 13, 2016 working draft. |
"relay" | Only ICE candidates whose IP addresses are being relayed, such as those being passed through a TURN server, will be considered. |
The RTCRtcpMuxPolicy
enum defines string constants which specify what ICE candidates are gathered to support non-multiplexed RTCP. <<<add a link to info about multiplexed RTCP.
Constant | Description |
---|---|
"negotiate" | Instructs the ICE agent to gather both RTP and RTCP candidates. If the remote peer can multiplex RTCP, then RTCP candidates are multiplexed atop the corresponding RTP candidates. Otherwise, both the RTP and RTCP candidates are returned, separately. |
"relay" | Tells the ICE agent to gather ICE candidates for only RTP, and to multiplex RTCP atop them. If the remote peer doesn't support RTCP multiplexing, then session negotiation fails. |
When you wish to provide your own certificates for use by an RTCPeerConnection
instead of having the RTCPeerConnection
generate them automatically, you do so through calls to 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: "[email protected]", credential: "webrtcdemo" }, { urls: ["stun:stun.example.com", "stun:stun-1.example.com"] }] }; var pc = new RTCPeerConnection(configuration);
© 2005–2017 Mozilla Developer Network and individual contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/API/RTCConfiguration