The PortaSIP is a combination of a dispatching node and a processing node. While the dispatching node is the center of communication in PortaSIP (it receives and distributes call requests), the processing node is what handles the call processing. Therefore, when assessing the PortaSIP performance, the processing node must be considered.

To achieve higher performance, scale up your PortaSIP with additional processing nodes.

There are three important criteria by which PortaSIP performance can be assessed:

  • How many simultaneously registered SIP phones can it handle?
  • How many concurrent calls can it handle?
  • What is the maximum number of call attempts per second that it can process?

A single PortaSIP processing node residing on a separate PortaSIP server (assuming this server meets the hardware requirements described on www.portaone.com) can process about 200 call attempts per second. This means that every second, 200 users can begin a new phone call on your network (and the same amount of users could end their calls concurrently). In addition, the processing node can process about 1000 registration attempts per second (for services such as cloud PBX). Assuming that each phone re-registers every 10 minutes, on average, this translates to more than 45,000 simultaneously registered SIP phones.

How many concurrent calls does that translate into?

Link copied to clipboard

Assuming the PortaSIP processing node is working in SIP signaling-only mode, this would primarily depend on the average call duration (ALOC) and call success rate (ASR). Given an aggregated call processing speed of 200 call attempts per second, an average call duration of 5 minutes and a call success rate of 50% (the industry norms), 50% of the 200 attempted calls per second would succeed. This means that 100 calls would be connected while the same amount of previously connected calls would be disconnected. Since the average call duration is 300 seconds (5 minutes), approximately 100 * 300 = 30000 calls would be in a "connected" state at all times. Obviously if either your ASR or ALOC change, that would have an immediate impact on the number of concurrent calls.

If RTP proxying is done for calls, then another consideration is the amount of voice traffic that has to pass through the server. Voice stream is extremely sensitive to delays in processing, so using a high-end network adapter is highly recommended.

A single PortaSIP processing node can proxy up to 3,000 concurrent calls.

How much bandwidth is required for call handling?

Link copied to clipboard

For a single call PortaSIP normally needs to transfer 10-20 KB of SIP signaling data.

However, the bandwidth required for SIP signaling is insignificant compared to that used by the RTP stream: 3,000 calls using the G.729 codec consume up to 100 Mbps of bandwidth. The same 3,000 calls using the G.711 codec consume up to 490 Mbps of bandwidth.

Thus, the amount of bandwidth required for call handling depends on the codecs you use and whether the media steam is proxied.

DoS attack protection for PortaSIP and the dispatching SBC

Link copied to clipboard

The SIP protector is a built-in firewall that protects PortaSIP and the dispatching SBC (DSBC) from network threats such as DoS attacks. It also protects the internal communication channel of PortaSIP components from accidental or intentional abuse.

The protector utilizes the Linux iptables modules:

  • hashlimit to analyze network traffic and shape it. This basically lets you block/drop incoming traffic having abnormally high rates.
  • string to parse SIP headers. This is needed to distinguish among the types of incoming requests. The following requests are supported to set the limit: REGISTER, INVITE, OPTIONS and overall requests.

The configuration options for PortaSIP and DSBC are the same and can be defined in a single place – via the Configuration server web interface. The administrator can define the maximum number of packets permitted to arrive from a specific IP address. If the threshold is crossed, further requests are dropped. If no new packets arrive, the counter gradually decreases. The decrease speed is calculated as 60 sec/number of allowed packets (e.g., for 100 packets it will be 60/100 = 0.6 sec.) If no packets arrive within a minute, the counters are reset.

The protector supports the UA blacklist. This is the list of UAs that can potentially be used for sniffing or DoS attacks (e.g., sipcli, eyeBeam release 3006o stamp 17551, etc.). Thus, requests sent from these UAs are dropped and logged for future investigation.

The SIP protector is the out-of-the box solution for protecting PortaSIP and DSBC from DoS attacks. Refer to Protection from DoS attacks for more details.

For more advanced protection, consider using external firewalls, SBC or other protection techniques.

Docs for
What's new
Admin manuals
Handbooks
UI help
Developers documentation