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)

AGI and DSM madness

If you wanted to develop such voice applications in the past, you usually fired up an editor and digged deep into the Asterisk AGI or SEMS DSM docs for days even for the most simple applications, especially if you were new to these things. You needed to reconfigure Asterisk or SEMS to serve your application, change the SIP routing to use it, and develop the application using complicated syntax or APIs. To sum it up: it was difficult, time consuming and frustrating for beginners.

Tropo to the rescue

By using your SPCE platform together with Tropo, you can jump right into building your voice applications using nothing but your browser. From start to testing your first simple app, it takes less then 5 minutes. And the good thing is – you can connect to Tropo via SIP, so it’s actually free! So here’s how you do it in 8 simple steps:

1. Sign up for a free account on http://www.tropo.com

2. Create a new application:

3. Choose “Tropo Scripting”:

4. Name your application, then “create a new hosted file for this application”:

5. Choose a file name for your script, and provide your application logic. For this test, I copy/pasted an example script taken from https://www.tropo.com/docs/scripting/asking_digits.htm . Then click “Create File”:

6. Click “Create Application”:

7. Copy the SIP URI shown in “SIP Voice”, we’ll need that in the next step:

8. Finally, log into your sip:provider Admin Panel and edit the Preferences for your subscriber, in our case test@sipwise.com:

In this case, we set a simple Call-Forward-Unconditional to the SIP URI provided by Tropo, so every call to either +4312345 or sip:test@sipwise.com will end up in your voice application. You can also set a Call-Forward-Busy or No-Answer, if you like your application to kick in only in these scenarios.

Save your settings, and you’re done. Really. Test, refine and repeat.

I guess it can’t get much easier than that.

• Sipwise develops and integrates highly-available and scalable telephony systems based on open-source software (and releases lots of its software as open-source).
• Our platforms are deployed at top-tier ISPs all over Europe, serving hundreds of thousands of customers each.
• We are an extremely dedicated team with a strong professional start-up culture, aiming to reshape the telecommunication market.

About the Job

• You will heavily extend our provisioning and monitoring systems and make the changes visible via the administrative and customer self-care panels, as well as the SOAP and XMLRPC interfaces.
• Analyze and optimize the usability of the web interfaces.
• Review and improve database access and performance metrics.
• Work closely with Sipwise developers and people in the open-source community to enhance system maintenance work-flows.
• Keep track of leading edge technologies and approaches to improve management of the Sipwise platforms.
• Write maintainable configurations and code with extensive test coverage in a professional engineering environment using version control (GIT/SVN) and following staged packaging, installation and release cycles.
• Troubleshoot and fix customer issues in various deployments.

Requirements

• A minimum of 5 years of experience developing object oriented Perl and web applications under Linux/UNIX systems.
• Fluent with SQL databases, HTML, CSS, Javascript and software design patterns.
• A strong background in computer science. You understand the fundamentals of networking and operating systems.
• Love to make an impact in collaborative and enthusiastic teams.
• Strong communication skills in spoken and written form, English and a second language.

Bonus Points

• Fluent German in speaking and writing.
• You’ve worked with VoIP systems.
• You’ve contributed to open-source projects.
• Formal theoretical background (BSc., MSc., …)
• Experience with Debian GNU/Linux, MySQL, Apache, Redis, jQuery and Perl Catalyst.
• Laziness, Impatience, and Hubris.

Perks

• Competitive salary.
• Flexible work-days and office hours.
• Smartphones and Laptops.
• Biiiiiig screens. More if you need.
• Vienna, the world’s most livable city! (according to the Mercer 2010 Quality of Living Survey)

Application

Send your detailed application including your CV/resume, engineering interests and experience, and why you would like to work with Sipwise to: office@sipwise.com

Please use PDF and/or Open Document Formats for your documents. Sipwise does not accept recruitment agency resumes. Please send your applications only to the contact address specified above. Sipwise is not responsible for any direct or indirect fees related to submitted applications.

• Sipwise develops and integrates highly-available and scalable telephony systems based on open-source software (and releases lots of its software as open-source).
• Our platforms are deployed at top-tier ISPs all over Europe, serving hundreds of thousands of customers each.
• We are an extremely dedicated team with a strong professional start-up culture, aiming to reshape the telecommunication market.

About the Job

• You will implement efficient and secure call routing features, leveraging technologies like IPv6 and TLS.
• Optimize mechanisms against fraud and DOS attacks on SIP level.
• Make calls flow in large-scale systems over geographically distributed components.
• Work closely with Sipwise developers and people in the open-source community to build new features and optimize existing onces.
• Keep track of leading edge technologies and approaches to improve the Sipwise platforms.
• Write maintainable configurations and code with extensive test coverage in a professional engineering environment using version control (GIT/SVN) and following staged packaging, installation and release cycles.
• Troubleshoot and fix customer issues in various deployments.
• Think out the box, meet with others at conferences both nationally and internationally.

Requirements

• A minimum of 5 years of experience building and maintaining VoIP deployments.
• A strong foundation in telecommunications and computer science. You understand the fundamentals of both packet-switched and circuit-switched networks and you are familiar with the concepts of operating systems.
• Obsessed about large scale VoIP platforms, both on boxed systems as well as cloud environments.
• Fluent in SIP, RTP, T.38 with a deep understanding of Kamailio and complementary SIP systems like Asterisk and SEMS.
• Love to make an impact in collaborative and enthusiastic teams.
• Strong communication skills in spoken and written form, English and a second language.

Bonus Points

• Fluent German in speaking and writing.
• You’ve built large-scale VoIP systems.
• You’ve contributed to open-source VoIP projects.
• You’re familiar with the Sipwise sip:provider CE platform.
• Formal theoretical background (BSc., MSc., …)

Perks

• Competitive salary.
• Flexible work-days and office hours.
• Smartphones and Laptops.
• Biiiiiig screens. More if you need.
• Vienna, the world’s most livable city! (according to the Mercer 2010 Quality of Living Survey)

Application

Send your detailed application including your CV/resume, engineering interests and experience, and why you would like to work with Sipwise to: office@sipwise.com

Please use PDF and/or Open Document Formats for your documents. Sipwise does not accept recruitment agency resumes. Please send your applications only to the contact address specified above. Sipwise is not responsible for any direct or indirect fees related to submitted applications.

Daniel-Constantin Mierla of Asipto, co-founder Kamailio Project, says:

“Asipto and Sipwise were successful partners in the past years, building strong confidence between us. Our successful collaboration was not limited to the business side only, as Sipwise is a relevant contributor to the Open Source Kamailio project. Having a strong background in research, Asipto’s lines of products focused a lot on novelty in communications. The evolution of the market demands it more than ever and we will continue to do that. In order to accommodate the SLA requirements for operators and be able to professionally handle the increased demand for Kamailio based solutions, the new joint venture with Sipwise is the perfect option.

As a long time Open Source advocate, I am glad that we can offer a free version of our newly branded product: the sip:provider Community Edition. Small and medium sized operators can start their voice services without any commercial constraints. With my new role as Director of Innovations at Sipwise, I am eager to launch the next release of sip:provider CE and Pro in the near future, to include features such as secure communication over TLS, IPv6, rich presence services and IMS extensions.”

Atilla Ceylan, co-founder and CMO of Sipwise:

“Decisions involving the core of a carrier’s network are not made every day, and service providers are placing their confidence in Sipwise’s vision and capabilities to provide them with industry-leading solutions today and over the years to come. Sipwise is currently engaged in projects with Europe’s leading cable operators supporting the conversion of their MGCP based voice infrastructure to a more flexible, more reliable and more economic SIP based Class 5 softswitch platform.

The Joint Venture with Asipto improves our business model and the business case for shifting investment from legacy equipment to now even more compelling next generation solutions from Sipwise. As operators select the partners who will usher them into the future very carefully, I believe that the joint approach of Asipto and Sipwise will provide the best choice by leading the change in voice infrastructure solutions based on Open Source for the new public networks.

The launch of our first jointly developed products – the sip:provider CE and PRO – have been architected with the global market in mind. With operators around the world embracing the transition to reliable, scalable and affordable solutions, our platforms dramatically lower the cost structure and enable the delivery of enhanced services that provide a competitive advantage.”

Based in Berlin, Asipto is led by co-founders and core developers of Kamailio SIP Server project (former OpenSER). The team built around Daniel-Constantin Mierla and Elena-Ramona Modroiu worked with SIP-based telephony since the early times of this protocol. They designed and deployed unified communication solutions for large VoIP providers around the world, with the core of the systems being the Open Source SIP server Kamailio.

Sipwise, a system development and integration company located in Vienna, builds IP telephony appliances based on Open Source technologies, using Kamailio as the core SIP routing engine. Targeting residential, mobile and carrier services, Sipwise products are deployed at operators world-wide, accompanied with long term support and professional SLAs.

Existing customers of Asipto and Sipwise, as well as related projects, will not be directly affected by the merge, existing contracts and collaboration will continue unchanged. The new telephony products will be developed and commercialized under the Sipwise brand. The Asipto brand will continue with a focus on services like trainings, development and consultancy for Kamailio and cutting-edge SIP services. The new venture will operate in both locations Berlin and Vienna – whenever you come around, let us know and we will be happy to meet and show you our latest products and services.

Contact:

Asipto

Elena-Ramona Modroiu
Phone: +49 30 21480730
Web: http://www.asipto.com
Email: office@asipto.com

Sipwise

Atilla Ceylan
Phone: +43 1 2521522
Web: http://www.sipwise.com
Email: office@sipwise.com