PortaSIP architecture

PortaSIP provides a single point of entry (a single visible IP address) to your wholesale partners and SIP trunking, and to your cloud PBX, residential, mobile and other customers. Incoming calls are handled first by a dispatching node and then are evenly distributed to back-end processing nodes. As a result:

• The interconnection process with other carriers and customers becomes really simple.
• Your network topology is not exposed to either your customers or carrier partners.
• In case of a hardware failure at one of the servers, the system automatically reconfigures and keeps processing calls without any changes on the client side.
• Call activity is load-balanced among available processing nodes.
• Your overall traffic processing capability can be easily scaled up by simply adding more back-end PortaSIP servers.

1. A call originates from your customer’s network to the virtual IP address of PortaSIP. The call initiation request is delivered to the currently active dispatching node.
2. The dispatching node forwards the call to one of the available processing nodes.
3. The processing node receives the call request and sends an authorization request to PortaBilling.
4. PortaBilling validates the call credentials, balance and other settings (e.g., geo-IP restrictions), and computes a list of outgoing routes. The result is then returned to the processing node.
5. The processing node attempts to establish an outgoing call leg and sends a call initiation request to the dispatching node.
6. The dispatching node forwards the call request to the actual gateway of the termination carrier. All further communication is forwarded via the dispatching node. Thus, the customer (originator) and carrier (terminating party) only see the PortaSIP virtual IP address.

PortaSIP consists of:

• a dispatching SBC,
• a dispatching node,
• a processing node, and
• a call quality tracker node for call quality metrics collection and processing.

The dispatching SBC is the dedicated PortaSIP node that operates as the high-level inter-system/inter-site proxy. The dispatching SBC accepts call initiation requests and dispatches them across systems. It operates in high-availability mode and presents a single point of entry both to your termination partners and to your wholesale, SIP trunking, residential and other customers.

• Virtual IP address – the virtual IP address serves as an entry point to the cluster. That is, all SIP traffic sent from/to the cluster is routed via the virtual IP address. This IP address is visible to customers and carrier partners, while your actual network topology is hidden from the outside world.The virtual IP address is shared among all dispatching nodes in the cluster, though it is only used by the active dispatching node. The currently active dispatching node, as the center of all communication, is always at the virtual IP address. If this dispatching node becomes unavailable for some reason (e.g., due to a failure), the virtual IP address is switched to another dispatching node that becomes active.
  The PortaSIP cluster’s virtual IP address must always be public.
• SIPProxy – the SIPProxy communicates directly with customers’ and vendors’ equipment via the SIP protocol, sheltering the core cluster’s components from direct access. The SIPProxy also provides NAT traversal and performs load balancing of incoming traffic among all components in the cluster.
• Processing Node Controller – the Processing Node Controller keeps track of the active components in the cluster. If one or more components become inactive, the Processing Node Controller detects this change and notifies the other cluster’s components accordingly.
• Limit Controller – the Limit Controller regulates the number of dialing attempts that can be made by an endpoint (e.g., a PBX) each second.
• SIP Protection – SIP Protection is responsible for PortaSIP’s security. It protects PortaSIP from network threats, such as denial of service attacks. Please refer to the DoS attack protection for PortaSIP and the dispatching SBC paragraph for details.
• Mail Proxy – the Mail Proxy forwards email, voice mail and fax messages to an available processing node for further processing. The Mail Proxy supports IMAP, SMTP and SMTPS protocols.
• SMPP Proxy – the SMPP Proxy performs the following functions:
  • Forwards messages received by the PortaSIP cluster via the SMPP protocol to the active IMGate for further processing.
  • Transmits messages received from the IMGate to SMSСs (short message service centers) or SMS aggregators for further delivery to mobile networks.

• Call Controller – the Call Controller combines functionalities of the Back-to-Back User Agent, the RTP Proxy and Media Server. Its main tasks include:
  • Processing call initiation requests (INVITE SIP messages) from endpoints and initiating outgoing calls.
  • Transporting the media stream (the actual voice traffic) from one endpoint to another.
  • Playing a number of short voice prompts (such as current balance, maximum allowed call duration, etc.) to end users.
• Registrar – the Registrar processes registration requests from customers’ IP phones and stores their location information.
• Subscription Manager – the Subscription Manager communicates both with users’ devices and with cluster components handling presence requests and sends notifications about users’ availability. This is a key component for providing presence and BLF services where it is important to see whether another party is currently online, off-line, busy, etc.
• IMGate – the IMGate enables online messaging and message storage for offline users (so they can receive messages later).

The Call quality tracker is the dedicated PortaSIP component is used for call quality monitoring. It collects call quality metrics from the RTCP RR (Real-Time Transport Control Protocol receiver reports) and RTCP XR (extended reports) messages. It also processes call quality metrics from call quality summary reports (RFC 6035).

The Call quality tracker communicates with:

• the RTPProxy to receive RTCP RR/RTCP XR messages during the call;
• the Subscription manager to receive summary reports in PUBLISH messages at the end of the call.

The Call quality tracker retrieves metrics values from the RTCP RR/RTCP XR packets, aggregates them and then stores the aggregated values in the local database. Summary reports in PUBLISH messages already contain aggregated metrics; therefore, the Call quality tracker only extracts and records them within the database.

The Call quality tracker also communicates with the PortaBilling web server to provide metrics values.

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. (Please refer to the Protection from DoS attacks chapter in the PortaBilling Administrator guide.)

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

While there are multiple dispatching nodes (each on its own physical server), only one dispatching node is active (receiving and distributing call requests), so all others are on standby. All servers in the cluster exchange heartbeat messages and if the server with the currently active dispatching node becomes unavailable due to hardware failure, the IP address is immediately switched to another server. That dispatching node is then activated to receive and distribute call requests.

The list of available processing nodes is constantly updated – entries are added when a processing node instance is started on a new server and removed when the server where the processing node was running, becomes unavailable due to a hardware failure.

One of the remaining processing nodes immediately disconnects calls handled by a failed node and sends accounting records to the billing engine for these calls. Accordingly, subsequent call attempts are distributed among the remaining processing nodes.

For normal operation, PortaSIP requires at least two servers where dispatching nodes are deployed. The number of processing nodes is virtually unlimited and only depends on the required total processing capacity.

The current PortaSIP architecture allows for the efficient handling of Class 4 services (wholesale traffic exchange, SIP trunking, etc.) and Class 5 services (SIP registration, cloud PBX, presence (UA status publishing), etc.). The BLF service is supported for calls made or received by customer accounts and for calls made to account aliases, too.

Since PortaSIP presents a single virtual IP address to your partners and customers, cluster servers must be located in the same site (geographic area).

Receiving call requests on a single IP address allows you to receive traffic from customers with legacy equipment (which send traffic to a single SIP proxy IP address) and process it in PortaSIP, consequently making use of all its benefits. This solution allows you to efficiently scale your system to meet the requirements of growing wholesale call traffic.

The PortaSIP virtual IP address is the only point of entry to your network, therefore only this IP address can be used for registration.

The virtual node IP address, since it is the center of all communication. The customer (originator) and the carrier (terminating party) see only the PortaSIP virtual IP address.

Yes, the Limit Controller component in PortaSIP allows the enforcement of so many calls per second. With this functionality you can decide upon and restrict the number of dialing attempts that can be made by an endpoint (e.g., a call center PBX) per second.

For more information, please refer to the Traffic density control section.

Is there a specific router configuration for PortaSIP?

No, there is no additional configuration requirement for routers or other network elements.