How to build your own VoIP system part 3!

In Part 1 of our series “Build your own VoIP System,” we learned the very basics of how VoIP and SIP in particular works.

In Part 2, the setup of a Skype-like service was explained.

This is Part 3, where you will learn how to protect existing VoIP deployments with the Sip:provider acting as a Session Border Controller (SBC).

Introduction

Over the last years, we’ve been developing the NGCP technology to make our products the best Class 5 Softswitches in the market. 90% of our deployments are Class 5 scenarios, where we do green field deployment or migrations from legacy systems. There are three  ways we’ve deployed the NGCP based products, though:

  • As Class 5 platforms. This is the usual way as we explain in the handbook.
  • As SBC systems, to protect and enhance already existing Class 5 systems.
  • As wholesale systems, just sending calls between peers and doing the accounting of high traffic.

Benefits

This blog post explains the SBC scenario and its benefits for already existing, in production Class5 or PBX systems. Before we start the technical part, let’s imagine a simple scenario: You have a company with people around the world and your PBX system is exposed to the internet to grant access to your employees or to let customers call your company via SIP. You now lock down your PBX system and only allow traffic coming from a Sip:Provider system that will act as SBC in front of your PBX system and will be the only element exposed to the Internet. Why would you do that? What does the Sip:provider provide to the PBX system?

1. Security

  • The Sip:provider platform provides DOS protection system, being able to handle thousands of requests per second, banning the originating IP addresses without measurable performance impact.
  • It also provides DDOS attack protection to prevent distributed attacks bypass the DOS protection to bruteforce a subscriber’s password.
  • It can limit the number of overall simultaneous calls and outgoing simultaneous calls per subscriber and per account. In our example, the PBX can do the same but it could be that we want to have different limits for direct connections to the PBX in the company LAN or for road-warrior connections.
  • It can block incoming and outgoing destinations. Maybe we want to restrict the destinations for outside connections while we have another set of permissions for in-office connections.
  • It has a real-time billing/rating system with prepaid profiles to limit the amount of calls/minutes/expense per month (PRO systems only)
  • It has an anti-fraud system with automated notifications and/or subscriber blocking mechanisms in case a threshold has been reached in a billing period.

2. Functionality

  • It has full UDP/TCP/TLS signalling support. The subscribers can talk TLS with the Sip:provider SBC while it will talk UDP with the PBX/Class5 system. This is something recommended on mobile devices not only because the security you achieve by encrypting the signalling but also because you avoid most SIP ALG mechanisms and traffic filtering.
  • It has full IPv6 support. It can translate IPv6/IPv4 for both media and signal with its dual stack.
  • It has parallel forking support. It will handle multiple registrations for the same subscriber but will register only once against the PBX.
  • It has to cancel reason support for parallel forking.
  • It has a reliable real time billing and rating system.
  • It provides per-leg session timers. You can set different session timers to each leg of the call, or even disabling it for endpoints that do not support it.
  • It has RTP timeout detection with automated call teardown.
  • It provides codec filtering. You can whitelist/blacklist the codecs that will be negotiated between the endpoints. You can also manipulate codec preferences.
  • You can set a max call duration for any call and tear it down once the limit has been reached.
  • It can take care of handling the NAT for the subscribers and sending the keep-alives to each device.
  • It can use different credentials for external subscribers and for registering against the PBX/Class5. That way subscribers don’t need to know the SIP credentials of the PBX system.
  • You can perform SIP method and header filtering for low-level manipulation.
  • There are early media announcements for several failed call scenarios like a busy or offline callee etc.
  • It is multi-domain capable. This means that a single provider can act as an SBC for multiple Class5/PBX systems at the same time. With that feature, it can perform as a routing hub for multiple systems.
  • It is open source, so it can be extended and tweaked even to more exotic needs and use-cases.

3. Performance

The Sip:provider platform is designed to handle thousands of concurrent calls and subscribers. The Sip:carrier platform can handle millions of subscribers. It is a scalable technology that runs on carefully specified Dell servers for the PRO and on IBM Bladecenters for the Carrier. It is much more cost effective to scale a Sip:provider system than any other systems. In terms of performance let’s imagine this scenario:

One subscriber has 5 different devices registered against on a Sip:provider system. They use TLS for signalling, they are behind NAT, the registration interval is 5 minutes, the NAT keepalive is 30 seconds, session timer period is 90 seconds and the client devices also send OPTIONS messages to the server. In the other leg, the Sip:provider registers once against the PBX, with a registration, expires on 6 hours, no NAT, using UDP as transport and session timers of 60 minutes. It’s clear that the traffic and the system load is lower on the PBX side without having to directly process the subscriber traffic.  If you extend this to hundreds or thousands (or millions!) of subscribers you’ll see that the existing system can handle more subscribers with the same hardware and less PBX/Class5 licenses.

Let’s go Technical

This won’t be a step-by-step tutorial of deploying a Sip:providerCE system (SPCE) as SBC. We offer deployment and configuration services as well as training and support contracts for this.  Let’s assume that you have already read the Handbook of the 2.6 system (the stable version at this point).  Although it describes a Class5 scenario deployment, almost everything needed in order to deploy the SBC scenario is covered there.

The necessary steps are:

  1. Read the Handbook. Really, do it.
  2. Install the system
  3. Set the networking address in config.yml
  4. Create a domain (we’ll use the IP address as domain in this example)
  5. Create an account
  6. Create a couple of subscribers
  7. Create a peering group with the PBX as a gateway and an empty (match everything) peering rule for it.

Let’s use examples:

Please note that for this deployment we won’t touch the already-in-production system configuration.

Asterisk system: We’ll use E164 numbers as username to simplify the example. We can always use rewrite rules in the Provider or in the PBX to work with different numbering plans. I’ve set up a 1.4 version since it’s a very common version in production environments. It would work the same way with other versions or even distributions such as Elastix.

  • IP: XX.XX.XX.XX
  • Subscriber 1: 4312001
  • Subscriber 2: 4312002

Sip:provider SBC system:

  • IP: YY.YY:YY.YY
  • Domain: YY.YY.YY.YY
  • Subscriber1: Testuser1
  • Subscriber2: Testuser2
  • Peer group: Asterisk PBX; Peer gw: XX.XX.XX.XX; Peer rule: Blank

We will make some changes to the low-level configuration. We’ll disable extra services and rating as we are using the most simple scenario in this example. Other changes like language-, address- and domain settings are omitted.

  • asterisk.voicemail.enable: ‘no’
  • kamailio.proxy.allow_non_numeric_to_pstn: ‘yes’
  • kamailio.proxy.presence.enable: ‘no’
  • networking.eaddress: YY.YY.YY.YY
  • rateomat.enable: ‘no’
  • sems.conference.enable: ‘no’
  • sems.vsc.enable: ‘no’

After modifying the file, apply the changes using the configuration framework: ngcpcfg apply

Now we can deal with the high-level configuration settings. As I mentioned before, we’ll create the YY.YY.YY.YY domain in the SPCE Admin panel. We’ll enable some default preferences in this domain that will be the default for every subscriber. Remember that any domain preference will be overwritten by the subscriber preference if it is set there as well. For the purpose of this example, just one preference is required: “force_outbound_calls_to_peer“. This setting will force all calls to SPCE subscriber to be routed to the peer even if the callee is local.

Create subscribers with proper SIP URIs and passwords. End-users will require those credentials to provision their softphones, tablets, mobile devices etc. After the master data is filled and the user is created, we need to tell the system to register on behalf of the subscriber to the PBX system. That’s easily done by just filling the preferences “peer_auth_user”, “peer_auth_pass”, “peer_auth_proxy” and “peer_auth_register” with the PBX credentials.

Once the preferences have been saved, the SPCE will automatically send a REGISTER request to the PBX system:

And that’s pretty much everything. The PBX will see the subscribers registered exactly as if there was no SBC in between so no changes need to be made to the configuration. Meanwhile, the SPCE will handle the attacks, NAT, transport and protocol translation, keepalives etc.

There’s still some work to do. Enabling REFER to be sent to the PBX (this is disabled by default in the SPCE) is needed if you put the SPCE in front of a PBX and phones use REFER for call transfers. It is not needed in front of Class4 or Class5 switches. To enable that, it requires white-listing the REFER method in Kamailio-proxy and white-listing some headers in the SBC profile.

Questions, Comments and Feedback

If you have any questions regarding the deployment, you can contact the Sipwise sales team for professional services.

Remember that Sip:providerCE is 100% free. You can install and use it without limitations. So, go and do a test deployment!

Enjoy!