RTCConfiguration - Web API 接口参考 编辑

草案
本页尚未完工.

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.

Properties

bundlePolicy 可选

Specifies how to handle negotiation of candidates when the remote peer is not compatible with the SDP BUNDLE standard. This must be one of the values from the enum RTCBundlePolicy. If this value isn't included in the dictionary, "balanced" is assumed.

certificates 可选

An 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. 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 RTCPeerConnection.setConfiguration().

iceCandidatePoolSize 可选

一个16bit无符号整型值，代表预获取的ICE candidate pool的大小。 默认为 0 (意味着不会发生candidate的预获取)。在某些情况下，由于预获取了ICE candidate，在 RTCPeerConnection.setLocalDescription() 被调用时，被预获取的candidate可被立刻检查，从而导致可以更快的建立连接。 改变 ICE candidate pool的大小将触发启动 ICE gathering。

iceServers 可选

An array of 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 可选

The current ICE transport policy; this must be one of the values from the RTCIceTransportPolicy enum. If this isn't specified, "all" is assumed.

peerIdentity 可选

A 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 可选

The RTCP mux policy to use when gathering ICE candidates, in order to support non-multiplexed RTCP. The value must be one of those from the RTCRtcpMuxPolicy enum. The default is "require".

Constants

RTCBundlePolicy enum

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.

Note: In technical terms, a BUNDLE lets all media flow 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.

RTCIceTransportPolicy enum

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.

RTCRtcpMuxPolicy enum

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.

Using certificates

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>>>

Example

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);