From openSIPS

About: Version-1-6-0

About -> Available Versions -> Version 1.6.x -> Release 1.6.0

Table of Content (hide)

  1. 1. Migration to 1.6.0
  2. 2. What is new in 1.6.0
    1. 2.1 Core
    2. 2.2 Script Routes
    3. 2.3 Pseudo variables
    4. 2.4 Transformations
    5. 2.5 AAA API and enhancement of RADIUS support(NEW)
    6. 2.6 B2BUA support (NEW)
    7. 2.7 MEMCACHED module (NEW)
    8. 2.8 DB_HTTP module (NEW)
    9. 2.9 DB_VIRTUAL module (NEW)
    10. 2.10 JSON module (NEW)
    11. 2.11 STUN server module (NEW)
    12. 2.12 ALIAS_DB module
    13. 2.13 AVPOPS module
    14. 2.14 AVP_RADIUS module
    15. 2.15 AUTH_RADIUS module
    16. 2.16 BENACHMARK module
    17. 2.17 CALL_CONTROL module
    18. 2.18 CFGUTILS module
    19. 2.19 DIALOG module
    20. 2.20 DISPATCHER module
    21. 2.21 DROUTING module
    22. 2.22 GROUP module
    23. 2.23 GROUP_RADIUS module
    24. 2.24 LOAD_BALANCER module
    25. 2.25 MI_DATAGRAM
    26. 2.26 NAT_TRAVERSAL
    27. 2.27 NATHELPER module
    28. 2.28 PERMISSIONS module
    29. 2.29 PIKE module
    30. 2.30 REGISTRAR module
    31. 2.31 TEXTOPS module
    32. 2.32 TM module
    33. 2.33 UAC module
    34. 2.34 URI_DB module
    35. 2.35 URI_RADIUS module

1.  Migration to 1.6.0

A manual for how to migrate/update from 1.5.x to 1.6.0 is now available on site.

2.  What is new in 1.6.0

2.1  Core

2.2  Script Routes

2.3  Pseudo variables

2.4  Transformations

2.5  AAA API and enhancement of RADIUS support(NEW)

AAA API

The AAA API represents a set of generic callbacks and structures needed for AAA operations.

The purpose of the API is to move all the AAA specific (Radius) implementations in a single module. The AAA API will hide the implementations details from the modules that want to use AAA support, making it easier to use.

Currently, only one module implements the AAA API - aaa_radius, offering Radius support.

Because both standardized AAA protocols, Radius and Diameter, use lists of attribute-value pairs, the API is designed based on attribute-value pairs, as well.

One of the advantages of using the API is that any module that wishes to do AAA operations does not depend on a certain protocol implementation, therefore it is not linked with a certain AAA library.

Hence, any module that was previously using Radius, for example, is not linked with the radiusclient library any more, which is obviously an advantage, especially when the module uses more than one API (DB, AAA, etc).

The AAA protocol to be used by a module is specified from the script using a so called "aaa_url" that encodes the protocol used and other useful information depending on the protocol.

The way the generic AAA API is used makes it very similar to the generic database API.

The ability to make custom Radius requests directly from the script

This feature is very useful because of its flexibility. Basically, any type of Radius queries can be yielded directly from the script, and also, Radius replies can be inspected for certain attributes.

Radius implementation for the generic AAA API

The handling of Radius AVP "SIP-AVP" (used for fetching variables from the Radius server) was integrated in this module. All SIP-AVPs are automatically and transparently handled by the module, so that this functionality is by default available for all the modules that use Radius.

Module changes

Due to the fact that the modules that were previously using Radius were ported to the generic AAA API, the following changes have been made:

2.6  B2BUA support (NEW)

A signaling B2BUA implementation has been added in OpenSIPS. It can keep the state of the dialogs, create new dialogs and control dialogs to offer some PBX specific services.

This feature is implemented in two modules: b2b_entities and b2b_logic.

The services are defined in XML documents that are parsed and applied by the b2b_logic module. It uses the basic dialog management functions offered by the b2b_entities module to command the actions needed to implement the service.

Find more here.

2.7  MEMCACHED module (NEW)

A new module that provides a new caching method using memcached servers was added. It provides a way to access memcached servers using the existing memcache API.

Advantages over the existing "localcache" module:

Find more on http://lists.opensips.org/pipermail/users/2009-July/007024.html or
http://www.opensips.org/html/docs/modules/devel/memcached.html

2.8  DB_HTTP module (NEW)

This module provides access to a database that is implemented as a HTTP server. It may be used in special cases where traversing firewalls is a problem, or where data encryption is required.

In order to use this module you must have a server that can communicate via HTTP or HTTPS with this module that follows exactly the format decribed in the specifications section.

The module can provide SSL, authentication, and all the functionalities of an opensips db as long as the server supports them ( except result_fetch).

There is a slight difference between the url of db_http and the urls of the other db modules. The url doesn't have to contain the database name. Instead, everything that is after the address is considered to be a path to the db resource, it may be missing.

Find more on http://www.opensips.org/html/docs/modules/devel/db_http.html

2.9  DB_VIRTUAL module (NEW)

The DB_VIRTUAL module allows you to create virtual DB connection on top of real connections. A virtual connection may use multiple real connection (a set), acting as a mixer layer - based on different algorithms, the DB operation pushed on the virtual DB will be pushed further to one or more real DB connections.

The DB_VIRTUAL provides failover mode (you have a master real connection and when this is down, the queries will be pushed via the next real connection from the set), parallel mode (the received query is pushed via all real connections) and round-robin mode ( the received queries are spread across the set of real connections).

The purpose of this module is to provide failover and load-balancing at DB connection level in a totally transparent way for the modules that needs DB support.

Read more on http://www.opensips.org/Main/News0035.

2.10  JSON module (NEW)

This module introduces a new type of variable that provides both serialization and de-serialization from JSON format. The Json format it is very useful as you can encode an unlimited number (and types) of info elements into a single string. For example a gateway description may contain several infos on the GW (if SST is accepted, RPID/PAI, etc), also a user profile (with all its date) can be condensed into a single string, so that DB ops are reduced to a maximum.

The variable provides ways to access objects and arrays to add,replace or delete values from the script.

The correct approach is to consider a json object as a hashtable ( you can put (key;value) pairs, and you can delete and get values by key) and a json array as an array ( you can append, delete and replace values).

Since the JSON format can have objects inside other objects you can have multiple nested hashtables or arrays and you can access these using paths.

See more on http://www.opensips.org/html/docs/modules/devel/json.html

2.11  STUN server module (NEW)

There is a new STUN server(rfc 3489) module integrated in OpenSIPS.

Why an integrated STUN server module?

In the case of a bad behaving NATs (such as symmetric NAT) only this integrated STUN server will increase the likelihood of STUN to solve the NAT traversal for a wider range of NAT implementations. This translates into less need of media relaying (for NAT traversal purposes).

Note:

Example: 

    Opensips listening for signaling traffic:
        89.89.89.12:5060
    for stun module we configure :
        primary_ip = 89.89.89.12; primary_port = 5060 - overlapping with signaling socket
        primary_ip = 89.89.89.12; alternate_port = 3478 - dedicated stun socket
        alternate_ip = 34.34.34.12; primary_port = 5060 - dedicated stun socket
        alternate_ip = 34.34.34.12; alternate_port = 3478 - dedicated stun socket

Documentation can be found here: http://www.opensips.org/html/docs/modules/devel/stun.html

2.12  ALIAS_DB module

2.13  AVPOPS module

2.14  AVP_RADIUS module

important - Removed as its functionality is now part of the AAA_RADIUS module - see the AAA API and module changes.

2.15  AUTH_RADIUS module

important - Renamed as AUTH_AAA module - see the AAA API and module changes.

2.16  BENACHMARK module

2.17  CALL_CONTROL module

modparam("call_control", "init", "call-id=$ci to=$tu from=$fu 
			authruri=$du another_field = $avp(i:10)")

2.18  CFGUTILS module

2.19  DIALOG module

2.20  DISPATCHER module

2.21  DROUTING module

2.22  GROUP module

2.23  GROUP_RADIUS module

important - Removed as merged into GROUP module - see the AAA API and module changes.

2.24  LOAD_BALANCER module

2.25  MI_DATAGRAM

2.26  NAT_TRAVERSAL

2.27  NATHELPER module

2.28  PERMISSIONS module

2.29  PIKE module

New extensions on the pike module for extending the flood detection : (1) from checking requests only, to checking all SIP traffic and (2) from checking the valid SIP packages to checking all received data (even if junk). New way of using the module -> automatic - the module will install internal hooks to catch all incoming requests and replies (even if not well formed from SIP point of view) - more or less the module will monitor all incoming packages (from the network) on the SIP sockets. Each time the source IP of a package needs to be analyse (to see if trusted or not), the module will run a script route - see "check_route" module parameter -, where, based on custom logic, you can decide if that IP needs to be monitored for flooding or not. As action, when flood is detected, the module will automatically drop the packages.

2.30  REGISTRAR module

2.31  TEXTOPS module

2.32  TM module

2.33  UAC module

2.34  URI_DB module

important - This module does not exists anymore as its was merged into URI module (see AAA API and module changes). All functions from this module are now in URI module and prefixed db_ string.

2.35  URI_RADIUS module

important - This module does not exists anymore as its was merged into URI module (see AAA API and module changes). All functions from this module are now in URI module and prefixed radius_ prefix from the name of the functions was replaced with aaa_.

Retrieved from https://www.opensips.org/About/Version-1-6-0
Page last modified on May 14, 2013, at 01:50 PM