# Understanding Congestion Alarms

### Overview

The ProSBC monitors system health and call processing capacity in real time. When the system detects that calls are being rejected locally due to capacity constraints, it raises congestion alarms visible on the web portal's Status page. These alarms appear as orange indicators on the NAPs tab, the SBC tab, or the System Info dashboard.

Note: Congestion alarms are warnings—they indicate the system is under strain but still operational. They are not outage alarms (which appear in red).

***

### Types of Congestion Alarms

#### 1. NAP Call Congestion

Where it appears: `Status > NAPs` tab (orange), or individual NAP status page.

What it means: One or more incoming or outgoing calls on this NAP were rejected locally by the ProSBC due to capacity constraints. Only calls rejected by the local system count toward this alarm.

Important: Calls rejected by the SIP processing layer (tbsip) before reaching the call processing pipeline are invisible in the NAP's Total/Accepted counters but still trigger this alarm. This is why a trunk NAP can show congestion while showing zero dropped calls in its statistics.

Common causes:

* Max Simultaneous Calls: If a NAP has a configured limit (e.g., 5 calls) and traffic exceeds it.
* System CPU Saturation: Protective mechanisms reject new calls to preserve audio quality on existing calls.
* Media Resource Delays: High load causes RTP endpoint allocation to take too long; the system proactively rejects new calls.

#### 2. SBC High CPU Alarm

Where it appears: `Status > SBC` tab (orange).

What it means: The packet-processing CPU cores (DPDK/firewall engine) have exceeded 97% utilization. This affects SIP signaling and RTP packet forwarding at the network layer.

#### 3. Scheduling Problem Alarm

Where it appears: `Status > Host` or `Status > SBC` tab (orange).

| **Alarm**       | **Scope**         | **Meaning**                                                        |
| --------------- | ----------------- | ------------------------------------------------------------------ |
| Host Scheduling | Host CPU cores    | The VM/host is not delivering consistent CPU time to applications. |
| SBC Scheduling  | Packet-processing | The packet forwarding cores are experiencing scheduling jitter.    |

***

### Understanding the Processor Status Page

The `Status > Host > Processor Status` page shows real-time CPU utilization for each application.

| **Column**   | **Meaning**                                                         |
| ------------ | ------------------------------------------------------------------- |
| Percentage   | Current CPU usage of this application.                              |
| Congestion   | Threshold above which congestion effects are expected (80% of max). |
| Expected Max | Theoretical maximum CPU for this application.                       |

Technical Tip: `tbrouter` always shows approximately 100% CPU. This is expected behavior because it uses dedicated DPDK polling and does not indicate a problem.

***

### Understanding NAP Call Statistics

| **Counter** | **Meaning**                                     |
| ----------- | ----------------------------------------------- |
| Total       | All call attempts on this NAP.                  |
| Accepted    | Calls admitted into the system for processing.  |
| Answered    | Calls where the remote party actually answered. |

* Total minus Accepted = Locally dropped calls.
* Accepted minus Answered = Ring-no-answer, busy signals, or remote-side failures. (These are not congestion drops).

***

### Symptoms That May Accompany Congestion

When the system is under CPU pressure, you may observe these symptoms even if a specific alarm hasn't triggered:

* Delayed audio at call start: 1–3 seconds of silence after a call connects.
* Intermittent one-way audio: Media allocation was too slow to establish the path in time.
* Dropped calls during traffic spikes: The system rate-limiter is protecting existing call quality.

***

### Common Scenarios

Cause: `tbsip` is rejecting messages at the network layer before they enter the pipeline.

Solution: Check `Processor Status`. If `tbsip` is >80%, the instance needs to be scaled up.

Cause: This specific NAP likely has a Maximum Simultaneous Call limit configured too low.

Solution: Review NAP configuration and increase the limit if the remote endpoint can handle more traffic.

Cause: Even with `CPS = 0`, the Adaptive Processing Delay Limiter or SIP Resource Manager can reject calls if the CPU is overloaded.

Solution: Scale up the instance size.

***

### Frequently Asked Questions

Q: Why does the NAP congestion alarm trigger so easily?

The default is 1 locally rejected call per 60 seconds. For production, we recommend contacting support to adjust this to 5–10 calls.

Q: I see high CPU on tbsip but the SBC High CPU alarm is not raised. Why?

The `SBC High CPU` alarm monitors the packet cores (`tbrouter`), not the application cores where `tbsip` runs. Check the Processor Status page for `tbsip` health.

***

### When to Contact Support

Contact TelcoBridges support if:

1. NAP congestion alarms are frequent (multiple times per day).
2. SIP memory congestion appears in red.
3. You need to adjust congestion thresholds (as they may be hidden in the UI).
4. Audio quality complaints coincide with these alarms.

Please provide a `tbreport` covering the time of the event when opening a ticket.