webrtc 从连接上房间服务器到p2p音视频通话的流程梳理(二)

在第一篇文章中,我们分析了sdp信息的交互.

https://blog.csdn.net/zhangkai19890929/article/details/82831885

在完成的sdp信息之后,接下来就是IceCandidate的信息传递。

IceCandidate就是自己的本地ip,公网ip,以及端口.

clientA先进入到房间的同时同时会被要求发送本机的icecandidata到sturn server,此接口会被调用多次.

  //发送本机的IceCandidate到signal server
  @Override
  public void onIceCandidate(final IceCandidate candidate) {
    runOnUiThread(new Runnable() {
      @Override
      public void run() {
        if (appRtcClient != null) {
          appRtcClient.sendLocalIceCandidate(candidate);
        }
      }
    });
  }

那么我们看看多次调用的数据情况:

第一次:

sdp = candidate:2407256073 1 udp 2122260223 10.220.28.74 43526 typ host generation 0 ufrag htw0 network-id 3 network-cost 10

10.220.28.74 是本机的ip地址,通过adb shell && ifconfig可以轻松的获得.

第二次:
sdp = candidate:559267639 1 udp 2122202367 ::1 54869 typ host generation 0 ufrag htw0 network-id 2

第三次:
sdp = candidate:1510613869 1 udp 2122129151 127.0.0.1 40788 typ host generation 0 ufrag htw0 network-id 1

127.0.0.1很熟悉了,本机的回环地址.
第四次:
candidate:2032080525 1 udp 41885439 172.17.0.2 63433 typ relay raddr 10.220.28.74 rport 43526 generation 0 ufrag htw0 network-id 3 network-cost 10

172.17.0.2是个什么玩意,本地的局域网:

webrtc 从连接上房间服务器到p2p音视频通话的流程梳理(二)_第1张图片

第五次:
sdp=candidate:2407256073 1 udp 2122194687 10.220.28.74 43073 typ host generation 0 ufrag htw0 network-id 4 network-cost 900

通过sturn server获取了5次ice的信息,然后在通过 sigserver 服务器(也就是我们第一篇说的房间服务器)转发出去.

当clientB进来后,clientB会首先获得clientA的icedidate,同时也会收到onIceCandidate的回掉,把自己的ip信息封装好发送出去.

  @Override
  public void onRemoteIceCandidate(final IceCandidate candidate) {
    runOnUiThread(new Runnable() {
      @Override
      public void run() {
        if (peerConnectionClient == null) {
          Log.e(TAG, "Received ICE candidate for a non-initialized peer connection.");
          return;
        }
        peerConnectionClient.addRemoteIceCandidate(candidate);
      }
    });
  }

但是这里有个很大的疑问:

就是通过断点我发现,当函数调用这里的时候,其实clientA和clientB已经开始进行视频的传输交互了.

那么到底什么时候建立的p2p呢? 类结果的依赖关系又是怎么样的呢?

你可能感兴趣的:(webrtc代码研究)