We try to keep the content of these articles varied – a mix of product info, industry events, operational best practices and technical tips. Today we’re going to double-down on the technical tips side of things, and share a best practice related to the Perimeta Session Border Controller.
If you don’t know what an SBC is, or don’t own a Perimeta then feel free to delete this email with no guilt. If someone else in the organization is responsible for technical work on a Perimeta, then maybe forward them this article, just in case it’s helpful.
Silent failures are bad
One of the powerful features of the Perimeta SBC is that you can configure specific rate-limits on every adjacency (interface with a particular device/trunk) – and these rate limits can even vary for different types of messages.
For example, you might have the following configured on an adjacency (I made up these numbers – these are much lower than a real system).
adjacency-limits
call-rate sustain 100 per-minute
in-call-rate sustain 500 per-minute
out-of-call-rate sustain 500 per-minute
regs-rate sustain 10 per-secondThis is fantastic, but if you only configure these limits, and don’t configure corresponding alarm thresholds, you could find calls getting rejected (when the limits get hit) without any alarm to warn you of what’s happening.
The Perimeta CLI does try to warn you of this – if you inspect the configuration after you’ve created it, you might see text like this – but unfortunately we often see systems where the limits have been configured, but the alarms have not.
! When this limit is breached, Perimeta will reject messages
! without any alarm being raised. It is advisable to configure an
! alarm via the CLI command config -> sbc -> diagnostics ->
! alarm-thresholds to provide notification when this limit is
! approached or reached.
How to set Perimeta default alarm thresholds
The good news is that you can set default alarm thresholds that will apply to all adjacencies, as a percentage of the configured limits. Here’s an example of how to do this for the call-limits.
config
sbc
diagnostics
alarm-thresholds
default-adjacency-alarms
call-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
The above configuration means that anytime the call-rate limit (100 per minute in the above example) exceeds 75% of that limit (i.e. 75 calls/minute) a minor alarm will be created, which then becomes a major or critical alarm at 85 or 95 calls/minute respectively (for that particular adjacency). If other adjacencies have different configured limits, then the alarms are percentages of those limits – so you can set these default alarm levels for use across the board.
Our recommended best practice is to configure these alarm percentages for all the different types of limits that you have configured. That may well include a call-rate-limit, in-call-rate-limit, ooc-rate-limit, regs-limit, regs-rate-limit, num-calls-limit, media-bandwidth-limit and media-streams-limit.
On top of that, you may have different limits for the adjacency “as-source” and “as-destination”, or you may have different sustain and burst limits configured – all of which would need to have alarm thresholds configured.
This is complicated…
If you’re unsure if you need to act, the simplest thing to do would be to copy all of your Perimeta configuration into a text file, and search for the “! When this limit is breached” text from the warning above.
- If that doesn’t appear, then at least your current limits have corresponding alarms in place.
- If it does appear, then you should be able to see the specific limit that you need to create as an alarm.
If you’re one of our clients, and you’d like us to configure all these alarms for you, then don’t hesitate to reach out (in some cases we’ve already done so – with your permission of course).
If you’re not currently a client, and would like to learn more about our support retainers, you can read more here.
