跨网络边界通过做端口反向代理调通WebRTC音视频通话功能案例


"构成我们学习最大障碍的是已知的东西,不是未知的东西" ------现代医学奠基人贝尔纳


WebRTC 交互的流程大致如下:

呱牛笔记

图片来源网络:https://www.jianshu.com/p/a7e7cb4d6d64

1、进入房间;

2、获取媒体,交换SDP;

3、通过turnserver获取本机候选地址,交换candidate;

4、ICE进行候选地址进行连接,连通了,则可以进行音视频通话;


这次项目实施的环境是一个网络等级相对要求高的网络,客户要求Android手机在安全网络外头,PC客户端运行在安全网络里头,大概的拓扑结构图如下:

                        代理前置机         代理后置机      WebRTC服务器                     TURN服务器 

客户端(192段)   192.168.1.40     20.80.4.131       20.80.4.133 (8099)                20.80.4.133 (3478)

52652                 3478                 52652                                                                 3478

                           30008                                        30008   

Android手机通过VPN接入到代理前置机网络,访问安全网络20.80.4.*的服务器,需要通过代理前置开反向代理才能进入,并且代理设备之间还有隔离交换设备;

首先在代理前置机上开了WebRTC服务器8099和Turnserver 3478 的代理端口

20.80.4.133/8099 -   192.168.1.40/8099  tcp

20.80.4.133/3478 -   192.168.1.40/3478  udp

20.80.4.133/30008-30208 -   192.168.1.40/30008-30208   udp  端口池


Android客户端配置的服务器地址信息统一调整为代理的ip和端口,信令很顺利的就调通了,媒体预知肯定是不通,需要修改几个地方:

1、Android端candidate收集的本机地址中,在开启stun配置后,能获取到20.80.4.133的ip和端口,并将candidate发送给服务器;

 "candidate": {

      "candidate": "0:0:candidate:4020260996 1 udp 2122260223 10.172.25.131 52652 typ host generation 0 ufrag 7CB0 network-id 3 network-cost 50: ",

      "sdpMid": "0",

      "sdpMLineIndex": 0

   }


2、Android端收到服务器的candidate地址信息,需要将20.80.4.133地址修改为代理前置机的地址,这是因为所有20.80.4.133其实已经被代理前置机代理了,但服务器是没法感知;

经过上面的修改,以为ICE就能通了,其实还是不通,通过抓包分析,原来问题出在STUN打的洞上,客户端可以通过代理机的端口发送数据包到服务器,但服务器通过客户端的candidate地址和端口发送ice请求包,却出现icmp不可达的错误!原来,这个环境的代理机制是我们极少碰到的对称型NAT!我们说对于对称型NAT,是无法通过预先打洞的端口进行数据互通的。这种网络设备,对每个外部主机或端口的会话都会映射为不同的端口(洞)。只有来自相同的内部地址(IP:PORT)并且发送到相同外部地址(X:x)的请求,在NAT上才映射为相同的外网端口,即相同的映射。


打洞机制失效,怎么破?


修改思路:

1、所有数据包都经过TURN服务器转发?这个思路可行,但在这种网络条件下,如何实施貌似有些问题不明白,比方turnserver开的转发端口就需要对外做代理,服务器可能也需要开启turnserver,暂时放弃这个思路;


2、这种网络环境下,去掉STUN服务器,不需要stun做地址探测了,应用对网络环境是清晰的,并且需要去掉ICE的候选地址配对的相关流程,主要是ICE地址配置过程中也是STUN协议交互的过程:

客户端将本机的candidate发送给服务器时,服务器的地址配置信息为:

[20.80.4.133]:30008 --> [20.80.4.131]:52652


但经过了客户端和服务器的stun试探性连接后,服务器发现,客户端给服务器返回的公网地址是:192.168.1.40:30008,

出现了新的配对:

 [192.168.1.40]:30008 --> [20.80.4.131]:52652 

并且服务器给出了配对失败的错误,其实互联的Socket都是正常的话,ice的交互显得有些多此一举了,所以果断修改libnice的ice交互流程,去掉了ICE的地址配对完成后服务器的地址匹配判断逻辑,libnice的ice服务器这么修改:忽略客户端返回的stun response 中的服务器的公网地址; 

static CandidateCheckPair *priv_process_response_check_for_reflexive(NiceAgent *agent, NiceStream *stream, NiceComponent *component, CandidateCheckPair *p, NiceSocket *sockptr, struct sockaddr *mapped_sockaddr, NiceCandidate *local_candidate, NiceCandidate *remote_candidate)
{
  CandidateCheckPair *new_pair = NULL;
  NiceAddress mapped;
  GSList *i, *j;
  NiceCandidate *local_cand = NULL;
 
  nice_address_set_from_sockaddr (&mapped, mapped_sockaddr);
  for (j = component->local_candidates; j; j = j->next) {
    NiceCandidate *cand = j->data;
    //忽略客户端返回的服务器地址,直接返回成功
    //if (nice_address_equal (&mapped, &cand->addr)) {
      local_cand = cand;
 
      /* We always need to select the peer-reflexive Candidate Pair in the case
       * of a TCP-ACTIVE local candidate, so we find it even if an incoming
       * check matched an existing pair because it could be the original
       * ACTIVE-PASSIVE candidate pair which was retriggered */
      for (i = stream->conncheck_list; i; i = i->next) {
        CandidateCheckPair *pair = i->data;
        if (pair->local == cand && remote_candidate == pair->remote) {
          new_pair = pair;
          break;
        }
      }
      break;
    //}
  }
 
}

经过上面的修改,webrtc的音视频通话功能正常!

本文为呱牛笔记原创文章,转载无需和我联系,但请注明来自呱牛笔记 ,it3q.com

请先登录后发表评论
  • 最新评论
  • 总共1条评论

:额,这不是2.5类网跟二类网么...

2021-03-04 14:28:34 回复