Registrar
SIP Registrar module handles all SIP Endpoints registrations with the Softswitch. The Registrar module supports SIP Digest authentication.
Radius AAA Client
Alpine sostswitch supports Radius based full AAA client. The AAA Client is used for interop with 3rd Party Billing Systems. The Radius client is fully compatible with AdvOSS Billing System. AAA Client supports following messages currently
-
Radius Access Request
-
Radius Accounting Request
-
Radius Route Request (Access Request)
-
Access Request
Radius Access Request is used for authenticating the subscriber and also for authorizing the subscribers for the services. The User will be authenticated /authorized when AAA client receives Access Accept response and will be rejected if the response received from the Radius Server is Access Reject.
Accounting Request
The Accounting Request is used for sending accounting records/CDRs to the Radius/Billing server. The AAA Client can send Accounting Start, Accounting-Update and Accounting-Stop Records to the Radius/Billing Server.
Radius Route Request/Access Request
The Radius Route Request is used for retrieving the route information from the external Least Cost Routing Server. The Radius Route Request is essentially a Access Request with some Vendor Specific Parameters for requesting routes. The Radius Server responds with Access Accept containing the route information.
Routing Core
- External Routing through Route Plans
- External Routing through Alpine LCR
- Local Routing Through Alpine LCR (Requires AdvOSS Billing System)
- Local Routing Through Local Routing Policy/Tables
- Alpine sostswitch Routing Core supports multiple routing techniques each required to meet specific business case. The following routing types supported by Alpine sostswitch
External Routing through Route Plans
The Service Providers might be interested in supporting custom routing to their terminators/carriers based on certain routing plans. Alpine sostswitch provides this flexibility to the Service Providers by allowing them to define their routing in particular way. The External Routing through route plans involves the sending Radius Route Request (Access Request) to the external routing server which in turn will return routes with their priorities in Access Accept. If This routing technique is configured on the Softswitch, then Softswitch sending Route Request just before routing/sending the call to the Terminator/Carrier. External Routing through Alpine LCR The External Routing through Alpine LCR works in this way.
- Subscriber calls some destination.
- The Softswitch Authorizes the Call and Now it need to send/route this call to some terminator so as to reach the caller destination.
- Since Softswitch has routing type configured to Alpine LCR, so it will take the external Alpine LCR Server (such as Alpine LCR) transport information from the configuration and will send Radius Route Request (Access Request) to the Least Cost Routing Server.
- The Alpine LCR Server responds with Access Accept containing the Routes and Their Priority.
- The Softswitch will try the route with high priority first, in case of failure the call will be routed to next route with high priority.
Local Routing Through Alpine LCR - (Dependency: AdvOSS Billing System)
The Local Routing through Alpine LCR is performed by the Least Cost Routing Function embedded in Softswitch. The Local Alpine LCR feature is dependent on AdvOSS Billing System. The Softswitch in conjunction with AdvOSS Billing System retrieves all routing information from the AdvOSS Billing System and maintains its least cost routing table for the destinations. On receiving the call for the particular destination, the Softswitch looks up its least cost routing table to find the least cost route for that particular destination.
Local Routing Through Local Routing Policy/Tables
The Alpine sostswitch in its basic routing type supports local routing table defined in its configuration. The local routing information in the configuration contains the
- Destination Prefix, The prefix of the caller destination.
- Terminator IP, the route to which the call shall be terminated
- Tech Prefix, the technical prefix of the carrier/terminator the call is being forwarded to.
- Default Route, the default route will be tried in case the call to the defined terminator IP is failed.
Request Dispatcher
One of the key differentiating features of the Alpine sostswitch is working as the request dispatcher for the external Application Servers of the Service Delivery Platforms such as AdvOSS Service Delivery Platform. The dispatching is supported through sophisticated dispatching table which is operator configurable. The dispatching table contains
- Source IP: The IP address of the entity originating the request for particular resource/service. The Source IP can be a Don’t Care Condition as well
- Dialed Digits: The dialed digits contain the target service /resource/endpoint/destination. The Dialed Digits Entry can be defined as Don’t Care as well.
- Forwarding Address(s): The Forwarding addresses are the address of the Application Server or Service Delivery Platform containing the requested resource/service/destination/endpoint. There can be more than one forwarding address separated by the semicolon.
Softswitch Database
Alpine sostswitch contains a MySQL based Database for the monitoring purpose. This database contains the following tables
- Active Sessions: This table maintains the Active Calls Sessions, the Administration and Monitoring GUI displays the Active Calls Status from this table.
- Active Registrations: This table contains the registered endpoints/users with the Softswitch
- ailed Calls: The Failed Calls Table contains the calls that were not successfully processed by Softswitch.
File based Accounting
The file based accounting module supports writing CDRs to the CDR files for offline processing. The CDR accounting files are generated in the accounting directory of the Softswitch. The CDR file are rotated (new CDR File generated) on the basis of time and the number of cdrs per file.
Administration & Monitoring GUI
The Administration and Monitoring GUI supports following functionality
- Configuration: This feature supports the configuration of Softswitch through Web Configuration Console (WCC)
- Active Sessions/Calls: The Active Calls with their details are displayed on the Web based GUI Administration & Monitoring GUI of Softswitch
- Failed Calls: Active Registration: The Administration & Monitoring GUI displays the List and Information of Registered Users.
Destination Re-Writing Rules
The Alpine sostswitch supports number Re-Writing. The Number Re-Writing is based on Re-Writing Rules defined in the Softswitch configuration. The number is re-written just before the call is routed to the carrier or terminator network.
Optional Headers Removal before Request Forwarding
Some of the Softswitch, Proxies and the Gateways don’t support some optional headers, the Alpine sostswitch supports removing those optional headers before forwarding the request to those entities.
Route Failover among multiple routes
In carrier networks sometime the wrong disconnect causes are returned by the Softswitch(s) or the gateways, hence such calls get their default treatment. But if you know that disconnect causes returned and their interpretation varies you can define the call failover policy based on your own defined Disconnect Causes & meanings.
System Failover/Redundancy
The System Failover and Redundancy is supported through Heartbeat Mechanism which works as followed
Heartbeat Mechanism/Health Monitoring Service
- This Service determines that Primary Server is Inactive and Not Responding
- It Notifies Secondary Server to takeover Primary IP through IP Switch over Mechanism.
- Softswitch Auto Recovery on Application Failure
Load Balancing
Alpine sostswitch Supports Load Balancing through frond-end dispatching mechanism where one/more instances of the Alpine sostswitch is configured as Front-End Dispatchers. These dispatchers maintain a real time instance monitoring SIP interface with the backend call processing instances to distribute the calls in intelligent way. They distribute the requests to multiple Softswitch instance based on the instance load. The dispatchers are themselves selected through DNS mechanism.
Scalability
- The Alpine sostswitch is implemented on High Performance AMPS Stack and SIP Stack, which enable it to handle thousands of calls per instance. It can handle 100 Calls per Second (CPS) and 5000 Concurrent Calls on a normal machine with 2GH CPU and 4G of RAM. The Hardware Scalability can be achieved by enhanced the CPU and RAM in the System
- The Scalability can also be achieved through Load Balancing among multiple request processing nodes. Thus operator can keep on adding the request processing Softswitch nodes
- AdvOSS Software can support Multiple Instances of Service Delivery Platform or Application Server, which helps to achieve the service level scalability through Softswitch
- Alpine sostswitch can support Multiple Instances of Radius Server
|
