FAQs about SBCs
Sessions determine the number of concurrent calls that the SBC can handle.
The sessions can be extended in the SBCs by means of a configuration change, once they have been managed at the administrative level with the manufacturer:
Example of sessions activated on Oracle:
SBCsSBC # show entitlements
Provisioned Entitlements:
——– —————–
Enterprise Session Border Controller Base: enabled
Session Capacity: 100
Advanced: enabled
Admin Security:
Keyed (Licensed) Entitlements
———– ——————
SBCM #
When planning an increase in sessions, it is important to take into account the capacity of the surrounding elements and the network itself that supports the service. That is, on the one hand, both the switchboard and the core part must have an equal or lesser number of licenses than those configured in the SBC. On the other hand, the access provided by the operator to support the service must be sized with the necessary bandwidth.
The configuration of the increase of sessions could imply a service cut in case it is necessary to expand the number of dedicated ports and this increase implies a change in range.
To monitor the service, Oracle has the Operation Monitor tool (EOM in its company version, OCOM in its operator version) that allows you to analyze VoIP systems in real time and store historical data for subsequent studies.
The Operation Monitor provides display of the traces in diagrammatic format and correlation of the call between the different network elements, providing a complete view of the call for analysis.
In addition, it offers the possibility of defining thresholds and generating and sending alerts based on various KPIs, simplifying the tasks of monitoring services.
It also allows functionalities such as analysis of traffic by element, analysis by trunk, statistics, filtering of historical data by numbering, filtering by date or time period, QoS analysis of calls, jitter, etc.
The different manufacturers of SBCs incorporate mechanisms for the verification of their use. For example, Oracle has statistics that show the total capacity of sessions configured in the machines, the current consumption of sessions and the peaks of concurrent sessions consumed since the last reboot:
SBC # show sessions Capacity = 100 Session Statistics - Period - -------- Lifetime -------- Active High Total Total PerMax High Total Sessions 6 8 14 457 861 66 69 SIP Sessions 6 8 14 457 861 66 69 H.323 Calls 0 0 0 0 0 0 IWF Statistics - Period - -------- Lifetime -------- Active High Total Total PerMax High H.323-to-SIP Calls 0 0 0 0 0 0 SIP-to-H.323 Calls 0 0 0 0 0 0 SIP Audio / Video Statistics - Period - -------- Lifetime -------- Active High Total Total PerMax High Audio Calls 6 8 12 371 699 57 68 Video Calls 0 0 0 0 0 0 SBC #In cases where a more exhaustive analysis of usage statistics is necessary, our recommendation is to install an Oracle Operation Monitor traffic monitoring tool. With this tool the customer can monitor make calls, get reports by trunk, by month, by numbering, etc., a very wide range of statistics and reports.
The different manufacturers of SBCs incorporate different mechanisms for the detection and correction of hardware errors. For example, Oracle SBCs have diagnostic images that can be loaded and run to analyze equipment at the hardware level and verify its status.
In the event of detecting problems in the SBC, either due to the execution of a diagnosis or due to inoperability of the equipment, RMAs are articulated with the manufacturer, complete or partial according to the SBC manufacturer, equipment model and the affected element.
The manufacturer manages the shipment of the spare part in question to the customer’s headquarters to proceed with the replacement and recovery of the affected service.
Yes. There is a false conviction that only Ribbon or Audiocodes SBCs support it. Since release 8.3, Oracle provides the necessary functionalities to adapt to the requirements of Microsoft Teams to configure direct routing. This Teams functionality enables Teams users to communicate with the PSTN.
The SBC makes it possible to adapt the coding of the messages according to the negotiations between the switchboard and the operator’s network.
If it is necessary to negotiate different codecs at both ends of the call, the SBC can perform the transcoding. In some cases it is necessary to have a specific hardware module and / or specific licenses for it. You can consult more information about the capabilities of your SBC with the Quobis team,
Example: verification of transcoding capacity on an Oracle SBC:
> show prom-info all
(...)
PCB Family Type: Low Capacity Transcoding DSP
ID : Low Capacity Transcoding DSP
(...)The HA (high availability) cluster solution consists of having two computers with replicated configurations playing different roles; active and standby.
With this configuration, neither of the two SBCs assumes the role of the main team and the backup team, but rather the active / standby role, sharing the same virtual IPs.
The SBCs maintain communication about the health level of each one, which allows that, when problems such as an interface drop, power problems, fan problems, etc. are detected in the active equipment, the service would automatically switch to the other. SBC avoiding loss of service.
It will depend on the exchange rate and manufacturer of the SBC. For example, in Oracle SBCs two types of changes are defined, rtc-supported and not rtc-supported, depending on the need to restart the computer to make the configuration change effective.
Some examples of configuration changes that do not imply restart are the application of HMRs, changes in LRTs, inclusion of new PBXs in established trunks, adding NTP servers, etc.
Examples of not rtc-supported changes would be negotiation changes of a physical interface, configuration of the monitoring tool, changes in HA, establishment of new trunks associated with a new physical interface, etc.
Although some SBCs have the ability to reproduce voice-overs, this functionality is mainly focused on solving problems in specific scenarios, such as the absence of Ring Back tone on certain calls. The use of this functionality is not recommended to try to implement an IVR or a voice-over service. You can consult more information about the capabilities of your SBC with the Quobis team.
The cluster of SBCs in HA allows switching the service between the two computers, either automatically due to health problems in one of them or intentionally due to maintenance work.
Switching between both SBCs in the cluster does not cause loss of service, that is, calls in progress at the time of switching would remain established without any impact.
The SBCs have a web interface with a configurable dashboard in which various parameters can be displayed, such as interface status, sessions consumed in real time, physical state of the equipment (such as temperature, memory or CPU consumption), etc.
SBCs allow system monitoring through SNMP protocol.
The SNMP configuration on the SBCs enables SNMP queries and the sending of Traps to the specified community:
snmp-community
community-name Community
access-mode READ-ONLY
ip-addresses 10.1.2.251
trap-receiver
ip-address 10.1.2.251:162
filter-level Critical
community-name CommunityThrough the different MIBs it is possible to monitor in the SBC, for example, CPU consumption, memory use, health level, active sessions, temperature, etc. Quobis collaborates with clients by configuring these Traps so that those responsible for monitoring and first level support can detect these incidents.
The firmware upgrade process consists of making a change in the image that runs in the SBC for a more updated version.
Each update published by the manufacturer contains improvements and a bugfix over previous versions, which means avoiding possible problems in the operation of the service.
In the case of clusters in HA, the firmware update would not entail a service outage, as it acts on the equipment in standby in the first instance, switching the service and repeating the process on the other equipment in the standby role after switching.
The process to follow for this task would be:
Preliminary tasks:
1. Verification of the current FW version of the equipment
2. Download of the new firmware version, verification of the release notes and upload of the new version by FTP to the SBCs in the corresponding partition
Execution of the update:
1. Substitution of the old bootloader file for the new one downloaded, renaming it accordingly in each of the SBCs
2. Modification of the bootparams of the SBCs so that when they reboot they start with the new version of FW
3. Reboot
4. After finishing the update in the standby SBC, balance the traffic and repeat the process in the other equipment.
Rollback
1. Restore the bootparams valueOrderly
2.reboot of the computers
The estimated time for the update process is approximately 1 hour (time conditioned by the upload speed of the new firmware that allows the connection)