This document outlines the configuration best practices for the Ribbon QSBC when deployed with Ribbon PSX (Redirector) and Ribbon Protect for Value-Based Routing (VBR) and Standard Routing.
Ribbon QSBC is a network element deployed to protect SIP-based Voice over Internet Protocol (VoIP) networks. Early deployments of SBCs were focused on the borders between two service provider networks in a peering environment. This role has now expanded to include significant deployments between a service provider's access network and a backbone network to provide service to residential and enterprise customers.
Ribbon Protect provides a single view of the end-to-end network, critical for UC threat detection, fraud management, and network operations.
Ribbon PSX Ribbon's centralized policy and routing solution (PSX) provides a way to manage the security, complexity, and cost of routing calls across any operator's network.
Ribbon QSBC CDR data is processed by Ribbon Protect and generates QOS KPI values. Ribbon PSX uses the QOS KPI values to dynamically route the call to the route which has the best quality and is least expensive. PSX updates QOS KPI values for each trunk group (TG) configured in the PSX table.
TG is identified in PSX with the associated Q21 server name mentioned.
If a TG is not configured in PSX or the name of the TG in PSX does not match Q21 CDR, QOS KPI values for that TG cannot be updated in PSX DB.
If QSBC does not use LCR based routing, there are two options:
This guide contains the following sections:
Section B: PSX Redirector Configuration
Captures the PSX Redirector configuration required for QSBC routing
Captures the PSX to Ribbon Protect interconnection related configuration
For additional information on the Ribbon QSBC, PSX, and Ribbon Protect refer to https://ribboncommunications.com/.
It is not the goal of this guide to provide detailed configurations that will meet the requirements of every customer. Use this guide as a starting point and build the QSBC, PSX, Protect product's configurations in consultation with network design and deployment engineers.
This is a technical document intended for telecommunications engineers with the purpose of configuring Ribbon QSBCs, PSXs and Protect. Steps will require navigating the product guide as well as the operations guide. Understanding the basic concepts of TCP/UDP, IP/Routing, and SIP/RTP is needed to complete the configuration and any necessary troubleshooting.
This configuration guide is offered as a convenience to Ribbon customers. The specifications and information regarding the product in this guide are subject to change without notice. All statements, information, and recommendations in this guide are believed to be accurate but are presented without warranty of any kind, express or implied, and are provided “AS IS”. Users must take full responsibility for the application of the specifications and information in this guide.
The sample configuration in this document uses the following equipment and software:
The following diagram shows the deployment topology.
The following diagram shows connectivity between QSBC, PSX and Ribbon Protect.
In the sample flow, QSBC1 needs to route the calls further based on QOS/LCR values collected by Ribbon Protect and used by PSX Redirector.
Media is bi-directional in the following diagram but is not shown explicitly. Media doesn't flow through PSX Redirector and Ribbon Protect.
Here, the Q21 configuration is given for QSBC1, but it can be used for QSBC2 or QSBC3 if there is a requirement similar to QSBC1.
Ribbon Protect pulls CDR data from QSBC2 and QSBC3 for QOS KPI analysis and then PSX pulls this data and updates its DB.
This section may be modified based on customer specific requirements
A signaling VNET (virtual network) is the combination of a physical interface, a gateway IP address (router), and an optional VLAN (virtual local area network) ID.
cli vnet add v1 cli vnet edit v1 gateway 10.34.92.1 ifname eth2 cli vnet add v2 cli vnet edit v2 gateway 10.34.94.1 ifname eth3
Configure the QSBC Media separately.
Realm is a logical service entry point for other devices to connect to the SBC. (A realm on the SBC is not synonymous with a SIP realm.)
For calls to connect successfully, you must have at least one realm configured on your system.
These refer to SIP Signaling IPs of QSBC towards various peers including SIP suppliers and SWe for Telstra.
cli realm add SYDPQ21LABVFNZREALM cli realm edit SYDPQ21LABVFNZREALM vnet v1 rsa 10.34.92.166 mask 255.255.254.0 emr alwayson imr alwayson medpool 1 cli realm add GVPSYDPQFLEXLAN394REALM cli realm edit GVPSYDPQFLEXLAN394REALM vnet v1 rsa 10.34.92.167 mask 255.255.254.0 emr alwayson imr alwayson medpool 1 cli realm add GVPLABPMPLSGVOIPCUSTREALM cli realm edit GVPLABPMPLSGVOIPCUSTREALM vnet v1 rsa 10.34.92.168 mask 255.255.254.0 emr alwayson imr alwayson medpool 1 cli realm add LABGIA210REALM cli realm edit LABGIA210REALM vnet v1 rsa 10.34.92.169 mask 255.255.254.0 emr alwayson imr alwayson medpool 1 cli realm add TCISYDLSWELABREALM cli realm edit TCISYDLSWELABREALM vnet v2 rsa 10.34.94.166 mask 255.255.254.0 emr alwayson imr alwayson medpool 2 cli realm add GVPLABPMPLSGVOIPCUSTREALM2 cli realm edit GVPLABPMPLSGVOIPCUSTREALM2 vnet v2 rsa 10.34.94.167 mask 255.255.254.0 emr alwayson imr alwayson medpool 2 cli realm add PSX cli realm edit PSX vnet v2 rsa 10.34.94.168 mask 255.255.254.0 emr alwayson imr alwayson medpool 2
PSX EndPoints (EPs) to send INVITE and receive 300 response
cli iedge add SYDLPSXLAB01EP 0 cli iedge edit SYDLPSXLAB01EP 0 realm PSX static 10.54.181.13 sip enable type sipproxy dtg SLPSXLBPAD01 use4904tg disable setdesttg disable vendor generic cli iedge add SYDLPSXLAB01EP 1 cli iedge edit SYDLPSXLAB01EP 1 realm PSX static 10.54.181.13 sip enable type sipproxy use4904tg disable setdesttg disable vendor generic cp PSX01CP
F1.1 EP for PSX dedicate Realm (Existing EP) REALM: 10.54.92.166
cli iedge add SYDPQ21LABVFNZEP 0 cli iedge edit SYDPQ21LABVFNZEP 0 realm SYDPQ21LABVFNZREALM static 10.54.81.11 sip enable type sipgw cp TEAMS01CP newsrcdtg SLPSXLBPAD01 use4904tg disable vendor generic cli iedge edit SYDPQ21LABVFNZEP 0 newsrcitg "SLVODAFNZL01"
B4-GW1 (Existing EP) REALM: 10.54.92.167 with 4904 disabled
cli iedge add SYDPQ21LABVFNZEP 1 cli iedge edit SYDPQ21LABVFNZEP 1 realm GVPSYDPQFLEXLAN394REALM static 10.54.81.11 contact 10.54.81.11:8012 sip enable type sipgw dtg SLVODAFNZL01 tg SLVODAFNZL01 use4904tg disable vendor generic
F1.2 EP for Selection of Ingress via DNIS REALM: 10.54.92.168
cli iedge add SYDLSIPLAB02EP 0 cli iedge edit SYDLSIPLAB02EP 0 realm GVPLABPMPLSGVOIPCUSTREALM static 10.54.81.12 contact 10.54.81.12:8012 sip enable type sipgw cp TEAMS02CP dtg SLVODAFNZL02 tg SLVODAFNZL02 use4904tg disable setdesttg enable vendor generic
F1.3 EP for Selection of Ingress via sourceTG=SLVODAFNZL03 (REALM: 10.54.92.168) with 4904 enabled
cli iedge add SYDLSIPLAB02EP 1 cli iedge edit SYDLSIPLAB02EP 1 realm GVPLABPMPLSGVOIPCUSTREALM static 10.54.81.12 contact 10.54.81.12:8014 sip enable type sipgw newsrcdtg SLPSXLBPAD01 dtg SLVODAFNZL03 tg SLVODAFNZL03 use4904tg enable vendor generic
B4-CSF2
cli iedge add SYDLSIPLAB02EP 2 cli iedge edit SYDLSIPLAB02EP 2 realm GVPLABPMPLSGVOIPCUSTREALM static 10.54.81.12 sip enable type sipgw dtg SLGVQ21PAD02 use4904tg disable vendor generic
B4-CSF1 (Existing EP)
cli iedge add GVMSYDPGIASYDLP01 1 cli iedge edit GVMSYDPGIASYDLP01 1 realm LABGIA210REALM static 10.54.81.13 sip enable type sipgw dtg SLGVQ21PAD01 use4904tg disable vendor generic
F4, B1 (EP for 3XX to LAB SWE1)
cli iedge add SYDLSWELAB01EP 0 cli iedge edit SYDLSWELAB01EP 0 realm PSX static 10.54.81.66 sip enable type sipgw newsrcdtg SLPSXLBPAD01 use4904tg enable vendor generic setdesttg enable URI 10.54.81.66
F4-B1 (EP for 3XX to LAB SWE2)
cli iedge add SYDLSWELAB02EP 0 cli iedge edit SYDLSWELAB02EP 0 realm TCISYDLSWELABREALM static 10.54.81.67 sip enable type sipgw newsrcdtg SLPSXLBPAD01 use4904tg enable vendor generic setdesttg enable URI 10.54.81.67
Sample Calling Plans
INGRESS FROM SUPPLIER CALLING PLAN
cli cr add TEAMS09980315INGCR cli cr edit TEAMS09980315INGCR calltype origin dest 09980315 prefix 64*09980315 cli cp add TEAMS02CP TEAMS09980315INGCR cli iedge edit SYDLSIPLAB02EP 0 cp TEAMS02CP
EGRESS TO PSX CALLING PLAN
(For 64* prefix numbers routed to PSX redirector)
cli cr add TEAMS09980315EGRCR cli cr edit TEAMS09980315EGRCR calltype dest dest 64*09980315 prefix 0998031512345 cli cp add PSX01CP TEAMS09980315EGRCR cli iedge edit SYDLPSXLAB01EP 1 cp PSX01CP
Link Calling Plan with MULTIPLE Calling Route
cli cr add TEAMS09980316INGCR cli cr edit TEAMS09980316INGCR calltype origin dest 09980316 prefix 09980316 cli cp add TEAMS01CP TEAMS09980316INGCR cli cr add TEAMS0998032INGCR cli cr edit TEAMS0998032INGCR calltype origin dest 0998032 prefix 0998032 cli cp add TEAMS01CP TEAMS0998032INGCR cli cr add TEAMS099803301INGCR cli cr edit TEAMS099803301INGCR calltype origin dest 099803301 prefix 099803301 cli cp add TEAMS01CP TEAMS099803301INGCR cli cr add TEAMS099803302INGCR cli cr edit TEAMS099803302INGCR calltype origin dest 099803302 prefix 099803302 cli cp add TEAMS01CP TEAMS099803302INGCR cli cr add TEAMS0998034INGCR cli cr edit TEAMS0998034INGCR calltype origin dest 0998034 prefix 0998034 cli cp add TEAMS01CP TEAMS0998034INGCR cli iedge edit SYDPQ21LABVFNZEP 0 cp TEAMS01CP
This section describes the implementation of the LCR feature in the PSX for this project.
LCR routing chooses a destination routing path based on the cost that provides the most savings. LCR makes the selection based on rate lists provided by one or more vendors. LCR must provide the least expensive way to route a call.
Vendors publish rate sheets to network operators. Network operators load and manage these rate sheets. The rate sheet data along with Quality of Service information is used to provide value-based routing to customers of the network operators. The rate sheet life cycle management includes parsing the rate sheets using their metadata template files, storing them in a local database to view them, pushing the optimized intermediate form rate sheets to PSX primary and secondary boxes, and undoing or rolling back loaded rate sheets. Routing of calls from customers to vendors relies on the vendor rates, offers agreed to with customers, exception handling, and call quality (or QoS).
Network Operators provide call routing services to their customer by using services from its vendors. Suppliers or vendors supply rate sheets, whereas customers are associated with Offer Bundles provided by the reseller. Network Operators offer bundled services to customers, which include a sell rate sheet. Offer Bundles can be generic and offered to multiple customers, or they can be made customer-specific to handle specific customer agreements. The TG and other call processing elements such as the carrier and subscribers are used to uniquely identify a customer.
A vendor contains a rate sheet and a set of egress trunk groups. The network operator offers multiple services to customers based on cost and quality. These services are referred to as Offers. Each Offer comes with a sell rate sheet that defines the cost TOTs and a set of quality parameters that define the expected quality of the offer. For example, a 'Premium' offer may cost more and has high quality, whereas a 'Silver' offer may be cheaper, but with a significantly lower quality compared to the Premium quality.
The network operator also picks certain vendors and associates them with the offer. This information may or may not be available to the customer. The association indicates that calls of customers using an offer will only be routed to the associated vendors taking cost and quality into account.
Quality of Service (QoS) is a combination of various parameters measurements which impact the call and voice quality. QoS depends on terminating vendor trunk groups. The QoS parameters are name-value pairs from the LCR perspective. The service provider can provision any number of factors or parameters.
QoS plays a major role in an Offer. A Premium package, for example, can come with a better quality of service as compared to, for example, a Silver package. Each package has its defined QoS parameter ranges. There is an expected QoS of the Premium Package Offer along with the cost as defined by the Sell Rate Sheet. The Network Operator must make sure that the vendors added to the offer are meeting the defined QoS.
QoS parameters are defined at a global level in the system and the defined QoS parameters can be chosen and combined using AND and OR logical operations with a subset of range values for computation purposes.
An Offer is associated with a QoS profile. If it is not associated (NULL profile), then no QoS checks happen for that Offer.
Each QoS profile contains a set of rules. Each rule has an order. The rules are evaluated based on the order. Each rule contains one or more QoS parameters interconnected with AND operations.
Each QoS parameter range must be defined and be within the range defined for that parameter at the global or system level. The rules within a given profile are interconnected with the OR operation. If a rule is evaluated to TRUE then no further evaluations are necessary and the QoS standards are met. If it is evaluated to FALSE then the next rule is evaluated. If all rules in the given profile are exhausted and all of them yielded FALSE, then it indicates failure to match set standards of QoS and results in ignoring the route associated with that egress TG.
8 QOS Parameters for LCR or VBR are given below
1. AHCT: Average Call Hold Time
2. ASR: Answer Seizure Ratio (Call Attempts Vs Completion)
3. JITTER: Jitter is the variation in delay of received packets
4. MOS: Mean Opinion Score
5. MOU: Minutes of Usage
6. NER: Network Effectiveness Ratio. It's similar to ASR but excludes customer behavior & terminal behavior like user busy or no answer
7. PDD: Post Dial Delay. It's the time between end of dialing & beginning of ringing
8. PLP: Packet Loss Percentage
Each vendor has a rate sheet and expected or committed quality of service (based on a bilateral agreement). Each vendor owns one or more trunk groups. A vendor may be part of one or more offers. Each trunk group may be associated with the QoS parameters, which is used in rule computation to assess, whether the TG meets the quality standards defined at the Offer level. For example, consider Vendor A is put into a Premium Package. If one of the trunk groups, TG1, owned by the vendor has an extended PDD, then the network operator can manually update the PDD QoS parameter on that TG. This value may result in failure of some or all the QoS rules defined at the Offer level for calls attempting to go over TG1. As a result, the TG1 may not be considered for routing, because it may not meet the quality requirements of the Premium Offer. But, the same trunk group QoS range may be meet the requirements for the Wholesale Package.
If no QoS parameter is set, then a call is routed on a trunk group without any QoS checks. The QoS name-values must be provisioned by the Network Operator using the LCR provisioning GUI or CLI mechanisms.
A report which details trunk groups that have QoS parameters set is available.
A customer subscribes to an Offer provided by the Network Operator. A customer may subscribe to more than one offer in certain scenarios. For example, a customer may purchase a Premium package to handle specific calls; for top management callers, and Silver package for all other callers in the company.
The customer expects the quality of service to be on par with the defined ranges as part of the 'Offer'. The QoS parameters are defined as part of the QoS profile and associated with an Offer. QoS parameter values can be set at the Egress Trunk Group Level. It is the responsibility of the Network Operator to provision the QoS values appropriately on Trunk Groups.
All data necessary to identify a customer and an offer is available in a table called VBR_CUSTOMER_IDENTITY. The ingress call processing elements which identify a customer is a part of this table. The call processing element types supported are currently limited to the following (ordered by precedence – high to low):
The Subscriber value may contain a prefix instead of full number. There is no primary key for this table. A unique index is needed on all columns to avoid duplicate rows. The value Sonus_NULL is used if no value is provisioned.
From a service perspective a Network Operator needs to guard against losing money or control how much money they are willing to lose. This directly affects the routing decision for a call. A Network Operator can route calls for certain customers with a small or even negative profit margin but can drop calls for other Customers if the calls incur a loss. It is critical for the LCR system to support a mechanism for profit protection for Network Operators.
Margin is defined on an Offer by the Network Operator. A service provider can for example define a margin as at least X% profit, no loss routing, or a Y% loss.
Network Operators can override the margin defined at the offer level by setting a margin at the customer-offer level.
A margin profile is associated with either an Offer or with a Customer in the context of an offer. The margin is the same for all the dial codes in the sell rate sheet associated with the offer. If the margin profile is not associated with an Offer or customer, then the call is completed irrespective of price. The sell rate sheet and margins are ignored, in this case. The margin profile contains a percentage. If the percentage is positive it indicates a profit, if it is negative it indicates a loss.
For example, if the percentage is +20%, it indicates the profit has to be at least 20%. The margin profile then ignores all the routes where the cost is below the 20% margin. If the sell rate sheet indicates the price for the 781123 dial code as 0.5, then the vendor rate sheet entries prices are <= 0.4.
If the percentage is -20%, the service provider is willing to take a loss of at most 20%. So the margin profile ignores the routes where the cost is above 20% loss. If the sell rate sheet indicates the price for the 781123 dial code as 0.5, then the vendor rate sheet entries prices are <= 0.6.
The gain or loss percent value is computed from the sell rate sheet.
Two customers may sign up for same Offer (for example, Premium), the network operator can set up different margins for these customers by overriding the margin profile defined at the offer level.
Volume or Dollar Commitment
This is a commitment from the Buy Side to the Sell Side to route the committed amount of call in terms of volume, that is Minutes of Use, or in terms of dollar amount paid to the Sell Side, over a specified time period. The time period is typically on a monthly basis. Some Network Operators may, once the quota committed to a Vendor is filled before the month end, temporarily suspend call termination towards the vendor if a cheaper vendor can be used to terminate the calls until the start of the next month.
Sonus LCR provides place holders for minutes of use. As part of the vendor data, the "minutes of use" flag is turned ON. When this flag is turned ON, it influences the routing. If MOU is turned ON, then the vendor is used as top route irrespective of cost, but the cost has to be within the margins defined. This means when a vendor has a dial code which can complete the call, it need to be chosen (based on if the vendor is part of the Offer) irrespective of cost. If more than one vendor has the MOU agreement, then the vendor priority determines which vendor to choose first in call completion. QoS filtering is also applied on the MOU vendors.
Some of the dial codes for specific suppliers be blacklisted for all customers or for a specific customer. A customer can request a supplier to be put in black list. An offer may be associated with zero or more customers. Each customer has the ability to put certain suppliers or dial codes in the black list.
The exceptions contain type and scope. The scope indicates the scope of the exception (ALL, Offer Id, or Customer Id). Each type may have one or more values. The following types and values are supported. If the CustomerId is Sonus_NULL, it impacts all customers.
Rate sheets come in various formats and flavors. The Rate sheet from each vendor follows a different template. The Rate sheet template defines the metadata and also provides parsing instructions.
Loading a Rate sheet involves:
Load Rate Sheet to the PSX:
The following example shows the generation of the PSX loading the “Rate Sheet”.
Rate sheet example (Viettel-P.csv):
Template example (Viettel-P_Template.dat):
Save both files in a directory readable for the “ssuser”.
Prior to loading a rate sheet, the PSX must be provisioned with the Vendor names and Offer names.
Log in to the PSX as ssuser and execute the following commands:
This command generates the intermediate rate sheet (intermediate_vendor01.dat). This rate sheet is loaded into the PSX later.
lcrrsprsr -t <path>/<template file> -i <path>/<rate sheet file> -o <path>/<intermediate file>
To upload the intermediate file to the PSX, run the following command:
lcrrsldr -l <path>/<intermediate file>
To load an offer rate sheet, change the type to “OFFER” in the business section. The rest of the template remains the same.
To generate the intermediate rate sheet, run the following command:
lcrrsprsr -t <path>/<template offer file> -i <path>/<rate sheet offer file> -o <path>/<intermediate offer file> -ofr offer_id
To load the rate sheet for the offer:
lcrrsldr -l <path>/<intermediate offer file>
Use this screen to define the currency data of the rate sheets.
This Routing Label contains the routes associated with the vendor which the PSX returns in the policy response to the SBC/GSX. The routes selection in the action frame notifies the PSX that a route must be returned as part of the response. Each combination of the SBC/GSX node / Trunk Group (Egress TG) pair must be added as a route option in the Routing Label.
For this design, the following routing labels provide an example of the design. Appropriate routing labels are created in actual implementations.
The following are the routing labels that are being used for the vendor associated with the routing label.
Routing Label | Vendor |
SINGTEL_PREMIUM_RL | SINGTEL_PREMIUM |
PCCW_PREMIUM_RL | PCCW_PREMIUM |
VIETTEL_PREMIUM_RL | VIETTEL_PREMIUM |
CITICTEL_STANDARD_RL | CITICTEL_STANDARD |
SINGTEL_STANDARD_RL | SINGTEL_STANDARD |
Create a Vendor entry using the LCR Vendor screen. Make sure you provision the Vendor Id (for example, VIETTEL_PREMIUM), a Routing Label Id (for example, VIETTEL_PREMIUM_RL) that is associated with the vendor, and a Currency Code (for example, USD).
To import Vendor Rate Sheets, use the rate sheet parser and loader tool to load vendor rate sheets. The vendor must exist in database for the data to be imported.
lcrrsldr -l <path>/<intermediate file>
Make sure the vendor name matches the Vendor template file.
Create an Offer entry using the LCR Offer screen. Set the Offer Id (for example, PREMIUM). If needed, create Offers and provide the Offers to the customers. Offers can contains a sell rate sheet and a set of QoS parameter values. The following is an example of an offer for US customers.
The example above contains 3 vendors.
To import Offer Rate Sheets, use the rate sheet parser and loader tool to load offer rate sheets.
The Offer must exist in database for the data to be imported. Loading offer rate sheet is optional and is necessary only when margins are a consideration.
lcrrsldr -l <path>/<intermediate offer file>
There are 4 types of LCR offers in this initial deployment:
LCR Offers | Description |
PREMIUM | Assigned to national to international calls beginning with 007 prefix |
STANDARD | Assigned to national to international calls beginning with 008 prefix |
PREMIUM_TRANSIT | Assigned to TDM international trunk groups for international to international calls |
STANDARD_TRANSIT | Assigned to SIP international trunk groups for international to international calls |
The following is an example of an LCR Customer:
Set the Customer Identification Criteria (Call Processing Element Type). The CPE types are Trunk Group, Gateway, Carrier, or Subscriber.
Associate Offers with a customer. For this deployment, Carrier (007) is an example for PREMIUM (Premium Customers).
There are 4 types of LCR customers in this initial deployment:
LCR Customer | LCR Offers | Identification Criteria |
PREMIUM | PREMIUM | Carrier = 007 |
STANDARD | STANDARD | Carrier = 008 |
PREMIUM_TRANSIT | PREMIUM_TRANSIT | Trunk Group = TDM International Trunk Groups i.e. BTSGP3_TG |
STANDARD_TRANSIT | STANDARD_TRANSIT | Trunk Group = SIP International Trunk Groups i.e. BIMIC1_TG |
For the LCR deployment, the following additional entity is created:
1) Routing Label = LCR_RL
The routing label above is required for LCR configurations with LCR selected as the action.
2) Standard Route
The standard route above is an example of a route with an assigned LCR routing label. This standard route affects all calls in the 007partition. The LCR_RL routing label means that the PSX will process all calls matching the criteria as an LCR call.
Use this to create minimum and maximum values for each QOS parameter as shown below in the sample configuration:
PSX uses this table to update the QOS values for every TG of QSBC2 and QSBC3 in this example.
This table is also used to select or reject that TG while returning routes in the PSX Response in 300 Multiple Choice.
Configuring SSH for PSX and Ribbon Protect's Dig Core Pod
Ensure that you have the following details of the Ribbon Protect's Dig Core Pod:
1. You must manually complete this configuration before the file transfer begins on both Active and Standby machines.
$ ssh-keygen
The command above generates two key files:
id_rsa which is a Private Key
id_rsa.pub which is a Public Key
$scp /export/home/ssuser/.sshid_rsa.pub pstk@DigCoreIP:/home/pstk/.ssh/id_rsa.pub
ln -s /usr/bin/rsync /usr/local/bin/rsync
This is needed for the Solaris PSX Master to work with Dig Core Pod.
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA2t+bzQrc7iaiIZuxaoLaP2p7QWDQkMuNhMzh4KlqMADrnUl0Jgaq7tMYvBbEpV2a8DbOqZKBahqz/DgKZNW3dwPcZ6GsbGVGRfOyuHbDdR+A/2SGXw1CqmMMBx/5eU0tFLhZv+qnY/BpZaIS9hc/xbhEQdBwRmcHoS0bCuQkK+q5+nbCxKV+EcleHqFG3i9vVaOF5E6fNlxSHGdtCA/K78kIPSR2zye9AmfrqsubMUqxX+4VpjxL8gfL5/X27Nsp0LhOCbBq4Mw9MbaPPcg6qTOs4WZvCeEmWsLEYQnRfhp6WNIOG7OYOEowCOJAfbTCXYphzNYSUXj01w+nZ4JQ== ssuser@mypsx
where mypsx is the Hostname of the Master PSX machine.
2. Set up KPI transfer and processing.
This is a one-time configuration to complete the setup process.
$setupnextxkpi.sh <Dig Core IP address or host name> <wait time before raising trap>
$setupnetxkpi.sh 10.6.30.128 10
where
10.6.30.128 is the IP Address of the Dig core Pod.
10 is the wait time before raising trap
$ ssh -i /export/home/ssuser/.ssh/id_rsa pstk@DigCoreIP Are you sure you want to continue connecting (yes/no)? yes
3. Restart the Softswitch on the Master PSX.
cd /export/home/ssuser/SOFTSWITCH/BIN ./stop.ssoftswitch
cd /export/home/ssuser/SOFTSWITCH/BIN ./start.ssoftswitch
The softswitch starts the kpinonstop.sh (if exists) in the background and stops kpinonstop.sh, kpisync.sh and lcrpildr if they are running before invoking kpinonstop.sh.
The softswitch stops kpinonstop.sh, kpisync.sh and lcrpildr if they are running.
This ensures that the KPI transfer functions long as the softswitch is up and running
Make sure that the Ribbon Internal IP address is in a different network from the network of the devices under monitoring such as PSX, GSX, SBX, QSBC.
Log in to Ribbon Protect GUI via the web browser with its Management (MAG) IP.
Go to System -> Add-on Manager -> Q20-Q21 Live Base KPIs -> Click "Deploy Add-on" for deploying the Add-on for VBR.
Go to System -> Add-on Manager -> Q20-Q21 Live Extended KPIs -> Click "Deploy Add-on" for deploying the Add-on for VBR.
This add-on includes additional aggregations by gateway and also by static endpoint to compute codec KPIs, ISDN cause code KPIs, SIP Response Code KPIs, and QoS KPIs by Codec.
Go To Applications → Discover → KPI Sets → "Run" (if not in the run state).
Aggregation service for QSBC and Core SBC set to 5 mins interval (System -> Global Settings -> Aggregation Service -> Q20/21
Enable "Value based Routing" by configuring "min bid count" to "5" (or any number according to the requirement) and select "Update".
Go to Applications → Discover → Value Based Routing → Configuration.
When Ribbon Protect, PSX and QSBCs are configured and are up and running, you can check whether PSX is pulling data from Ribbon Protect. Access the PSX as root and check the /var/log/messages log.
If PSX successfully pulls data, you can see logs similar to the following:
Sep 19 05:44:54 STPSX02 lcrkpildr[29547]: lcrkpildr: finished kpi file (/tmp/VBR-network-15-2020-09-18Z23:35:00.csv) load at Sat Sep 19 05:44:54 2020#012.
Sep 19 05:44:54 STPSX02 lcrkpildr[29547]: lcrkpildr: loading took 0 seconds.
Sep 19 05:44:54 STPSX02 lcrkpildr[29547]: lcrkpildr: kpi file (/tmp/VBR-network-15-2020-09-18Z23:35:00.csv) load report (last updated=1600474494) - noValues=6, unchanged=70, gets=74, inserts=0, updates=4, gateway-trunkgroup not found=0, insert failures=0, update failures=0
Log in to the Ribbon Protect Internal IP and execute the following.
A) For Checking VBR/LCR data in Ale-Lcr Pod
1. To Display All running Pods
kubectl get pods -o wide
2. To Login to Specific Pod like Ale Lcr
kubectl exec ale-lcr-5dcd76c45-qkxcb -it bash
Ale Lcr Pod name varies. Take the name from the output in the previous step.
3. Check that the VBR/LCR csv file is stored in the following path.
cd /home/lcr/
B) For Checking VBR/LCR data in Dig Core Pod
1. To Display All running Pods
kubectl get pods -o wide
2. To Login to Specific Pod like Dig Core
kubectl exec digcore-5fb8988b65-cg829 -it bash
The Dig core Pod name varies. Take the name from the output in the previous step.
3. Check VBR/LCR csv file stored in the following path.
cd /var/dropbox/pstk/stats/scoring/vbr
C) For Checking VBR/LCR data in Hadoop DB
Enter the following 3 commands:
kubectl exec hadoop-master-0 -it bash su -s /bin/bash impala -c "impala-shell --ssl -k -i hadoop-data-0.hadoop.default.svc.cluster.local" use sensorstore;
1. To Check the Quantity of Q21 CDRs fetched by Ribbon Protect from Q21
select count(*) from tbl_ribbonsbcqx_cdr;
D) For Checking VBR/LCR data in PostGres DB
Enter the following 3 commands:
kubectl exec postgres-0 -it bash psql -U postgres appstore; select * from data_aggengine.tbl_kpi_qx_vbrstats_by_egress_tg;
E) For checking Ribbon Protect Log
Log in to the Internal IP and then go to directory /flume and check the latest vigil log.
cd /flume vi vigil-1591603823719-192.log
There should not be any SQL exception related errors like the sample log shown below:
[2020-06-16 12:51:05,910][aggengine][ERROR][aggengine][vigil.app.common.DBActor][43]: SQLException SQL State = 08006 Error Code = 0
[2020-06-16 12:51:05,911][aggengine][ERROR][aggengine][vigil.app.common.DBActor][44]: SQLException message An I/O error occurred while sending to the backend.
[2020-06-16 12:51:05,911][aggengine][ERROR][aggengine][vigil.app.common.DBActor][45]: SQLException
These Application Notes describe the configuration steps required for QSBC interop with PSX Redirector and Ribbon Protect. All features and serviceability test cases were completed.