VOS3000 overview & architecture

VOS3000 is a softswitch platform that many wholesale VoIP carriers use to receive calls from customers, route them to vendors and bill them. This lesson gives you a mental model of how a VOS3000 system is put together and what each part is responsible for. It is written as a general overview: exact menu names, screens and options differ between versions and installations, so always check your own system and your vendor’s documentation before changing anything.

What a softswitch does

A softswitch is the “brain” of a VoIP carrier. For every call it has to answer a few questions very quickly:

1. Who is calling? Which customer sent this call, and is it allowed?
2. Can they pay? Does the customer have enough balance or credit?
3. Where should it go? Which vendor routes are available for the dialled number, and in what order?
4. How should the number look? Do prefixes need to be added, removed or changed for the vendor?
5. What did it cost? After the call, how long was it, what is charged to the customer and what is owed to the vendor?

VOS3000 handles all of these in one platform, which is one reason it is popular with small and medium wholesale carriers.

The main building blocks

The softswitch server

The core runs on a Linux server. It contains the signalling engine that processes SIP (and, in older networks, H.323) messages, applies routing rules, and enforces limits. Depending on configuration, it can also relay media (RTP) so that audio passes through the server instead of flowing directly between customer and vendor. Relaying media helps with NAT problems and recording, but uses more bandwidth and CPU.

The database

All configuration — accounts, gateways, rates, routing — and the call detail records (CDRs) are stored in a database on the server. Because the database holds both your configuration and your billing history, it is the most important thing to back up (see Lesson 10).

The management client

Administrators usually work in a desktop management client that connects to the server. From there the NOC and billing staff create accounts, configure gateways, load rates, watch current calls and search CDRs. Different staff logins can be given different permissions, which is good practice: not everyone needs to change routing or balances.

Web portals

Many installations also offer web interfaces, for example so customers can check their balance, download CDRs or view their rates without contacting your team. If you expose a web portal to the internet, treat it as a security-sensitive system.

Key objects you will work with

Accounts

An account represents a business relationship and holds money-related settings: balance, credit limit, which rate group applies, and whether the account is prepaid or postpaid. Customers have accounts so they can be charged; vendors are often also set up as accounts so that their cost can be tracked.

Mapping gateways (customer side)

A mapping gateway describes how a customer’s traffic enters the switch: which IP addresses it comes from, how it authenticates, which account it is billed to, and any rules for rewriting numbers on the way in. When an INVITE arrives, the switch uses this information to decide which customer sent it.

Routing gateways (vendor side)

A routing gateway describes a vendor interconnect: where to send calls, which number prefixes it can carry, technical prefixes the vendor expects, capacity limits and priority. When the switch routes a call, it chooses among the routing gateways that are allowed to carry the dialled prefix.

Rate groups

A rate group is a price list: a table of destination prefixes with a price per minute and billing increments. Assign one to a customer account and the switch uses it to calculate charges. Vendor costs can be held in separate rate groups so the system can report margin.

Prefixes

Prefixes appear everywhere: in rate tables, in the list of destinations a routing gateway may carry, and in number-rewriting rules. A common source of mistakes is the difference between the destination prefix (the real country/operator code) and a technical prefix (a few digits added in front so that a partner can identify a product or route).

CDRs

Every call attempt produces a call detail record with the caller, callee, gateways used, times, duration, end reason and charges. CDRs are the basis for billing, reconciliation and most troubleshooting.

How a call flows through the system

1. An INVITE arrives from a customer’s IP address.
2. The switch matches it to a mapping gateway and therefore to an account.
3. It checks the account: is it active, does it have balance or credit, is it under its concurrent-call limit?
4. It applies any number-rewriting rules and looks up the customer’s rate for the dialled number. No rate usually means the call is rejected.
5. It finds routing gateways that can carry the prefix and orders them by the configured priority.
6. It sends the call to the first choice. If that vendor rejects the call with a suitable error, it may try the next one.
7. When the call ends, it writes a CDR and updates balances.

Lesson 4 turns this flow into practical setup steps.

Where monitoring tools fit

The softswitch knows what happened at the signalling level, but it does not judge whether a route is honest or whether audio was good. External monitoring tools — such as VoxInspector — read call data and media from the switch with very little load, and add things like ASR/ACD dashboards, FAS detection and route testing on top.

Examples in this course use invented names (Vendor X, Customer Y, Country Z) and documentation IP ranges. Menu names and options differ between softswitch versions; always check your own system and vendor documentation.