Overview
This guide provides information regarding UniMRCP interoperability. UniMRCP has been developed in accordance with the MRCP specifications. Therefore, UniMRCP client and server should inter-operate with all MRCPv1 and MRCPv2 compliant implementations.
Below is the list of MRCP vendors/products UniMRCP client and server are known to work with. The interoperability has been tested internally either on UniMRCP or vendor side.
UniMRCP Server
| Vendor | MRCPv1 | MRCPv2 |
| Voxpilot | Completed | N/A |
| Aculab | Completed | N/A |
| Holly-Connects | Completed | N/A |
UniMRCP Client (TTS)
UniMRCP Client (ASR)
If you used UniMRCP client or server with MRCP vendors/products not mentioned above, please leave a comment below by providing the following information
- Vendor:
- Protocol: MRCPv1 and/or MRCPv2
- Resource: ASR and/or TTS
If you experienced interoperability issues, please submit them to the
issue tracker.
For nuance we had one or two issues. We had to set the contentid in the MRCP header to testrecog@speechworks.com or something like xxxx@speechworks.com, also we had to modify the mrcpv1 and v2 params in the nuance configuration file.
GVP rejects RTSP response to DESCRIBE RTSP request on speechrecognizer resource. The problem is in the Transport header of the response, GVP says client_port does not match. (How could we know client port without Transport header or SDP in request?) Excluding Transport header from the response solves the issue. So generally, is it necessary to include transport header in the response for RTSP DESCRIBE? I think it is a bug of GVP, that is why I have not put it on issue tracker. It can be easily patched by commenting out lines 540--543 in mrcp_unirtsp_sdp.c (r1086).
Remarks:
Acapela TTS for Linux and Windows Server have 2 Server add-on implementing MRCP.
More info