pc = new RTCPeerConnection([configuration]);
Specifies how to handle negotiation of candidates when the remote peer is not compatible with the SDP BUNDLE standard. If the remote endpoint is BUNDLE-aware, all media tracks and data channels are bundled onto a single transport at the completion of negotiation, regardless of policy used, and any superfluous transports that were created initially are closed at that point.
In technical terms, a BUNDLE lets all media flow between two peers flow across a single 5-tuple; that is, from a single IP and port on one peer to a single IP and port on the other peer, using the same transport protocol.
This must be one of the following string values, if not
The ICE agent initially creates one
RTCDtlsTransportfor each type of content added: audio, video, and data channels. If the remote endpoint is not BUNDLE-aware, then each of these DTLS transports handles all the communication for one type of data.
The ICE agent initially creates one
RTCDtlsTransportper media track and a separate one for data channels. If the remote endpoint is not BUNDLE-aware, everything is negotiated on these separate DTLS transports.
The ICE agent initially creates only a single
RTCDtlsTransportto carry all of the
RTCPeerConnection's data. If the remote endpoint is not BUNDLE-aware, then only a single track will be negotiated and the rest ignored.
Arrayof objects of type
RTCCertificatewhich are used by the connection for authentication. If this property isn't specified, a set of certificates is generated automatically for each
RTCPeerConnectioninstance. 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 for further information.
Note: This configuration option cannot be changed after it is first specified; once the certificates have been set, this property is ignored in future calls to
An unsigned 16-bit integer value which specifies the size of the prefetched ICE candidate pool. The default value is 0 (meaning no candidate prefetching will occur). You may find in some cases that connections can be established more quickly by allowing the ICE agent to start fetching ICE candidates before you start trying to connect, so that they're already available for inspection when
Note: Changing the size of the ICE candidate pool may trigger the beginning of ICE gathering.
An array of
RTCIceServerobjects, 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 connection attempt will be made with no STUN or TURN server available, which limits the connection to local peers.
The current ICE transport policy; if the policy isn't specified,
allis assumed by default, allowing all candidates to be considered. Possible values are:
All ICE candidates will be considered.
Only ICE candidates with public IP addresses will be considered. Removed from the specification's May 13, 2016 working draft.
Only ICE candidates whose IP addresses are being relayed, such as those being passed through a STUN or TURN server, will be considered.
DOMStringwhich specifies the target peer identity for the
RTCPeerConnection. If this value is set (it defaults to
RTCPeerConnectionwill not connect to a remote peer unless it can successfully authenticate with the given name.
The RTCP mux policy to use when gathering ICE candidates, in order to support non-multiplexed RTCP. Possible values are:
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.
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. This is the default value.
RTCPeerConnection 对象, 如果指定了配置信息，它按照指定配置进行配置，否则,它将按照基本配置进行配置。
|WebRTC 1.0: Real-time Communication Between Browsers
|Candidate Recommendation||Initial definition.|
|特性||Chrome||Edge||Firefox (Gecko)||Internet Explorer||Opera||Safari (WebKit)|
|Basic support||(Yes)||(Yes)||22 (22)||?||?||?|
|特性||Android Webview||Chrome for Android||Edge||Firefox Mobile (Gecko)||Firefox OS||IE Mobile||Opera Mobile||Safari Mobile|
|Basic support||未实现||(Yes)||(Yes)||24.0 (24)||?||?||?||?|