Christian worked as Operations Engineer at Sipwise, after building fantastic products with open source VoIP components at an Austrian ISP over the last years. I will always remember him as an extremely helpful and kind soul.

Our deepest condolences go out to Christian’s family and loved ones during this time. We will miss him as a colleague and friend.

Anyways, if a customer uses your VoIP service (especially if it’s a paid service), it just needs to work, and if not, you better pin down the error cause as soon as possible and provide a solution to the customer, otherwise she’ll turn away from you quite quickly.

The poor man’s approach

In the past, VoIP troubleshooting went somewhere along this line (we’ve been there and done that):

• Ask the customer when approximately she did the failed call or failed to register her phone
• Grep the (hopefully extensive) log files for hints pointing to the error
• If nothing obvious comes up there, start a tcpdump on the system and ask the customer to try the call again
• Copy the resulting trace to your local machine and try to extract the relevant packages from a potentially HUGE trace
• Analyze the call, take your actions, and if necessary repeat the process

This approach has some obvious flaws. First, your support agent needs access directly on the system and the proper rights to start a trace.

It is also quite time consuming and probably doesn’t draw a professional picture if you need to ask your customer for some action in order for you to find the problem. It’s also a heavily manual process, requires quite some technical expertise to pull off, and if the support agent needs to escalate the issue to 2nd Level Support, it involves uploading SIP traces to somewhere, or even worse, sending them back and forth by email.

External Monitoring Tools to the rescue!

Due to the huge overhead of the traditional troubleshooting approach, a whole new ecosystem around external SIP monitoring and analysis. New start-ups were created to tackle these issues, and established network monitoring vendors pushed into the market, providing traffic analyzer solutions to ease the pain of VoIP support. The problem for small VoIP operators is that these solutions can be horrendously expensive. In the telephony industry, licensing models are broken down to a per-line or per-subscriber price, and it’s not uncommon that the line price of the analyzer tools exceed the line price of the VoIP soft-switch, which is just unfeasible.

However, since open source projects increasingly get their feet into the VoIP market, it’s quite natural that also open source VoIP monitoring and troubleshooting tools start to appear. The most promising project in the open source landscape is Homer, an open source SIP capturing server. Since it can passively wiretap traffic on mirrored switch ports, it integrates nicely into a VoIP network environment without interfering with existing networking elements.

Using such tools, the support process changes significantly, because all SIP packets are constantly captured on the network and can be filtered and viewed on web interfaces. Most of them, like Homer, also visually present the call flows of the SIP packets, so it gets very easy to spot issues between the involved hops.

Instead of having to involve the customer into the troubleshooting process, it becomes something like this:

• Filter for calls or registrations of the respective customer
• Visually check the call flows and packets for obvious issues
• If necessary, grep the logs for specific calls
• Take actions and repeat the process if necessary

If more people need to be involved into the troubleshooting process, just the link to the call flow in question needs to be shared.

However, the problem with such tools is that they can only provide an external view of a VoIP system, because in most of the cases it’s not possible to hook into the internal communication of a VoIP soft-switch. For example the Sipwise sip:provider appliances consist of several SIP elements communicating with each other on the local interface, and this traffic can’t be captured without “opening up” the soft-switch and install additional software onto it, which might either be impossible at all, or might void any warranties provided by the vendor.

The Sipwise Approach

To get a complete view of the SIP packet flows also inside of the VoIP system, we have integrated a first version of our own SIP monitoring and troubleshooting system into the upcoming version 2.6 of the sip:provider^PRO platform. It provides deep insights into past and current call flows by lining out a break-down of SIP requests and responses, as well as visual call graphs and packet details. The advantage to external solutions is that it integrates tightly into the existing Administrative Interface.

An overview of the amount and distribution of various requests and responses gives you great hints for failure predictions. We’re working hard to also implement trending and predictions of issues, so countermeasures can be taken in a pro-active approach before complains start hitting your support team.

To troubleshoot customer issues, all call scenarios are listed directly in the subscriber view, so you don’t have to search for calls belonging to specific customers:

Each call scenario provides a dynamically rendered graphical representation of the call flow, so you can easily spot any issues in the call routing directly on a network level:

The call scenario is clickable, so you can easily dig into the details of a specific packet:

For further analysis, you can also download the raw SIP trace in PCAP format.

What’s next?

We’ve learned that it is extremely important to provide a very simple way to get an overview of what is going on at any given moment directly on a networking level, because log files don’t always provide all the information needed to troubleshoot an issue. It is crucial to be able to analyze calls which happened in the past, so you don’t have to bother a customer with any actions during the troubleshooting process.

One major task to tackle is also to counteract on arising issues before they pile up, and most importantly before customers get affected. Our focus will be to extend the described tools to predict issues where possible, so you’ll be able to react before problems escalate.

What’s the sip:provider platform?

The Sipwise sip:provider platform is a highly versatile open source based VoIP soft-switch for ISPs and ITSPs to serve large numbers of SIP subscribers. It leverages existing building blocks like Kamailio, Sems and Asterisk to create a feature-rich and highly performant system by glueing them together in a best-practice approach and implementing missing pieces on top of it. Sipwise engineers have been working with Asterisk and Kamailio (and its predecessors SER and OpenSER) since 2004, and have roles on the management board of Kamailio and are contributing to these projects both in terms of patches and also financially by sponsoring development tasks. The sip:provider platform is available as a Community Edition (SPCE), which is fully free and open source, and as a commercial PRO appliance shipped turn-key in a high availability setup.

The SPCE can provide secure and feature-rich voice and video communication to end customers and connect them to other SIP-, Mobile- or traditional PSTN-networks. It can also act as a Session Border Controller in front of existing VoIP services in order to enable signaling encryption, IPv6 support, fraud- and Denial-of-Service prevention. Another use-case is to act as a SIP concentrator to bundle multiple SIP peerings for other VoIP services.

What’s new in v2.5?

There are a whole lot of new features, improvements and fixes since v2.4, here is an overview of the most important ones:

• Subscriber Features:
• Video Calls: The SPCE now supports video calls, optionally encrypted end-to-end with ZRTP by using a proper SIP client like Jitsi.
• Time Based Call Forwards: You can define complex time period definitions to trigger call forwards, e.g. for call deflections outside of office hours.
• Serial Call Hunting: This feature allows you to create serial hunt groups, e.g. to ring your land-line for 10sec, then ring your mobile phone for 30sec, and finally route the call to your voicebox if those targets haven’t picked up the call.
• Permanent Location Entries: If your device (e.g. a Cisco CallManager Express) can’t register on the platform, you can manually define a permanent registration entry via the Admin Panel.
• Billing Features:
• Fraud Detection: Post-Paid Subscribers can automatically get locked for outbound calls if they exceed a certain billing fee threshold during a month. You will receive regular emails with a list of affected subscribers.
• Call Initiation Time in CDRs: The initiation timestamp of calls is now stored along with the connect timestamp, so you can fetch the call establishment duration from CDRs.
• Network Features:
• IPv6 Support: The SPCE now supports IPv6 both for subscribers and for peerings. It also supports transparent bridging between IPv4 and IPv6 networks and vice versa, both for signaling and for media sessions.
• Internal Enhancements:
• Stateless Load-Balancer: The load-balancer has been reworked to operate completely stateless. This change squeezes out even more performance of the system while at the same time reducing the memory foot-print.
• Strict Rewrite-Rule Checks: When adding rewrite rules to the system, these rules are strictly checked for syntactic and semantic errors before being saved to the DB in order to prevent the proxy from refusing to come up on restarts due to regex errors.
• Rolling Release Support for DB Schema: All DB Schema changes are now versioned in a separate table, which allows for rolling releases from any past version to the latest one. This is also the first step towards a bleeding-edge trunk version where you can test the latest features without having to wait for stable releases.
• Optimized I/O Scheduler: Due to the heavy I/O operations for DB access and logging under high load, the I/O scheduler of the kernel has been changed to deadline to increase the throughput.

How do I test-drive the new version?

As usual, we’re providing both a VMWare Image and a Virtualbox Image for quick evaluation testing. Check the relevant section in the Handbook for detailed instructions.

How do I install the new version or upgrade from an older one?

For new users, please follow the Installation Instructions in the Handbook to set up the SPCE v2.5 from scratch.

For users of the SPCE v2.4, please follow the upgrade procedure outlined in the Handbook. If you happen to still run v2.2, please upgrade to v2.4 first by following the procedure in the v2.4 Handbook. If you have customized your configurations using customtt.tt2 files, you must migrate your changes to the new configuration files (especially the proxy- and lb-configuration) after the upgrade, otherwise all your calls will most certainly fail.

Acknowledgements

I really would like to thank our PRO customers and the SPCE community for their feedback, bug reports and feature suggestions to make this release happen. I hope you enjoy using the v2.5 release and keep your input coming. A big thank you also to all the developers of Kamailio and SEMS, who make it possible for us to provide an innovative and future-proof SIP engine as the core of our platform!

• Part 1, which is provided in this post, gives you an introduction in how VoIP works.
• Part 2 shows how you can set up a full-blown VoIP system for free using the sip:provider Platform within 30 minutes.
• Part 3 describes how you can operate a whole-sale business with the sip:provider Platform.
• Part 4 is dedicated to the sip:provider Platform acting as an SBC in front of existing VoIP systems.
• Part 5 shows how to enable Over-The-Top (OTT) services using Apple and Google Push Notification Services.

Introduction

VoIP Systems are seen as complex communication infrastructures even from a high level perspective, but they’re not. Well, VoIP is in fact complex in its details, but it has been abstracted by various projects in order to make it really straight-forward to use it, so it’s easy to start a compelling voice/video communication system or service (which I’ll name “VoIP system” or “VoIP service” throughout the document) from scratch, but it’s important to learn a few facts about it in order to choose the right base system for successfully running a VoIP service.

The Basics

VoIP just means “Voice over IP”, which is a generic term for transporting real-time voice sessions over the Internet. However, it doesn’t define HOW this is done, and even the term “Voice” is a bit misleading, because with the very same concept, you can transport also Video and Fax over an IP connection.

There are a couple of elements involved when you’re talking about a VoIP system:

To sum it up, there are SIP Endpoints, which are the client instances of your customers. These could be software installed on your customer’s computers (popular software is Jitsi, an open source and cross-platform communications client, or Bria, a commercial multi-platform client for Windows, iOS and Android). Other possibilities are SIP phones like SNOM phones or Polycom Phones.

Beside the customer facing end points, there are SIP gateways which translate VoIP into traditional fixed-net and mobile networks. They pretty much act like customer facing clients, but usually are able to handle multiples of parallel calls. They are usually connected via multiple ISDN E1 or T1 lines, and sometimes an SS7 control layer is used on top.

How does SIP work?

In order to establish a communication session, you need a signaling protocol, which tells the involved parties who wants to communicate with whom, and which media capabilities might be used (e.g. plain voice, voice/video, fax etc.). There are several protocols out there, like Skype (a proprietary protocol) and H.323 (more or less obsolete since 2004) and the most important and nowadays most wide-spread one and the one we’re concentrating here: SIP, the Session Initiation Protocol.

SIP Registrations

A very important part of VoIP is the registration of customer endpoints. It means if a customer starts its SIP client, the client tells the SIP server at which IP and port it is reachable in case there’s a call towards this customer. The call flow looks like this:

The important part, beside the authentication scenario which is a http digest authentication, is the Contact header, which indicates at which IP:port the customer is reachable.

So during start-up, the client tells the server the contact address it’s reachable for subsequent calls.

But what about real Phone Numbers?

Ok, so we learned that alice@example.com can contact bob@example.com if bob@example.com registered up-front (telling the SIP service provider at which IP:port he’s reachable), and vice versa. But what about real phone numbers?

In order to receive calls from the PSTN (public switched telephony network), your SIP service provider needs to map a PSTN number to your SIP URI, e.g. he needs to know that alice@example.com is an equivalent to for example +43 1 1001. If somebody calls 4311001 in the PSTN, it’s routed through the telephony network down to your service provider, which holds ownership of that number. The service provider is now responsible to translate the number to a corresponding SIP-URI, and then route the call to the IP:port where this user is registered.

How about a Video Stream?

The important thing here is that any media stream in SIP signalling is negotiated end-to-end. This means that if alice@example.com calls bob@example.com, alice proposes a list of media sessions (e.g. audio with a specific list of codecs, and video with a specific list of other codecs), and bob compares this list with its own capabilities and then replies with a (potential) sub-set of the offer from alice. So if alice proposes an audio and video call, but bob doesn’t have a web-cam, he’ll reply with a sub-set of alice’s offer, which only contains the audio-part. However, if bob has a web-cam, we’ll reply with an according answer telling alice that both audio and video streams are available.

Conclusion

If you want to work with “VoIP”, you most likely will work with the SIP Protocol. SIP will allow you to do two-way, end-to-end communication, but you’ll need SIP clients to attach to a system like this. Do you need do pay for an external service in order to start a VoIP system? No!

What’s next?

The next post will describe how you can use the open source Sipwise sip:provider CE to build a VoIP system from scratch within an hour. It’ll show how you can create a Skype-like service within your network using IPv4, IPv6, TLS and SRTP.

Follow us at Twitter and Facebook for updates and new posts.

Who are we?

Sipwise develops carrier-grade VoIP platforms and integrates them into existing ISP/ITSP landscapes. The company was founded in 2008 by Andreas Granig, Daniel Tiefnig and Atilla Ceylan and has been boot-strapped since then to a highly skilled team of 10 people. With our open-source based communications platform based on SIP (the Session Initiation Protocol), we’ve aquired top-tier customers all around the world (e.g. UPC Broadband and its US-based mother company Liberty Global, one of the largest cable-operators world-wide, amongst others), where we managed to replace Cisco-, Nortel- and Siemens-Systems with our Sipwise NGCP (Next Generation Communication Platform).

Open Source, you said?

The telco landscape consists of two parts. One is big incumbents deploying IMS solutions (e.g. mobile operators and former state-owend ISPs), who insist on dictating what their customers can do and what they can’t. This approach resulted in the “walled garden” scenarios where they have full control over you as a customer, and where you have to pay a premium to break out of their networks (roaming, data roaming, SMS costs).

The other part is alternative ISPs/ITSPs, who build their systems from scratch using open standards based on SIP. The usual approach here is to take available open source building blocks and create their own solutions from scratch. The problem with this approach is that the same work is done over and over again, resulting in low-quality systems, because SIP is not an easy protocol and the same mistakes are being made again and again. Beside that, there are many missing building blocks like proper provisioning and billing of customers.

This is where Sipwise jumps in and provides a free and open source solution, putting together the proper building blocks which already exist, glue them together in a best-practice approach and providing the missing parts to offer an end-to-end solution. We are also heavy contributors to the open source projects we use, both on the side of code contribution and management as well as on the financial side by sponsoring certain development tasks (e.g. Kamailio and Sems). The result of that is the sip:provider CE (Community Edition), which is an easy-to-install and fully-fledged VoIP soft-switch covering all the requirements for alternative ISPs/ITSPs.

How do you make money on Open Source?

Getting started with a VoIP service is easy, but scaling is hard. Often times, people start off with an MVP (minimum viable product), which is fine. Once they get off the ground with it, they realize that the initial technology they used is not appropriate to scale. In VoIP deployments, people often start out with Asterisk, which is actually a PBX, and it’s not built to serve >1000 subscribers. This is where our Sipwise sip:provider CE comes in, which allows to scale up to 50k subscribers. Once you reach a level like this, you might also start to think about high-availability.

The CE doesn’t provide that feature, but the sip:provider PRO does. The PRO is a highly available, turn-key VoIP platform, which comes on two 1U servers, optimized for high performance and availability, guaranteeing a maximum of 50k subscribers or 2000 parallel calls. It’s a commercial upgrade, where we offer a seamless migration from an existing CE. Beside the HA feature, the PRO also comes with a prepaid billing engine and fax2mail/webfax features, beside monitoring capabilities. One of the main advantages with the PRO though is that we provide 24/7 support on the platform, so you can lay back and let our engineers do the troubleshooting if something goes wrong.

Once you’ve reached 50k subscribers, we’ll offer you the sip:carrier, a highly scalable platform on top of the PRO. It’s an IBM BladeCenter, which contains up to 5 PRO instances (2×5 servers), and a middle-ware to shard your subscribers dynamically over those instances. This covers at least 250k subscribers, and if you go over that number, we offer ways to scale that arbitrarily.

So where is this venture going to?

Sipwise is currently serving small-, medium- and high-tier ISPs all around the world. What we want to do is focussing more on the US market, where we’re currently developing modules to replace Centrex deployments by state-of-the-art cloud-based PBX solutions. Beside that, we’re targeting all the self-made solutions which suffer the scaling pain to move to the free CE solution and upgrade from there to the PRO or Carrier.

Are you hiring?

Hell yeah, we do! If you’ve a good background in network engineering or in systems engineering, we’d love to hear from you at! Send me an email to agranig@sipwise.com to get in touch with us!

What about your current Investors?

We’ve looked carefully at which investors suit us best, and finally went with Speedinvest and Tecnet Equity.

Speedinvest is a private VC with experienced entrepreneurs, having hands-on knowledge in the mobile and internet industry. Members of their team have had large fund-raising events and successful exits by themselves, so they know what they’re talking about. They are backed by a number of “Super Angels” from Austria with a focus on Co-Entrepreneurship and Hands-On-Support.

Tecnet Equity is a funding group tied to the government of Lower Austria, which has decided to pay particular attention to technology-oriented high-growth companies with a need for funding in the early stages of development.

Interested in our technology?

If you want to quickly try out our solution, download the installer or a pre-installed virtual machine image as described in the handbook.

For any additional questions, we’re happy to answer them either on the mailing list or directly by our sales team at sales@sipwise.com.

What’s new in v2.4?

Here is an overview of the most important changes since v2.2:

• Security
• SIP over TLS for subscribers is now supported out-of-the-box and can be enabled in config.yml
• You can white-list IP addresses in the Denial-of-Service check in config.yml using the dos_whitelisted_ips option.
• Billing
• Call duration is now calculated in milliseconds granularity to comply with requirements of certain countries (e.g. Germany).
• External account and subscriber-contract IDs can be set during provisioning (using External ID when creating an account or subscriber), which will be passed through to the CDRs. That way, external billing systems can identify users more easily.
• The CDR file-format has been changed to version 003 to reflect the new schema. Don’t forget to upgrade your parsers if necessary.
• Unrated CDRs can now be exported if the rating engine is disabled in the config.yml.
• Dialplan Manipulation
• In previous versions, each domain and peer had its own Rewrite Rule Set. This has been changed in a way that Rewrite Rules can now be defined on a global level (e.g. System Administration → Rewrite Rule Sets in the administrative web panel) and can be assigned to domains, peers and subscribers via their Preference settings. With this enhancement, Rewrite Rule Sets can be re-used for domains and/or peers using the same number format, and you can define separate dialplans down to single subscribers.
• Since Call-Forward destinations are stored in format +<E.164-number> internally, in previous releases you had to define an Inbound Rewrite Rule For Callee stripping the leading +. The routing behavior has been changed so that on one hand, rewrite rules are not executed again for call-forwards, and leading + is implicitely stripped instead.
• You can use the variables ${caller_cc} and ${caller_ac} in the replacement part to dynamically fill in the country-code and area-code of subscribers during routing-time.
• CLI Handling for Business Customers and PBX Subscribers
• The user-provided number (UPN) and network-provided number (NPN) handling has been improved. Using the allowed_clis preference, patterns can be provided to match against CLIs sent by the calling party (e.g. in From-User, Display-Name, P-Preferred-Identity etc). This information is used as UPN in the From-header when delivering the call. The number provided in the cli preference is used as NPN, passed on in the P-Asserted-Identity. The user_cli preference can be used to provide a UPN, overriding the one coming from a called party.
• You can set multiple E.164 numbers per subscriber using the Alias Numbers. For inbound calls, these numbers are mapped to the same subscriber. For outbound calls, you need to set the allowed_clis preference mentioned above to allow screening of these numbers.
• SBC Functionality
• Using the preferences peer_auth_<user|pass|realm|register>, you can register subscribers of the sip:provider^CE to a 3rd party soft-switch. The CE will register itself on the external soft-switch in behalf of the subscriber using the peer_auth_* information, so calls to this user will end up on the CE. They are then mapped to the local subscriber and being sent to devices registered at the CE. For calls towards the external soft-switch, the peer_auth_* information is used to authenticate the call in behalf of the subscriber. Using this feature, you can for example give subscriber credentials of the CE to end-customers, while keeping the credentials of the external soft-switch secret for various reasons. If your external soft-switch charges you licensing fees per parallel registration, you can also use this feature to reduce costs if multiple devices are registered per subscriber (parallel ringing).
• Letting the CE act as an SBC in front of a third-party soft-switch the way outlined above, you can do TLS-to-UDP translation for legacy soft-switches only supporting UDP.
• Due to the internal DoS/DDoS attack protection introduced in v2.2, the CE can protect third-party soft-switches from this kind of attacks by silently dropping requests.
• The B2BUA component of the CE enables the Session-Timer feature to prevent billing fraud, and it performs codec and SIP header filtering.
• SIP/Media Routing Features
• Using the allow_non_numeric_to_pstn option in the config.yml file, you can now allow non-numeric destinations to peers, e.g. if you do true SIP peerings with alphanumeric usernames.
• If NAT is detected, the CE engages the internal media relay to force any media traffic over the platform. Using the <always|never>_use_rtpproxy preferences for peers, domains and subscribers, you can force to either always or never engage the media relay, regardless of NAT.
• Using the concurrent_max and concurrent_max_out preferences, you can limit the number of simultaneous calls per subscriber, domain (which is then a default value for subscribers within this domain) and peers.
• Interfaces
• The SOAP/XML-RPC interface has been completed with a few more functions and now provides access to the complete feature set of the platform.
• The CSC web interface is now available in English, Spanish, French and German.
• The administrative web interface is now completely displayed in the new design.
• Various Improvements and Bugfixes
• The documentation has been extended to give an overview of the platform architecture.
• Issues reported by Community or Pro users have been solved successfully.

How do I get it?

For new users, please follow the instructions in the SPCE Handbook for an initial installation.

Users of the SPCE v2.2 please follow the Upgrade Procedure outlined in the updated SPCE Handbook. If you’ve customized your installation (especially when it comes to adding new user preferences to the database), you’re adviced to revert these changes before the upgrade in order to not conflict with new preferences introduced by the CE. During the upgrade procedure, you might experience short down-times of the service due to restarts of various processes.

What happend to v2.3?

The mindful SPCE user might now wonder what happend to sip:provider^CE v2.3? Don’t worry, you didn’t miss anything. We’ve done an internal v2.3 release in early autumn when deploying our new internal release framework (more on that in later posts), and for this v2.4 release, there are upgrade scripts available for a smooth migration directly from v2.2 to v2.4.

What’s new?

For the list of fundamental changes since v2.1, please read the v2.2-rc1 announcement linked above. Since v2.2-rc1, we only fixed bugs and improved the general handling of the SPCE:

• Sponsored development of and integrated qop handling in SEMS to improve SIP peering authentication.
• Improved far-end NAT traversal for more exotic scenarios.
• Masked private contact header to prevent far-end NAT traversal at other end of SIP peerings.
• Added out-of-the-box support for installations on Amazon EC2 nodes for both signaling and media (more on this in a separate post).
• Added syntax check in admin panel for rewrite rules.
• Fixed bug in admin panel when manipulating peering rewrite rules.
• Fixed bug in SIP peering handling to correctly hop via the load-balancer for outbound calls.

How to install?

For new users and v2.1 users, please follow the quick-install procedure to get up and running.

If you’re already running v2.2-rc1, upgrade to v2.2 like this (it will change your v2.2-rc1 repo to the 2.2 repo and install the new packages):

perl -pi -e 's,(spce/2\.2)\-rc1,\1,' /etc/apt/sources.list
apt-get update
apt-get upgrade
ngcpcfg apply


Do NOT upgrade your v2.1 installation like this, since it will break your setup! Use the migration procedure described in the quick-install guide instead.

Contributions

Thanks to our awesome community on our mailing list for their valuable feedback, which helped us to shape the road-map for v2.2 and tracked down the issues in v2.2-rc1.

Special thanks go out to Michael Prokop, Daniel Mierla, Stefan Sayer, Sebastien Lesimple and Carsten Bock for contributing in terms of features, language packs, bug reports and spreading the word.

Over the last days, I was working on deploying and testing our open-source VoIP soft-switch SPCE v2.2-rc1 on an Amazon EC2 instance in order to provide a ready-to-run AMI for our community.

Coincidently, I came across this tweet from @martingeddes:

When you hear a vendor selling you “cloud”, remember what they really have on offer is “fog”.

The funny thing is that although I was just managing to get our SPCE to work on “the cloud” (and mind you, I was pretty enthusiastic about it), the tweet finally expressed in one sentence the ambivalence I have with it for quite some time now.

What’s the fuzz about “Cloud Telephony”?

Cloud Telephony is a pretty hot topic at the moment in the web development world. It started with ribbit a couple of years ago (and it took me like 3 years to “get” what they were doing) and got a lot of attraction with the emerge of Twilio and Tropo. Telephony was considered quite a boring topic (who really cared about integrating a java applet on a web site?) until various APIs provided really easy access to telephony features.

So with all this asynchronous access to telephony APIs, a whole lot of telephony applications, tightly integrated into web sites, pop up everywhere on the Internet. It’s really becoming a whole new ecosystem. Remember that you were able to do the same thing with Asterisk over 5 years ago? Admittedly it’s much easier now.

But honestly, do you really know what’s going on behind the scene when you issue a request to call somebody?

How traditional ITSPs operate

If you’re looking for broadband offerings, you most likely get a triple-play bundle (Internet, Telephony, Mobile or IPTV). Usually, all ISPs except incumbents offer telephony via IP, even if you don’t know it. They lease the last mile from the incumbent (DSL) or have their own access networks (Cable, WiMax, WiFi), and telephony is just another service on top of their IP network. Most routers, EMTAs, modems etc. provide a phone jack, so you can just reuse your old phone. >90% of residential customers don’t care about the underlying technology, they just want to use their phones. And that’s fine.

But do you know what it takes for a telephony switch vendor to get deployed at an ITSP to route those calls? Telephony networks (for a good reason) are still renown to operate at 5-9, which means an availability of 99.999% per year. Yeah, that’s around five and a half minutes of downtime. Per year. And that’s also fine, since you don’t want to choke on something while waiting for your ITSP to get the phone service back up due to a software failure.

Now to be selected as a vendor for a serious ITSP, you’ve to disclose your whole system architecture, from the software components to the algorithms for various load balancing and fail-over mechanisms down to the hardware being used. The point here is that a buyer can evaluate how good or bad, compared to its competitors, a telephony vendor’s platform is designed.

How does this apply to the Cloud?

When you, as a vendor, offer services like “Cloud Telephony”, then you’ve control over your own software. The good thing here is (e.g. with Amazon EC2) that you can scale out horizontally quite quickly when it comes to hardware, because new instances are launched pretty quickly.

The bad thing is that you still need to take care of scalability on an application level. Adding more server instances doesn’t help you much if you can’t leverage them on application level. And then again, there is not much difference if you deploy your software on real hardware or in “the cloud”, because if it scales on the former, it will automatically do so on the latter. You also don’t have any detailed insight into the underlying software and hardware architecture, since you’re happily decoupled from that problem. Good for you – as long as everything runs fine.

But the most important thing is this: Your cloud fails!

For me, the whole EC2 cluster always was and still just is a convenient way to quickly launch more server instances. At some point during all this hype I was really thinking that I probably miss something, like that you’re not responsible anymore for providing active/active or active/standby services, since this is taken care of “in the cloud”. Fortunately, me (and a lot of others) always doubted that. Those who didn’t were punched into their face quite heavily by the latest Amazon outage.

So what’s the point?

The term “cloud telephony” actually says nothing at all. For example, with the SPCE running on an Amazon EC2 instance, it means you don’t have to pay up-front for the bare metal and its power and cooling costs. Not more and not less. And this applies to any other vendor or service. What if one of their processes crashes? How would the cloud help? Right, it won’t.

If you want to get a reliable service, dig deep into their architecture to find out how it works and how they operate. Just saying “we’re reliable because we use the Cloud” should raise a HUGE red flag.

So if Twilio, Tropo and Co. want to evolve from a pure “End-Customer Approach” to something like a B2B reselling model, then they should be prepared for some serious questions regarding architecture and stuff. Telling our ITSPs to use an additional external service “running in the cloud” on top of our soft-switch (which goes through lots of cycles of acceptance testing at the ITSP before being deployed to real customers) won’t impress them much, although their customers might still appreciate it.
But mind you, if it breaks, it’s the ITSP’s fault, not the fault of the 3rd party vendor. At least from the end-customers point of view.

Based on the feedback from our awesome Community and Customers, and aligned to our long-term Road Map, we’ve implemented some fundamental changes into v2.2 compared to v2.1, and we bring you some desired new features.

What’s new in v2.2?

Here is an overview of the changes between v2.1 and v2.2:

• Updated Software versions:
• The operating system for the SPCE v2.2-rc1 is Debian Squeeze (6.0).
• Kamailio is running on latest version v3.1.3 (plus two minor Sipwise patches: one info message has been reduced to debug to not log false-positive NAT ping response errors, and the PKG mem pool size has been increased to 8M to load the quite big Sipwise configuration).
• SEMS is running on latest version v1.4 (plus a Sipwise patch to reg_agent and registrar_client to properly set the Contact header to the external interface).
• New RTP Proxy:
• The standard rtpproxy has been dropped.
• The kernel-based Sipwise ngcp-mediaproxy-ng is used as media relay. We’ve decided to release this software under GPLv3 and integrate it into the SPCE. The ngcp-mediaproxy-ng is used at our Customer deployments for over 4 years now, giving you much better performance and providing automatic bridging between an arbitrary number of networks.
• We use DKMS to automatically update the ngcp-mediaproxy-ng Kernel module whenever your Kernel version changes (e.g. due to security upgrades).
• New SIP Architecture:
• There is a dedicated Kamailio instance running as load-balancer on the external interface, acting as a gatekeeper into the SPCE.
• The proxy/registrar Kamailio instance is now running on an internal address (localhost by default).
• Asterisk acting as Voicemail server and SEMS acting as Application server are now also running on the internal address for security reasons.
• For all calls, a Back-to-Back User Agent (SEMS running the sbc module) is put into the routing path to allow sophisticated call control, provide topology-hiding and to enhance SIP interoperability between different clients and also SIP peerings.
• New Peering Features
• For outbound calls to SIP peering hosts, the SPCE can perform authentication against SIP peer hosts on a per-host basis, and you can override the credentials also on per-subscriber basis. See Chapter 3.4.5.1 of the SPCE Handbook.
• The SPCE can now also register at SIP peer hosts. See Chapter 3.4.5.2 of the SPCE Handbook for instructions.
• New Security Features:
• There is a configurable protection against DoS attacks, silently blocking requests on the load-balancer for a certain amount of time if an IP (except these configured as peer hosts) reaches a threshold of SIP requests within a sampling interval.
• A protection against brute-force authentication attacks is implemented, blocking all SIP requests for a certain amount of time if a configurable number of failed authentication attempts within a sampling interval is reached.
• Only the SIP load-balancing instance is visible from the outside, protecting all internal SIP services from direct access.
• The B2BUA performs Topology Hiding to cover calling party information.
• Updated User Interfaces:
• The admin panel has been redesigned to provide a fresher look&feel.
• The priority of Peer and Domain Rewrite Rules can now be changed by simply drag&drop the rules into the appropriate positions.
• Bugfixes
• All issues reported by the Community and our Customers have successfully been solved.

How do I get it?

For new users, please follow the instructions in the SPCE Handbook for an initial installation.

Users of the SPCE v2.1 please follow the Upgrade Procedure outlined in the updated SPCE Handbook. We’ve worked hard to provide a really easy migration from v2.1. It will upgrade your Debian Lenny (5.0) to Squeeze (6.0) and switch to the new SIP routing architecture described above. Note that during the upgrade some services will be stopped, and after the upgrade you’ll be asked to reboot your server due to a necessary kernel upgrade. Thus, expect a service downtime during the upgrade (~5-15 minutes, depending on your network connection).

Is this the final v2.2 release?

This is the official Release Candidate 1 of the SPCE v2.2. We’d like to gather some feedback from the Community over the next 2 weeks, iron out any reported bugs, then do the final release.

There won’t be any new features and no changes in the APIs between this rc1 and the final release, only bug fixing if applicable.

Users of the SPCE v2.1 are kindly asked to upgrade to v2.2-rc1 and give us feedback whether you like it or not.

Andreas Granig, CTO of Sipwise, will present the sip:provider^CE v2.2 in Hall 7.2b at the Kamailio booth 112 (near to the Mozilla project) on Thursday and Friday.

You want to deploy your own Sipgate(tm) service for free in 5 minutes? Drop by and ask Andreas to demonstrate you how to do that using the sip:provider^CE, and get impressed by the capabilities of Open Source communication software carefully packed into one appliance.

We’re looking forward seeing you there, discussing with you the role of Kamailio in carrier deployments in general and in Sipwise products specifically.

Depending on the day you drop by, you can also meet the Who is Who of Open Source SIP Communications:

• Daniel-Constantin Mierla (Asipto)
• Henning Westerholt (1&1)
• Carsten Bock (ng-voice.com)
• Stefan Sayer (SEMS)
• Raphael Coeffic (Tekelec)