TUTK海外部分双卡手机视频卡顿问题排查过程

前言

tutk是台湾的一家P2P厂商，公司产品在使用过程中，发现部分双卡手机只要开启双卡流量时，就会出现视频非常卡，偶尔只能播放一帧的现象。当关闭一张卡时，即可正常使用。当出现双卡卡顿时，连带着系统的其他应用也会卡顿，比如微信视频聊天时会出现严重卡顿，问题比较棘手。

背景

	详细说明
相关设备	三星、诺基亚部分双卡手机
问题场景	使用三星SM-G781B手机同时开启双卡流量开关
现象	1、开启双卡的开关时监视门禁主机，视频无法播放，偶尔能播放一帧，表现为网络非常差 2、只开启单卡时，视频播放顺畅

各版本现象

序号	版本号	修改内容	现象	备注
1	V2.1.1_20230213	直接使用一期云对讲aar包	双卡能使用
2	V2.1.10811_20230308	二期最新版本，修改超时间5s为3s，源码引用	双卡不能使用
3	V2.1.10813_20230308	基于2022/6/28提交，aar引用	双卡不能使用
4	V2.1.10816_20230308	2021/10/29 git最初版本	双卡不能使用
5	V2.1.10817_20230308	直接使用一期云对讲aar包	双卡能使用	GS, WiFi 不能用
6	V2.1.10909_20230309	基于2022/6/28提交，aar引用	双卡不能使用	基于intercom分支
7	V2.1.10915_20230309	基于2022/6/28提交，aar引用	双卡不能使用	基于develop分支
8	V2.1.10916_20230309	基于2022/6/28提交，aar引用，增加 IOTCAPIs.IOTC_Setup_LANConnection_Timeout(0);	双卡能使用
9	V2.1.2_20230309	基于最新的云对讲sdk代码，增加 IOTCAPIs.IOTC_Setup_LANConnection_Timeout(0);	双卡能使用

基于上述版本情况分析：

序号1、3、5、6、7 都是基于同一个提交，区别在于1和5是去年一期时编译打包的，但是只有1和5能够在双卡时正常使用。3、6、7即使是同一份代码再打包也无法在双卡时使用。于是决定对aar源码进行解析比较。

比对源码

问题分析：因同一份代码再打包也无法使用，但是两个版本的AAR确实会影响到双卡问题，决定对两个AAR包进行拆包分解源码比对，仔细比对后发现一期的版本多一行。

IOTCAPIs.IOTC_Setup_LANConnection_Timeout(0); 增加该代码时，开启双卡视频不会卡顿。

了解到这一行的作用是加上这一行就不会再走局域网模式，即使在同个路由器下。

猜想是因为tutk的穿墙打洞机制，当两张卡同时开时，数据始终在手机内部流传，导致丢失大部分数据包，导致卡顿。（联系了tutk的技术人员，他们也无法解释这一现象）

问题总结

通过版本管理工具查看提交记录，追溯到2019年版本也没有发现任何版本提交过该代码，正常情况下不应该设置该代码，当设置时就不会再走局域网模式，即使在手机与设备在同一个路由器下。该代码是碰巧在2022年底统计P2P、RLY、LAN呼通率时的临时测试代码。在测试完后，提交代码时即删除了该临时测试代码。后续功能基于GIT提交的版本继续开发。

特此记录一下问题排查的过程，如果有帮助到你，不胜荣幸。