Sip:provider CE v2.2-rc1 Is Now Available!
Sipwise Sip:provider CE v2.2-rc1 has been released!
After over 4 months of development, we proudly present you the official Release Candidate 1 of sip:providerCE v2.2 or the Sip:provider CE v2.2-rc1!
Based on the feedback from our awesome Community and Customers, and aligned to our long-term Road Map, we’ve implemented some fundamental changes in 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 Sip:provider CE v2.2-rc1 (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 a per-subscriber basis. See Chapter 220.127.116.11 of the SPCE Handbook.
- The SPCE can now also register at SIP peer hosts. See Chapter 18.104.22.168 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.
- 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.