MRCP vs. API, Part 1
The Media Resource Control Protocol is an agreed upon standard to allow interoperability
between multiple media resources. It allows diverse elements such as speech engines, text to
speech engines, fax resources, platforms, and PBX systems to talk using an agreed upon
standard method of communication.
There are two versions of MRCP, version 1 and version 2:
- Version 1 uses the real-time streaming protocol (RTSP) to control packets of data
transferred between applications.
- Version 2 uses the session initiated protocol (SIP), which is the same method used
with many voice over IP (VOIP) applications.
MRCP is a standard allowing various applications can share for communication.
- An application programming interface is a vendor and application specific method of
communication with a resource. It's a generic term which means that the creator of a
resource, such as a speech engine with LumenVox, makes available a variety of functions
you can use in your program to write a direct integration from your application into ours.
- This would hook your application into ours using these functions which we publish.
LumenVox has both a C and C++ API for the speech engine. This is part of our Software
Development Kit and you will receive documentation and access to various libraries to
include our functions in your applications.
- The major benefit for MRCP is that you have one interface for multiple components.
If your platform works with one speech engine, you should be able to just plug in the
LumenVox Speech Engine. This is the point of having a standard, a new interface is not
needed when using a new resource.
- Also, MRCP is network based, it uses a standard method of talking across network
connections. So both the application and resource can be on the same machine or on
different machines, which makes MRCP a more abstract method of communicating between
applications than a direct API integration.
- Another benefit is if your client application runs on embedded hardware or is an
embedded application, some type of really small hardware that LumenVox doesn't support.
If you are going to do a direct API integration you would have to have LumenVox's client
and libraries installed on the same machine as you application because a API level
integration would require that it would be on the same machine it is not abstract so
that it be able to communicate over a network. MRCP is abstract so an embedded system,
in which an application is being run on the embedded system then that application could
simply talk with the speech engine or other resources by way of a network connection
- The API integration method also offers a number of advantages as well. One of which
is that you will have more functions available. With a standard like MRCP, you can only
use a subset of the of the total number of functions available in the application.
Every vendor had some features that other vendors do not have, and these functions can't
exist in the MRCP standard. Because this is a standard, everyone who supports MRCP has
to support the standard features agreed upon. So if we have some features in our Speech
Engine that are not found in a different speech engine, our additional features will not
appear as the MRCP standard. So with an API integration you receive all of the features
we have. Note: MRCP does allow for some vendor specific type of tags, however if you
start adding more and more vendor specific functionality it will defeat the purpose of
having a standard.
- Another advantage to an API is that it's very flexible. If a customer requests a new
feature and the vendor determines that it makes sense, it can be added to the engine and
then an API function can be added so that the customer can use it. This can be done
relatively quickly. If the same function was requested using MRCP, we could not simply
call up the governing standards body and ask for a new feature because our customer has
requested it. The API allows us to be much more flexible in making additions and changes
per customer requests.
- Generally an API has greater backwards compatibility then MRCP. So if you originally
wrote an application for an older version of our Engine, then upgrade your Engine without
changing your application, the application will still work. Even if your using older
functions, or using functions in an older way. LumenVox goes out of our way to make sure
we don't break your stuff when we make upgrades. This not the case with standards. MRCP
version 1 and MRCP version 2 are not exactly compatible, the control protocol has been
changed. Standards governing bodies are not very interested in backwards compatibility
generally. They are interested in standard methods and are OK with throwing out old things
which can create a bit of a problem. With our API, you have LumenVox's assurance that we
will do every thing we can to not break your applications just because you've upgraded to
the latest version of our engine.