Build your own VoIP System – Part 3: the sip:provider as an SBC
In Part 1 of our series “Build your own VoIP System” we learned about 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).
Over the last years, we’ve been developing the NGCP technology to make our products the best Class5 softswitches in the market. 90% of our deployments are Class5 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 Class5 platforms. This is the usual way as we explain in the Handbook.
- As SBC systems, to protect and enhance already existing Class5 systems.
- As wholesale systems, just sending calls between peers and doing accounting of high traffic.
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?
- 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.
- It has full UDP/TCP/TLS signaling 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 signaling 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 signaling 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 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.
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 signaling, 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 of 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 in 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:
- Read the Handbook. Really, do it.
- Install the system
- Set the networking eaddress in config.yml
- Create a domain (we’ll use the IP address as domain in this example)
- Create an account
- Create a couple of subscribers
- Create a peering group with the PBX as 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’ll 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:
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 always use our support mailing list or contact “sales _AT_ sipwise.com” 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!