Purpose
This document contains the decisions regarding SR (Speech Recognition) and TTS (Text-to-Speech) MRCP sales combinations. These decisions are specifically applicable to on-prem installations and aim to guide the relevant teams in making accurate recommendations in projects. Since MRCP is not available on cloud-based solutions, this document solely focuses on on-prem deployments.
Summary
When IVR and MRCP are used, we will not provide any options other than Windows SR and Windows TTS.
Decisions
| Projects | Installation |
|---|---|
| SR-Only MRCP (IVR) | The customer will be directed to a Windows installation. |
| TTS-Only MRCP (IVR) | The customer will be directed to a Windows installation |
| SR+TTS MRCP (IVR) | The customer will be directed to a Windows installation |
| SR-Only (REST and/or WebSocket) TTS-Only (REST and/or WebSocket) SR+TTS (REST and/or WebSocket) |
Customer Preference: The customer will be asked whether they prefer Windows or DevOps. Both solutions are supported. Evaluation: Presales teams should assess the customer’s technical capabilities. If the customer is not familiar with DevOps, a Windows solution should be offered. Otherwise, a DevOps solution will be recommended. |
| Customer IVR-Based VA | If MRCP SR and MRCP TTS are to be used, the customer will be directed to a Windows installation. Note: VA installation will be DevOps, but SR and TTS will run on Windows. |
| SESTEK IVR-Based VA | In SESTEK IVR projects, SR and TTS will operate via REST, and the installation will be DevOps-based. |
| VA Without IVR and WebChat | SR and TTS will operate via REST, and the installation will be DevOps-based. |
| Analytics | SR will operate via REST, and the installation will be DevOps-based. |
| Real-time Guidance | SR will operate via REST, and the installation will be DevOps-based. |
When SR is embedded within different products, such as voice-enabled applications, Analytics, Real-time Guidance or other products, it can seamlessly support alternatives like WebSocket or gRPC if required by specific project needs. The current implementation serves as a baseline, but these configurations are not fixed rules. SR’s architecture is designed to be versatile, allowing us to tailor it to the unique demands of each product it interacts with.
Why MRCP Should Not Be a DevOps Installation?
- DevOps Costs: There will be management costs when using DevOps.
- OpenSIPS and Maintenance: OpenSIPS dependencies can cause future issues. Due to backward compatibility problems with security updates, we plan to discontinue maintaining OpenSIPS.
- Hardware Costs: MRCP DevOps requires more hardware resources.
OpenSIPS is used in MRCP-based solutions to route SIP traffic and manage call sessions. While MRCP handles communication between media servers and applications, OpenSIPS efficiently manages SIP messaging and session control. This setup is especially preferred for managing requests to SR and TTS servers in voice response systems like IVR.
What Will Be Different with MRCP Windows Compared to DevOps?
- Costs: Loadbalancer and Windows licensing costs will be incurred.
- Core Interface: The core interface (which hosts the Data Flow service) is not supported on Windows. However, this interface is not necessary for MRCP projects. It can be the default solution for non-MRCP projects instead.
Recognition results can already be viewed through the Recognitions page on Windows. Therefore, if I need to check the recognition results, we can continue using the traditional method. Previously,we could access the results through a page typically opened at http://localhost:10097.
Action Plan for Existing DevOps MRCP SR and/or TTS Customers
Transition Suggestions:
- For customers facing issues, a Windows platform migration can be suggested. Possible issues could include:
- Complex Maintenance: DevOps-based configurations can be complex to maintain and manage, especially for customers without extensive technical expertise. They may struggle with monitoring, updates, or troubleshooting their servers effectively.
- Compatibility Issues: SR or TTS services running on DevOps might encounter compatibility problems with the customer’s existing infrastructure, particularly during integration or when interacting with specific hardware and software components.
- Infrastructure Limitations: The customer’s infrastructure may not be sufficient to support a DevOps environment. Limitations in hardware, network configurations, or other technical constraints can lead to performance degradation.
- Operational Overhead: Running SR or TTS on a DevOps platform could result in operational overhead and increased costs. Customers might need more technical personnel, face higher resource consumption, or incur additional management tool expenses.
- Complex Maintenance: DevOps-based configurations can be complex to maintain and manage, especially for customers without extensive technical expertise. They may struggle with monitoring, updates, or troubleshooting their servers effectively.
- Customers without issues can remain with their current setup.
- Emphasize the compatibility issues in the OpenSIPS library and highlight that Windows provides a more stable solution.
- Mention that Windows requires less hardware when we compare it with DevOps hardware requirements.
Exceptions
- In case the customer insists on a DevOps solution, DevOps SR MRCP and DevOps TTS MRCP may be provided. However, communication between teams must be ensured, and the decision should be made collaboratively. For this decision, consultation with the DevOps team, Product team, and Management is essential to ensure the right approach is taken.
Communication and Notifications:
- Sales teams and PMs (Project Managers) should reach out to customers for ongoing projects.