Introduction

Purpose and scope

The sub-project which main goal is to provide IVR application routing flexibility which is enough for migration from old to new MediaServers and for basic handling of GeoRedundancy configuration.

Collaborators

Business Department

• Andriy Zhylenko

Development Department

• Denys Tarasenko, Unknown User (psv), Unknown User (kote)

Testing and Support Departments

Definitions, acronyms and abbreviation

PortaSIP Media Cluster (PSMC)

The clustered media processing solution built on top of PortaSIP Cluster. I.e. it is PortaSIP cluster equipped by IVR processing logic and helper services.

PortaUM

The old Asterisk based media server which currently used as our main production solution.

References

1. https://wiki.portaone.com/x/6wBU  requirement UR6.
2. Routing of IVR applications in case of Redundant setup (TT#431863).

Overview

There are two tasks related to IVR calls routing which could not be solved by currently used BE routing mechanism.

First task is explicit distribution IVRs handling between MediaCluster and PortaUMs to provide smooth migration procedure. There are basically several main statements about it:

• We do need to allow customers to run both old and new media server n parallel to ease the migration.
• Typical user would procrastinate the migration until the moment we totally remove the old media server (and only then will discover that something does not work as expected). So we should provide the migration path where if we consider an IVR. App to be "ready" for the new media server in some MR - it is moved there by default after update; only if customer specifically turns on the configuration option to keep it on the old server - it will be processed the old way.
• It does not seem that we (and customers) really "per access number" routing to individual nodes in media cluster (except the scenario withgeo sites, which will be considered separately). Also using old PortaUM in env "A", but new media cluster in env "B" seems a bit complex and the only people who may benefit from it is a handful of companies like Telinta.

So the idea is to make the "old / new" switch per application type (we have about 25 of them) in PortaConfigurator. This will allow us to set some "default" options for new release and for a customer to override them if he wants to do so.

Second task is connected with processing IVRs only by nodes of single MeidaCluster in case of multi-site setup to avoid inter-cluster communication. It is connected with limitation of BE  which doesn't have enough knowledge to build proper routing for IVR applications as result it tries to distribute calls over all available sites.  It is unacceptable - we need to handle IVRs by nodes of the same MediaCluster where original call arrives to.

Specifications

Create "Business requirements" Create "Software requirements" Create "Design requirements"

Testing plan

Feature integration guide