简介：本文深入解析高通平台语音通话（Voice Call）的技术实现流程，剖析常见问题根源，提供从底层协议到应用层的全链路调试方案，助力开发者优化通话质量。

一、语音通话技术架构与核心组件

高通平台语音通话功能基于QMI（Qualcomm Modem Interface）协议栈实现，其技术架构可分为三层：硬件层（基带芯片+射频模块）、协议层（3GPP标准协议栈）和框架层（Android Telephony框架）。核心组件包括：

Modem子系统：负责物理层信号处理，包括编码/解码（AMR-NB/WB、EVS等）、信道编码、时序同步等。以EVS编码器为例，其支持24.4kbps超宽带语音，通过CELP+MDCT混合编码技术显著提升音质。

RIL（Radio Interface Layer）：作为Modem与Android框架的桥梁，实现AT命令封装与状态回调。典型调用流程为：

// RIL请求示例（发起语音呼叫）
public void dial(String number, String uusInfo, Message response) {
 RILRequest rr = RILRequest.obtain(RIL_REQUEST_DIAL, response);
 rr.mParcel.writeString(number);
 rr.mParcel.writeString(uusInfo);
 send(rr);
}

TeleService框架：处理呼叫状态管理（如CS_CALL、IMS_CALL）、补充业务（呼叫转移、三方通话）等逻辑。关键类包括Call.java、InCallService.java等。

二、语音通话全流程解析

2.1 电路交换（CS）语音流程

主叫流程：
- 应用层触发：TelecomManager.placeCall()
- 框架层处理：生成OUTGOING状态Call对象
- RIL层交互：发送RIL_REQUEST_DIAL命令
- Modem响应：返回CALL_STATE_DIALING状态
- 网络侧交互：完成信道建立（TCH分配）、鉴权加密
- 通话建立：Modem上报CALL_STATE_ACTIVE
被叫流程：
- 网络寻呼：通过SACCH信道下发PAGING_REQUEST
- Modem中断：触发RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED
- 框架层处理：生成INCOMING状态Call对象
- 用户响应：通过InCallService显示来电界面

2.2 IMS语音流程（VoLTE/VoNR）

IMS流程在CS基础上增加SIP信令交互：

注册阶段：通过REGISTER消息完成P-CSCF发现、鉴权
会话建立：
- 主叫发送INVITE（SDP包含媒体能力）
- 被叫返回183 Session Progress（预协商媒体）
- 双方通过PRACK/200 OK完成信令确认
专有承载建立：QCI=1的GBR承载用于语音数据传输

三、典型问题分析与解决方案

3.1 单通/断续问题

现象：通话中一方听不到对方声音，或声音断续。
排查步骤：

底层信号检查：
- 通过AT+CSQ查询RSRP/RSRQ值（建议RSRP>-110dBm）
- 检查/proc/modem_log中的L1层误码率（BLER<2%）
编码器适配问题：
- 确认双方支持相同编码格式（如均支持EVS-WB）
- 检查persist.vendor.radio.voice.codec参数配置
上行链路异常：
- 使用tinycap工具抓取麦克风原始数据：
```
tinycap /data/mic.wav -D 0 -c 1 -r 16000 -b 16
```
- 分析波形是否出现削波（峰值超过-3dB）

解决方案：

调整ro.qc.sdk.audio.fluency.mode参数优化回声消除
更新基带版本修复已知编码器Bug

3.2 呼叫建立失败

现象：拨号后长时间无响应，或直接提示”呼叫失败”。
排查步骤：

信令跟踪：
- 使用QCAT工具抓取Modem日志，分析RIL_REQUEST_DIAL后的响应
- 典型失败原因：
  - 3GPP规范错误（如CM_SIM_REJECT）
  - 资源不足（RIL_E_MODEM_ERR）
  - 网络拒绝（CAUSE_CODE=34）
配置检查：
- 确认persist.vendor.radio.call_default.network设置正确
- 检查/vendor/etc/cne/SwimConfig.xml中的PLMN优先级

解决方案：

重置网络设置：adb shell cmd telecom reset-network
更新NV配置项：AT%NVWRITE=XX,YY（需高通授权）

3.3 回声与噪声问题

原因分析：

声学设计缺陷：听筒与麦克风距离过近（<3cm）
算法参数不当：AEC（声学回声消除）收敛速度慢
硬件故障：麦克风偏置电压异常

优化方案：

软件调优：

调整audio_platform_configuration.xml中的AEC参数：

<param key="aec_mode" value="2"/> <!-- 2=自适应模式 -->
<param key="aec_tail_length" value="128"/> <!-- 尾长128ms -->

硬件改进：
- 在麦克风与Speaker之间增加声学海绵
- 确保PCB布局符合高通推荐（麦克风远离电源模块）

四、调试工具与方法论

4.1 必备调试工具

QXDM：高通专属协议分析工具，支持：
- 实时解码3GPP信令（如RRC、NAS消息）
- 统计呼叫建立时延（T1-T7各阶段耗时）
- 捕获QMI消息流

Logcat过滤技巧：

adb logcat -s TelephonyFramework:V RILJ:V QMI:V *:S

音频质量评估：
- 使用PESQ算法评估语音质量（需离线处理）
- 高通Audio Quality Test Suite（AQTS）自动化测试

4.2 系统化问题定位流程

复现问题：确定触发条件（如特定网络/对方号码）
分层排查：
- 应用层：检查Call.getState()返回值
- 框架层：跟踪TelephonyConnection状态机
- Modem层：分析QMI错误码（如QMI_RESULT_FAILURE）
根因分析：
- 信号问题→优化天线设计
- 协议问题→升级基带版本
- 配置问题→修改NV项

五、性能优化最佳实践

快速呼叫建立优化：
- 预加载SIM卡信息：persist.vendor.radio.sim_powerdown_mode=0
- 启用快速休眠：persist.vendor.radio.fast_dormancy=1
功耗优化：
- 动态调整DRX周期：persist.vendor.radio.drx_mode=2
- 限制后台呼叫：config_disable_non_cs_call
兼容性处理：
- 针对不同运营商定制apn_conf.xml
- 实现CarrierConfigManager覆盖默认参数

通过系统化的流程分析和工具应用，开发者可显著提升高通平台语音通话的稳定性和用户体验。建议建立持续集成测试（CI），在每次基带更新后自动执行呼叫流程验证，确保质量可控。

高通开发系列 - Voice Call之语音通话流程和问题分析