sip:provider CE v2.4 Released

12 months after the initial release of version 2.1 and 7 months after release of version 2.2, I am happy to announce sip:provider^CE v2.4! This is mainly a feature-release, no fundamental architectural changes have been made.

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.