mod_unimrcp从FreeSWITCH代码树中删除

这其实是一个“蓄谋”已久的操作，不要着急，听我慢慢讲。

MRCP的全称是Media Resource Control Protocol，即媒体控制协议。现在广泛用在语音合成、语音识别等领域，大多数做人工智能（语音）的厂商现在也都支持该协议。UniMRCP是一个开源的实现。FreeSWITCH中有一个mod_unimrcp模块就是使用了这个库和开源的协议。

为什么移除呢？简单回答，就是为了更好。

那为什么说“蓄谋”已久呢？因为被一些事情耽搁了。

UniMRCP底层使用了APR（Apache Portabl Runtime）库，而FreeSWITCH底层也使用了APR库，所以，在FreeSWITCH中，他们共用同一个版本的APR。这很好。但是，随着时代的发展，当人们想升级UniMRCP时，发现问题了，那就是，FreeSWITCH用的APR库比较旧，而新版UniMRCP需要的库又比较新，升级不了了……

为什么FreeSWITCH不更新APR库吗？这就说来话长了。简单来说，那就是——升不了。

FreeSWITCH对APR库有一些改动。而这些改动并没有合并到上游的APR里。

为什么不能合并呢？说好的开源软件呢？不是说程序员一言不合就提交补丁吗？FreeSWITCH难道不能把自己修改的部分提交到上游的APR仓库里吗？

提交补丁很简单，但合并补丁还真不是那么简单。FreeSWITCH确实向APR提过补丁，但都是石沉大海。感兴趣的可以自行搜索一下，也可以参考以下这些链接。

所以，后来，FreeSWITCH就一直用旧版本的APR。因而导致UniMRCP也无法升级。

不过，时隔多年，FreeSWITCH团队终于解决了这个问题。解决方式也简单粗暴。把FreeSWITCH自己用的APR改成fspr。这样，就可以把mod_unimrcp移出FreeSWITCH代码树，放到独立的仓库中。新的模块也转由社区维护，想咋升咋升。

什么？那mod_unimrcp是不是转为二等公民了？是，也不是。

首先，你可以自行编译，单独编译一个模块比放在FreeSWITCH里简单多了，比如：

$ git clone https://github.com/freeswitch/mod_unimrcp.git
$ cd mod_unimrcp
$ export PKG_CONFIG_PATH=/usr/local/freeswitch/lib/pkgconfig:/usr/local/unimrcp/lib/pkgconfig
$ ./bootstrap.sh
$ ./configure
$ make
$ sudo make install

详情可参见该模块的README。

其实，FreeSWITCH早就发明了一套机制，在FreeSWITCH主代码树的modules.conf中引用一个外部模块，编译还是像以前那样make install，没有任何不和谐。比如：

之前：

asr_tts/mod_unimrcp

现在：

mod_unimrcp|https://github.com/freeswitch/mod_unimrcp -b master

你甚至可以把你自己写的模块也放一条记录到modules.conf中去，只要你写得足够好，大家都愿意用，甚至也可以变成FreeSWITCH缺省的安装模块。

这是今年FreeSWITCH最大的改变，希望未来会越来越好。

话说FreeSWITCH把mod_unimrcp模块移出还有另外一个原因，或者说释放一个信号，那就是——MRCP这个协议好是好，但毕竟是上古时代的协议，在当今的互联网环境下部署比较复杂，NAT穿透都很难解决，而私有化部署的AI服务又往往比较贵。AI厂商大部分都提供自己的基于私有协议的ASR/TTS产品，又不受MRCP协议的限制。我们在XSwitch的做法是为每个云厂商的每个ASR/TTS服务都写了一个模块，后面我们还会发文专门讲。