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.
 
|   | Measuring call setup time 
 | 
