Welcome to Streamco Softswitch!
Streamco Softswitch allows you to manage, bill and analyze VoIP traffic in real-time mode. As you may see, it's a very powerful and flexible system. Majority of its features are available only in very expensive proprietary systems.
Streamco Softswitch consists of a set of modules. Each module has its functions. Modules may interact with each other. Here they are:
Routing Module
Billing Module
Configuration Module
Resource Manager
Interface
In the next few sections you'll find information about what each module does particularly.
This is the heart of the system. No joking. It's the most complex part of the system, and it was designed to be as productive as possible to achieve maximum performance in call traffic processing.
Its job is to produce a set of routes in responce to the incoming call. Sounds simple, but this envolves lots of processing to implement all the features that were proclaimed in product's brochure.
Asterisk is tied tightly to the Routing Module via loadable module (app_switch_originator.so, app_switch_end_user.so, app_ivr.so). After a set of routes was produced, Asterisk (to be more specific, lisbssasterisk.so) starts hunting on them. What does it mean? It means that the call is first routed to the route with the highest priority. If it failes, then the call goes on to the second priority route and so on. More detailed description can be found later in this manual.
Information about all the calls, that flow through the Routing Module, in the end is passed to the Billing Module.
Its job, as it stands from its name, is to bill the calls. ALL the calls that pass through the Routing Module, are billed. The Billing Module is a very important part of code also, because it holds vital informtion about business, and every loss will be frustrating. It is designed to be as reliable to possible.
The call itself consists of 2 parts (legs): incoming(inbound or answering) and outgoing(outbound or originating). Due to the hunting we can have 1 inbound leg and 0-N outbound legs.
Legs are tied with each other in this way: inbound leg is linked with the last leg in hunting (no matter succeeded hunting or not), outbound legs link with the only inbound leg. Such linking makes possible to analyze call flow after hunting ends in statistics.
So the Billing Module bills every leg of a call and stores CDR (Call Detail Report) for each leg in database through a specially designed pipe. This pipe holds information in memory and/or in local temporary database table, in case if database server is unavailable or overloaded. So no information will be lost.
Besides of storing CDR, the Billing Module is responsible for updating balances in database. The balances are used by the Routing Module.
This module is responsible for transforming configuration from database into Asterisk core and reloading it when necessary (when configuration in database changes).
Resource Manager holds information about currently active resources. As for now, it's information about active calls. This module is feeded by the Routing Module. In turn, it provides Interface with information about active calls.
If the system suddenly crashes (it happens in this world), the Resource Manager is responsible for passing information about active at the time of crash calls to the Billing Module. So again, even in such disasterous situaton no business information is lost.
This is what operator sees. Interface is web-based. You'll see further in this manual screenshots of it.