TeleStax provides full support after the original release date of a major version of Enterprise version of Restcomm as explained in Support Policy. Telestax does not offer support for any Restcomm instances that are not licensed as part of a commercial subscription plan.
The following Service Level Agreement terms apply to on-premise support:
| Standard | Premium | Customized Support | ||
|---|---|---|---|---|
| Hours of coverage | Regular business hours | 24×7 for Severity 1 |  Contact Us | |
| Support channel | Web | Web and phone | ||
| Number of cases | Unlimited | Unlimited | ||
| Response times | Initial and ongoing response | Initial response | Ongoing response | |
| Priority 1 (Urgent) | 1 calendar day | 2 hours | 2 hours or as agreed | |
| Priority 2 (High) | 1 business day | 4 hours | 4 hours or as agreed | |
| Priority 3 (Normal) | 2 business days | 1 calendar day | 1 calendar day or as agreed | |
* In order to provide you with 24×7 coverage, Telestax requests that you identify a dedicated point of contact who will be available until the issue is resolved.
* Customer can set the priority level of a ticket when submitting via web/phone. However, Telestax reserves the right to reclassify the priority level at any time if we reasonably believe the classification is incorrect. Reclassifications are almost exclusively used in situations where a ticket is submitted as Priority 1, but the situation contradicts the Priority 1 definition – usually a non-production setup issue, or how-to question. Telestax team members may also increase the priority level if the situation is deemed to be more urgent than originally reported. If you do not choose a priority level when you create a ticket, the ticket will default to Priority 3.
A Priority 1 incident occurs when there are fatal errors or errors whose impact major functions of the use of the software. Does not include development issues or problems in staging environments
A Priority 2 incident consists of errors disabling only certain non-essential functions or impairing major functions where the software is still operational.
A Priority 3 incident is defined as a minimal impact error, all errors that are not Priority 1 or 2. Â Includes Production, Development and Staging environments.
