WebRTC的chrome调试（三）

参考地址：
https://blog.csdn.net/glw0223/article/details/91857658

总结一下主要的流程

• createOffer -> 传了一个options

• createOfferOnSuccess -> 生成了offer，也就是type:offer + sdp:xxxxxx

  • 这里面有ice-frag、ice-pwd、ice-options:trickle，但是后面不会发现新的candidate，所以也不会再发送。
  • setup:actpass://表示客户端再dtls协商过程中，可以做客户端也可以做服务器
  • 扩展：在stun里的有controlling、controlled两种角色。
  • 这个sdp里，并没有candidate。

• setLocalDescription

  • type:offer + sdp:xxxxxx

• signalingstatechange

  • have-local-offer

• setLocalDescriptionOnSuccess

• icegatheringstatechange -> 开始收集candidate

  • gathering

  • 收集上来三个udp的candidate，都是host类型的

  • 后面还会收集到三个udp的candidate，都是host类型的

  • 扩展：真正选择的candidate 其实是个peer reflexive 类型的

• setRemoteDescription

  • 收到了远端的sdp
  • type：answer + sdp:xxxxxx
  • 这个sdp是有candidate的，是一个公网的ip，并且是host类型
  • 而且也有ice-ufrag、ice-pwd、ice-options:trickle
  • 这里有setup:active->这个应该是表示dtls是由谁先发起吧？？？再确认

• signalingstatechange

  • stable

• setRemoteDescriptionOnSuccess

• iceconnectionstatechange

  • checking

• iceconnectionstatechange

  • complete -> 好像官网的文档里没有这个状态

• iceconnectionstatechange

  • connected

• iceconnectionstatechange

  • completed