FreeSWITCH中文网,电话机器人开发网 ,微信订阅号：
FreeSWITCH及VOIP,Openser,电话机器人等产品中文技术资讯、交流、沟通、培训、咨询、服务一体化网络。QQ群：293697898
FreeSWITCH及VOIP,Openser,电话机器人等产品中文技术资讯、交流、沟通、培训、咨询、服务一体化网络。QQ群：293697898
我们在前文《大模型中的小模型实现电话智能客服(视频讲解）》中，讲述了当前我们使用大模型来深化业务、收敛边界、更多智能、更强智慧地在语音业务中使用大模型，当然音视频自始一直是虽分家，但是又不得不在一起的状态，所以遇到运算量大、响应处理复杂的一些场景，就需要进一步改进音视频的对接方式。 MRCP在其中可能是一个方式，但是MRCP它的出发点一直是针对于音频资源的管理和控制。当然有些场景使用它也是适用的，但是在越来越多的ASR/TTS的实现上，MRCP反而是一个很大的问题。
就好比我们在多年前《视频电话语音交互、按键交互》中所看到的，需要对音视频流都进行处理，甚至于要抓图、截视频流等，那么就力所不及了。 当然还有个重要的原因，再怎么使用、摸索，面对体量巨大的代码们，我们还是有很多地方做不到，协议、实现、功能、多进程多线程间的完全协调，所以我们当前开发了这个版本na_stream，主要用于面向实时通话、大模型对话、人机耦合对话等更协调。
我们会在开始工作时，向tcp server发送一个消息请求： / * 发送开始工作消息。 * * @param sock Socket 描述符 * @param uuid 会话 UUID * @param mode 模式 * @param caller 呼叫者 * @param callee 被叫者 * @return 成功返回 0，失败返回 -1 /int send_start_message(int sock, const char uuid, const char mode, const char caller, const char callee,switch_core_session_t session,stream_thread_data_t *data){ ... snprintf(message, sizeof(message), "UUID=%s&start&MODE=%s&CALLER=%s&CALLEE=%s", uuid, mode, caller, callee); ... }
其中如果是sendrecv模式，我们会启动多个线程，发实时语音流、收实时语音流（包括不限于tts实时流、录音录像文件等）、流程控制、消息通知、ACK确认等等。
通过以上方式，我们可以协助大模型（语义大模型、语音识别大模型、语音合成大模型）等传输语音流，进行正确有效的音视频沟通能力。 当然以上的方式只是一种我认为脱离了原有思维方式的开拓，至于最终实际进行通话，那么需要更多的辅助能力来实现。