WebRTC-PeerConnection.RTCConfigu

WebRTC通信最主要的配置

public static class RTCConfiguration {

//收集的策略类型，目前可供选择的有ALL(全部收集),NOHOST(不收集host类的策略信息),RELAY(只使用服务器的策略信息，简言之就是不通过P2P，只走服务端流量),NONE(不收集策略信息，目前作用未知)。一般来说，如果你想减少流量，那么就用ALL，WebRTC会在能打通P2P情况下使用P2P；如果你想要保证客户端的联通率，那么RELAY是你最好的选择。
 public IceTransportsType iceTransportsType;

//服务端的候选地址，主要是用于客户端之间建立连接前的通信。
 public List<IceServer> iceServers;

//协商策略，balanced、max-compat、max-bundle,基本上是选择max-bundle，主要是防止另一个客户端属于策略不可协商型。
 public BundlePolicy bundlePolicy;

//实时传输控制协议多路策略，negotiate、require，第一个是获取实时传输控制协议策略和实时传输协议策略，第二个只获取实时传输协议策略，如果另一个客户端不支持实时传输控制协议，那么协商就会失败。Tiki客户端测试发现Require比较适合移动客户端。
 public RtcpMuxPolicy rtcpMuxPolicy;

//TCP候选策略控制开关，只有Enable和Disable，TCP策略虽然有握手来保证传输到达率，但这也是效率上最致命的，会极大拉低视频传输效率，所以建议不开启，除非有特别的需求。
 public TcpCandidatePolicy tcpCandidatePolicy;

//候选网络策略，属于新出的策略，有ALL和LowCost两个值，暂时未知作用，如果有童鞋了解的话，可以交流下。
 public CandidateNetworkPolicy candidateNetworkPolicy;

 public int audioJitterBufferMaxPackets;

 public boolean audioJitterBufferFastAccelerate;

 public int iceConnectionReceivingTimeout;

 public int iceBackupCandidatePairPingInterval;

//加密类型，如果没有特殊需求，不建议更改。
 public KeyType keyType;

//收集策略时间段，有GATHER_ONCE和 GATHER_CONTINUALLY两种值，默认值为GATHER_ONCE，可以不用改。
 public ContinualGatheringPolicy continualGatheringPolicy;

 public int iceCandidatePoolSize;

 public boolean pruneTurnPorts;

 public boolean presumeWritableWhenFullyRelayed;

 public RTCConfiguration(List<IceServer> iceServers) {

 iceTransportsType = IceTransportsType.ALL;

 bundlePolicy = BundlePolicy.BALANCED;

 rtcpMuxPolicy = RtcpMuxPolicy.NEGOTIATE;

 tcpCandidatePolicy = TcpCandidatePolicy.ENABLED;

 candidateNetworkPolicy = candidateNetworkPolicy.ALL;

 this.iceServers = iceServers;

 audioJitterBufferMaxPackets = 50;

 audioJitterBufferFastAccelerate = false;

 iceConnectionReceivingTimeout = -1;

 iceBackupCandidatePairPingInterval = -1;

 keyType = KeyType.ECDSA;

 continualGatheringPolicy = ContinualGatheringPolicy.GATHER_ONCE;

 iceCandidatePoolSize = 0;

 pruneTurnPorts = false;

 presumeWritableWhenFullyRelayed = false;

 }

1. IceTransportsType：收集的策略类型，目前可供选择的有ALL(全部收集),NOHOST(不收集host类的策略信息),RELAY(只使用服务器的策略信息，简言之就是不通过P2P，只走服务端流量),NONE(不收集策略信息，目前作用未知)。一般来说，如果你想减少流量，那么就用ALL，WebRTC会在能打通P2P情况下使用P2P；如果你想要保证客户端的联通率，那么RELAY是你最好的选择。
2. bundlePolicy：协商策略，balanced, max-compat, max-bundle,基本上是选择max-bundle，主要是防止另一个客户端属于策略不可协商型。
3. rtcpMuxPolicy：实时传输控制协议多路策略，negotiate, require，第一个是获取实时传输控制协议策略和实时传输协议策略，第二个只获取实时传输协议策略，如果另一个客户端不支持实时传输控制协议，那么协商就会失败。Tiki客户端测试发现Require比较适合移动客户端。
4. tcpCandidatePolicy：TCP候选策略控制开关，只有Enable和Disable，TCP策略虽然有握手来保证传输到达率，但这也是效率上最致命的，会极大拉低视频传输效率，所以建议不开启，除非有特别的需求。
5. candidateNetworkPolicy：候选网络策略，属于新出的策略，有ALL和LowCost两个值，暂时未知作用，如果有童鞋了解的话，可以交流下。
6. iceServers：服务端的候选地址，主要是用于客户端之间建立连接前的通信。
7. continualGatheringPolicy：收集策略时间段，有GATHER_ONCE和 GATHER_CONTINUALLY两种值，默认值为GATHER_ONCE，可以不用改。
8. keyType：加密类型，如果没有特殊需求，不建议更改。
9. 其他参数，有些属于M52之后新加的类型，还没有测试过，不敢妄下定论，还有一些属于测试后觉得不需要修改默认值的。