FreeSWITCH中detect_speech模块的并发调用问题分析

问题背景

在FreeSWITCH语音通信系统中，detect_speech功能是实现自动语音识别(ASR)的核心组件。用户报告在使用mod_unimrcp或mod_vosk模块为通话双方同时启用语音识别时，系统会在运行一段时间后异常播放等待音乐(MOH)，同时语音识别功能失效。

问题现象

通过分析日志发现，问题发生时存在以下关键现象：

1. 通话双方几乎在同一毫秒内同时调用了detect_speech功能
2. 5秒后系统开始播放等待音乐
3. 该问题在FreeSWITCH 1.10.8和最新版本中均存在
4. 影响mod_unimrcp和mod_vosk两个模块

技术分析

并发调用机制

FreeSWITCH的媒体处理采用单线程事件驱动模型。当两个通道同时发起detect_speech请求时，系统会尝试为每个通道创建独立的语音识别会话。从日志可见，两个识别会话(ASR-35和ASR-36)几乎同时建立，包括：

1. 创建媒体队列
2. 建立MRCP控制通道
3. 添加媒体终端
4. 发送SDP offer/answer协商
5. 加载语音识别语法

资源竞争问题

深入分析日志发现，当两个识别会话同时运行时，系统资源出现竞争：

1. 音频流处理冲突：两个会话尝试同时处理相同的音频流
2. 编解码器切换异常：日志显示系统在5秒后强制将编解码器切换为PCMA:8
3. 媒体流重定向：系统异常触发了local_stream://moh的播放

根本原因

问题的根本原因在于未正确区分主被叫通道(aleg和bleg)的媒体流处理。在FreeSWITCH中，当需要对通话双方同时进行语音识别时，必须明确指定通道角色，否则系统无法正确处理双向媒体流。

解决方案

正确使用uuid_broadcast

通过添加aleg参数明确指定通道角色，可以解决此问题。正确做法是在调用uuid_broadcast时：

<action application="uuid_broadcast" data="aleg detect_speech vosk default default"/>
<action application="uuid_broadcast" data="bleg detect_speech vosk default default"/>

参数优化建议

1. 设置合理的超时参数：

detect_speech(vosk {start-input-timers=true,no-input-timeout=30000,recognition-timeout=30000} default)

2. 为不同通道使用不同的语法文件
3. 考虑使用串行识别策略而非并行识别

最佳实践

1. 通道隔离：始终明确区分aleg和bleg通道
2. 资源管理：在高并发场景下限制同时进行的语音识别会话数
3. 监控机制：实现会话状态监控，异常时自动恢复
4. 日志分析：定期检查系统日志，识别潜在资源冲突

总结

FreeSWITCH的语音识别功能强大但需要正确配置。并发调用detect_speech时，必须注意通道角色区分和资源管理。通过明确指定aleg/bleg参数和优化识别参数，可以避免媒体流冲突，确保语音识别功能稳定运行。

对于需要高并发的语音识别场景，建议考虑使用专业的ASR服务器集群，并通过负载均衡分配识别请求，以获得更好的性能和稳定性。