随着人工智能的发展，ASR和TTS在通讯里面的应用越来越多，之前也陆续做过很多相关的项目，通讯和人工智能应用结合我们做的最多的项目就是自动外呼，关于外呼的模式和原理说明可以参考我的另一篇文章，外呼系统分类说明，自动外呼是完全无人工交互外呼模式，交换机将名单外呼，客户接通后转移给IVR，IVR负责和客户交互，IVR通过ASR和TTS实现完全无人工干预。
从目前做的项目总结一下目前这些应用的场景和效果，目前做了此类项目大概有七八个，用户大客户居多，用户所用的场景大部分都是回访、到期提醒功能、分期办理等等，对接过有科大、捷通、nuance等语音引擎，对接的协议都是MRCP V2.0，从效果来说感觉在基础业务上能够覆盖百分之80的操作，百分之20的处理不了的可以转人工，由于大客户对效果的要求还是比较高，总体效果感觉还是不错的。
总结一下自动外呼产品的优势和不足：
- 最大的优势就是可以无人工参与，减少人力成本，由于现在人力成本不断的增加，人工管理越来越复杂，减少人力成本无疑是最吸引企业的优点；
- 去年可以说是人工智能年，所以很多大型企业在应用上都靠向人工智能，所以偏向人工智能的应用还是容易得到预算；
- 因为机器是单一的，无情绪的所以在外呼效率和满意度上可以比人工外呼提高很多；
个人认为不足有以下几点
- 复杂的场景往往效果不太好，比如身份核实，信息采集，电话营销等；
- 价格昂贵，由于大厂商的ASR、TTS引擎价格往往都很贵，再加上集成费用，一套自动外呼系统的价格往往不菲
最近仔细研究了阿里、百度、科大、腾讯的云asr、tts服务，基本上公有云版的服务都不提供mrcp协议，都会http的或者是websocket的服务，识别的效果一般，但是基本上符合目前最常用的需求，尝试过和FreeSwitch做过对接，可以实现，实现的方式通过监听媒体流的方式或者到媒体流，然后转化厂商特定的协议，发送给服务端，然后获取结果，这种方式实现起来很复杂，不好维护，因为你要在一通呼叫中不停去监听和释放媒体流，而且在不改变FreeSwitch源码的基础上很难实现只获取单边媒体流，所以效果不太好；最后决定实现一个MRCP Server中间件服务，和FreeSwitch的交互跟所有MRCP V2.0的引擎一样，然后在中间件的一遍实现和所有公网接口的对接；这样原有的交互模式不再发生变化；总结一下这种方式有优势也有挑战；
优势就是：
- 由于云端的接口往往按需付费，很多可以免费试用一定次数，所以成本会降低太多；
- 云端的接口统一稳定，不需要特定的厂商支持，效率上要高很多；
挑战：
- 中间件平台的实现难度有点大；
- 必须支持公网访问，内网部署方案（不具有访问外网权限不能用）；
初步简单的架构图如下所示
初步列了下需要完成的工作
- 和FreeSwitch的MRCP交互协议实现包括，包括SIP，RTP协议的实现；
- 相关识别语法的实现，包含最常用的srgs/xml实现
- 和各种服务供应商的对接， 包含阿里、腾讯、百度、科大或者其它的ASR、TTS；
目前已经完成了第一步，实现语言java，在尝试对接阿里，基本的可行性已经验证过，这条路是可行，一步一步来，每一个大的工程都不是简单。
欢迎交流，联系方式参考边栏。