Below is an overview of how we test Rhino performance with IN, followed by links to the benchmarks.
About the IN test scenario
To test the IN performance of Rhino {space-metadata-from:rhino-internal-version}, we use a Virtual Private Network (VPN) application, which:
-
provides number-translation and call-barring services for groups of subscribers
-
uses CAPv3 and INAP CS1 protocols for call-control, and MAPv3 for location information
-
uses OpenCloud’s CGIN APIs and resource adaptor to provide CAP and MAP support.
OpenCloud developed this VPN application to meet genuine business requirements from a Tier-1 network operator, giving us genuine benchmarks — instead of, for example, using a trivial demo application.
This test application performs functions that are common to many real-world IN applications:
-
monitoring the entire call, and reliably maintaining state for the duration of the call
-
interacting with external systems (MSC, HLR, call detail records)
-
supporting a large subscriber database.
The VPN Application
The VPN application provides number-translation and call-barring services for groups of subscribers. It uses CAPv3 for call-control and MAPv3 for location information.
If the A party… | then VPN responds with: |
---|---|
…has called a B party in their own VPN using short code or public number |
|
…and B party are not in the same VPN |
|
…dials a short code that doesn’t exist |
|
Call flow
The VPN application applies incoming call-screening and outgoing call-screening rules, some of which require location information and involve a MAP query of the HLR.
![vpn callflow](../images/in-benchmarks/vpn-callflow.png)
![]() |
Measuring call setup time
|