Supported standards
gRPC
gRPC is a cross-platform open-source high performance Remote Procedure Call (RPC) framework, initially created by Google. This is the preferred and recommended protocol for communication with LumenVox software. gRPC can run in any environment and can efficiently connect services in and across data centers with support for load balancing, tracing, health checking and authentication. It is optimized for scalability and is cloud and microservices native. All major programing languages can access our API via gRPC. Supported programing languages can be located here Supported languages | gRPC.
The service proto files can be obtained from here. The client should access the relevant release version Protocol Documentation (lumenvox.com)
MRCP
Media Resource Control Protocol is a communication protocol between applications (voice IVR platforms) and the ASR and TTS resources serving them (taking in the audio or outputting the text). Primarily used by voice application platforms, call centers, call recording providers, telephony trunks, and network switches, using the W3C standards.
A subset of the standard is specific for speech recognition and voice biometrics. MRCP uses 'methods' to control speech resources: to start or stop a recognizer, set parameters, load grammars, or control a speech synthesizer (for TTS). MRCP uses web technologies to deliver information and commands.
- MRCPv1 used RTSP (real time streaming protocol) where session management and the MRCP content are sent together.
- MRCPv2 uses SIP (session initiation protocol) where a session is established first, then MRCP content is sent separately, allowing both ASR and TTS in one session.
Use of MRCPv2 is prevailing in customer service platforms. We support all major voice platforms and IVRs using MRCP. The MRPC services need to be run on their own virtual machine using Docker, as MRCP uses UDP and TCP ports which are currently not supported by Kubernetes. To support this, a media server that sits outside the Kubernetes cluster for communicating with MRCP clients is used. The client app communicates via MRCP to our media server, the MRCP API, which in turn uses gRPC to communicate with the LumenVox API.
This does limit the ability for MRCP to scale well. However, this approach allows massive connectivity: many MRCP API servers can connect to a single LumenVox Kubernetes Cluster.
The following links provide further information:
- How to connect with MRCP Version 1 and MRCP Version 2
- MRCP Connectivity – LumenVox Knowledgebase articles
Refer to Appendix 7 for MRCP API server installation steps.
If clients want to just install a simple MRCP installation to test the MRCP API, they could make use of our Simple MRCP client. More information can be obtained here: https://www.lumenvox.com/knowledgebase/index.php?/article/AA-01633/13/
MRCP services are deployment-specific and there is no option to change the deployment ID used by the service. If customers want to provide different tenants (deployments) access to MRCP, each will require their own MRCP service configured for their own deploymentId.
REST
A subset of LumenVox clients use REST APIs with HTTP or Web Sockets for their communications protocols. REST / HTTP is a traditional model for communications with backend servers. It relies on a client (web application) initiating a request, such as obtaining data from a database, and is stateless. This model doesn’t work well for applications with real time data access requirements. The REST interface is used for the Voice Biometric APIs, Voice biometric reporting APIs, and management APIs.
The REST API guide can be obtained from here. The client should access the relevant release version LumenVox API Documentation
Visit the LumenVox Knowledgebase for technical information on the supported communication protocols