This page has been visited 7628 times.

OpenSIPS Control Panel

The new OpenSIPS 2.1 goes hand in hand with the new OpenSIPS Control Panel 6.1, the Web Control Panel Application intended for both system and user provisioning. The new version provides full integration with OpenSIPS using the new MI_JSON and MI_XMLRPC_NG interfaces and it is also backwards compatible with the old MI mechanisms. The last OpenSIPS CP version also comes with significant improvements on the front-end side.

Download and install now the new OpenSIPS Control Panel 6.1 from SourceForge:

    https://sourceforge.net/projects/opensips-cp

Greetings

Greetings from the OpenSIPS team :)

http://opensips.org/images/team/opensips-team-800x450.jpg

• message body and header compression

Bye, bye I/O blocking !! Now you can run DB queries, REST queries or external scripts without the blocking penalty ! The OpenSIPS config file allows you to use certain functions in an async way (via a dedicated statement). Suspending and resuming are done at script level. A detailed description of how the async support works in 2.1 is available here:

Bye, bye I/O blocking !! Now you can run DB queries, REST queries or external scripts without the blocking penalty ! The OpenSIPS config file allows you to use certain functions in an async way (via a dedicated statement). Suspending and resuming is done at script level. A detailed description of how the async support works in 2.1 is available here:

OpenSIPS 2.1 is a major release which brings radical changes and enhancements in OpenSIPS.

For more details, read the full description of what is new in the OpenSIPS 2.1 release and the tutorial on how to migrate your script to OpenSIPS 2.1.

\\

    http://www.opensips.org/Documentation/Tutorials-FraudDetection-2-1

When was the last time when your users were hijacked and scammed? We know for sure when it will be the last time - NOW! For those of you familiar with the major problem in the VoIP world, we have good news: OpenSIPS 2.1 can now detect and prevent those attacks through its fraud detection module! \\

A migration tutorial is available as well:

• avpops for DB MySQL queries

In OpenSIPS 2.1, the whole protocol stack was redesigned and re-written - from the network layer, all the way up to the SIP transport layer. The goal was to create a new protocol interface that allows developers to add new transport protocols (for SIP) in a very simple way, without being aware of how the multi-process support works in OpenSIPS, of how the I/O reactors work or of any other very low level OpenSIPS details.\\

How to configure OpenSIPS with WS support and gatewaying, see our tutorial:

    http://www.opensips.org/Documentation/Tutorials-WebSocket-2-1

About -> Available Versions -> 2.1.x Releases -> 2.1.0 Notes

Details

For more details on what is new in OpenSIPS 2.1, please see the full listing of changes and features:

    http://www.opensips.org/About/Version-2-1-0

A migration tutorial is available too:

    http://www.opensips.org/Documentation/Migration-1-11-0-to-2-1-0

About -> Available Versions -> 2.1.x Releases -> Release 2.1.0 Notes

(:toc-float Table of Content:)

OpenSIPS 2.1 is a major release which brings radical changes and enhancements in OpenSIPS.

Asynchronous Operations

Bye, bye I/O blocking !! Now you can run DB queries, REST queries or external scripts without the blocking penalty ! The OpenSIPS config file allows you to use certain functions in async way (via a dedicated statement). The suspending and resuming is done at script level. A detailed description of how the async support works in 2.1 is available here:

    http://www.opensips.org/Documentation/Script-Async-2-1

The first modules providing async functions are:

• avpops for DB queries
• exec for script execution
• rest_client for REST queries

WebSocket support

In OpenSIPS 2.1, the whole protocol stack was redesigned and re-written - from the network layer, all the way up to the SIP transport layer. The goal was to create a new protocol interface that allows developers to add new transport protocols (for SIP) in a very simple way, without being aware of how the multi-process support works in OpenSIPS, of how the I/O reactors work and any other very low level OpenSIPS details.
As a result, the websocket transport protocol for SIP was added in OpenSIPS, as a natively supported protocol (taking full advantage of OpenSIPS scalability and performance).

Fraud Detection

When was the last time when your users were hijacked and scammed? We know for sure when it will be the last time - NOW! For those of you familiar with the major problem in the VoIP world, we have good news: OpenSIPS 2.1 can now detect and prevent those attacks through it’s fraud detection module!
Fraud is a major problem nowadays and it is more complex as it depends on the end-user/end-device security level. And all the VoIP providers are looking forward for ways to protect their users and avoid the blame.
For recognizing an attack, the Fraud Detection module defines profiles. A profile is a set of five parameters that together decide when an user account is hijacked:

• Total number of calls - maximum number of incoming calls (in a given time frame) before considering the accounted hijacked
• Number of calls per minute - maximum number of CPS before considering the user account hijacked
• Number of concurrent calls - maximum number of parallel calls the user can have without being considered hijacked
• Number of sequential calls - maximum number of consecutive calls to the same destination before the user account is considered hijacked
• Call duration - maximum duration of a call before being considered a potential fraud

How to use the Fraud Detection module, see the following tutorial:

    http://www.opensips.org/html/docs/modules/2.1.x/fraud_detection.html

Compression

OpenSIPS 2.1 comes with a new module able to achieve deflate and gzip compression/decompression and also SIP message compaction.
One common issue we are facing when using SIP over UDP is message fragmentation, because there is no way to reassemble the original packet. The only way we can prevent fragmentation is to reduce the size of the message. One use case is when you have multiple OpenSIPS proxies, which internally communicate using UDP, but outside the SBCs use TCP.
You definitely do not want fragmentation, as you won’t be able to rebuild the original message when TCP will be used when it leaves the proxies. The compression module gives you the means to reduce the size of the message, by using the following features:

• message body and the header compression
• unnecessary headers removal
• header name reduction to RFC compact form (such as 'v' for 'Via'); we support a limited set of compact headers from RFC 3261 and RFC 4028 (complete list at [2])
• unnecessary attribute lines removal from the sdp body which represent default values

A comprehensive tutorial is available here:

    http://www.opensips.org/Documentation/Tutorials-Compression-2-1 

Topology Hiding

Topology hiding is usually utilized as an approach to enhance SIP network security. Since, in regular SIP traffic, critical IP address data is forwarded to other networks, the concern is that third parties can use that information in order to direct attacks at your internal SIP network.
The new topology_hiding module strips and restores the headers that contain topology information (Via, Record-Route, Route and Contact headers) , and optionally it can also change the Call-ID of the requests.
Compared to the topology hiding solution offered by the B2B modules, it has the great advantage that it can be used together with other script functionalities that were previously incompatible ( eg. dialog vars & profiles, accounting, etc.).
Compared to the previous solution of topology hiding which was integrated into the dialog module ( which only supported topology hiding for INVITE based dialogs ), the new module can work in stand-alone mode as well ( without dialog support ), thus allowing to do topology hiding for all types of dialogs ( eg. Presence dialogs ) and also for standalone initial requests ( eg. SIP MESSAGE ).

Usage tutorial is available here:

    http://www.opensips.org/Documentation/Tutorials-Topology-Hiding 

Emergency call handling

To make as emergency call using a single code (e.g.: 911 in US or 112 in Europe) has been a challenge for VOIP technology. This is a problem because a crucial information is missing: the user's location and the location is essential to route the call to the closest PSAP(call center responsible for answering emergency calls).
This has been studied by many entities, such as the IETF, who created several RFC on the topic, and the American NENA (National Emergency Number Association), who devised a solution based on the concepts of the IETF. The main elements of this solution are, LIS (Location information server ,which is the node that determines the location of the VoIP terminal), ERDB (servers that determines the area's emergency closest PSAP due this location ), VPC (servers that manage the location and routing information associated with a call) and, most importantly, the SIP PROXY that can make routing the call according to the data sent by these servers.
The OpenSIPS can be an element in this architecture acting as a SIP proxy, but need to meet the requirements of this solution. To provide this we have developed the Emergency Module, which basically makes the interface with the servers mentioned and adds the new SIP extensions that the IETF has created for this purpose. Including only two commands and some parameters in your configuration file, we enable OpenSIPS to be an important component in the solution of this problem, with great potential to meet American market or other countries that could adopt a similar architecture.

A great tutorial on using the Emergency Call module:

    http://www.opensips.org/Documentation/Tutorials-Emergency-2-1