Main.Ver160 HistoryHide minor edits - Show changes to markup April 25, 2013, at 05:17 PM
by
- Added lines 1-3:
(:redirect About.Version-1-6-0 quiet=1:) October 25, 2012, at 12:43 PM
by
- Changed line 1 from:
Main -> Releases? -> Version 1.6.x -> Devel 1.6.0to:
Main -> Available Versions -> Version 1.6.x -> Devel 1.6.0October 13, 2009, at 02:55 AM
by
- Changed line 20 from:
For backward compatibility, setting mem_leg will automatically set to the same value the mem_dump.\\ to:
For backward compatibility, setting mem_log will automatically set to the same value the mem_dump.\\ October 12, 2009, at 09:56 PM
by
- Added lines 4-9:
September 21, 2009, at 03:45 PM
by
- Deleted line 230:
Added lines 232-242:
CALL_CONTROL module
modparam("call_control", "init", "call-id=$ci to=$tu from=$fu authruri=$du another_field = $avp(i:10)")
Added lines 302-312:
PERMISSIONS module
September 20, 2009, at 10:39 PM
by
- Changed line 24 from:
to:
Changed lines 27-28 from:
@] Close Patch #2706135 (see https://sourceforge.net/tracker/?func=detail&aid=2706135&group_id=232389&atid=1086412) to:
@] September 20, 2009, at 10:39 PM
by - September 20, 2009, at 10:38 PM
by - September 20, 2009, at 10:34 PM
by
- Changed lines 24-30 from:
to:
listen=[proto:]host[:port][ AS host[:port]] Close Patch #2706135 (see https://sourceforge.net/tracker/?func=detail&aid=2706135&group_id=232389&atid=1086412) Changed lines 56-59 from:
to:
September 20, 2009, at 10:25 PM
by
- Added lines 124-136:
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 Added line 232:
Added lines 329-330:
September 20, 2009, at 10:15 PM
by
- Added lines 25-30:
Script Routes
September 20, 2009, at 10:05 PM
by
- Added lines 262-268:
PIKE moduleNew 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. September 20, 2009, at 10:00 PM
by
- Added lines 198-204:
BENACHMARK module
Deleted lines 210-211:
Added lines 226-228:
DROUTING module
September 20, 2009, at 09:54 PM
by
- Changed lines 208-210 from:
to:
Added lines 239-243:
MI_DATAGRAM
September 20, 2009, at 09:50 PM
by
- Deleted line 237:
Added lines 239-242:
NAT_TRAVERSAL
Changed lines 246-247 from:
to:
Changed lines 272-275 from:
to:
September 20, 2009, at 09:36 PM
by
- Added line 43:
September 20, 2009, at 09:35 PM
by
- Added line 256:
September 10, 2009, at 03:15 PM
by
- Changed lines 128-137 from:
ALIAS_DB module
to:
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 Changed lines 141-143 from:
AVPOPS module
to:
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 Changed lines 174-176 from:
AVP_RADIUS moduleimportant - Removed as its functionality is now part of the AAA_RADIUS module - see the AAA API and module changes. to:
ALIAS_DB module
Changed lines 185-187 from:
AUTH_RADIUS moduleimportant - Renamed as AUTH_AAA module - see the AAA API and module changes. to:
AVPOPS module
Added lines 189-196:
AVP_RADIUS moduleimportant - Removed as its functionality is now part of the AAA_RADIUS module - see the AAA API and module changes. AUTH_RADIUS moduleimportant - Renamed as AUTH_AAA module - see the AAA API and module changes. Added lines 276-277:
August 26, 2009, at 07:24 PM
by
- Added lines 172-176:
GROUP module
August 25, 2009, at 12:46 PM
by
- Added line 93:
Added line 95:
August 25, 2009, at 12:45 PM
by
- Changed lines 92-97 from:
TO BE updated to:
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 on http://www.opensips.org/Main/News0036. August 25, 2009, at 12:02 PM
by
- Changed lines 90-92 from:
to:
B2BUA support (NEW)TO BE updated August 25, 2009, at 11:37 AM
by
- Added lines 216-220:
UAC module
August 25, 2009, at 11:35 AM
by
- Deleted line 132:
Added lines 134-141:
AVP_RADIUS moduleimportant - Removed as its functionality is now part of the AAA_RADIUS module - see the AAA API and module changes. AUTH_RADIUS moduleimportant - Renamed as AUTH_AAA module - see the AAA API and module changes. Added line 163:
Added lines 165-169:
GROUP_RADIUS moduleimportant - Removed as merged into GROUP module - see the AAA API and module changes. Changed lines 220-221 from:
to:
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. Added lines 223-227:
URI_RADIUS moduleimportant - 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_. August 25, 2009, at 11:22 AM
by
- Added line 26:
Added lines 49-90:
AAA API and enhancement of RADIUS support(NEW)AAA APIThe 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 scriptThis 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 APIThe 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 changesDue to the fact that the modules that were previously using Radius were ported to the generic AAA API, the following changes have been made:
August 25, 2009, at 11:17 AM
by
- Changed lines 64-73 from:
to:
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. August 25, 2009, at 11:09 AM
by
- Added lines 64-65:
Deleted line 76:
Changed lines 78-81 from:
DIALOG module
to:
AVPOPS module
Added lines 83-96:
CFGUTILS module
DIALOG module
Deleted lines 156-165:
CFGUTILS module
AVPOPS module
August 20, 2009, at 03:21 PM
by
- Changed lines 43-44 from:
Transformationsto:
TransformationsAugust 20, 2009, at 01:13 PM
by
- Added lines 141-150:
CFGUTILS module
AVPOPS module
August 20, 2009, at 01:07 PM
by
- Changed lines 42-47 from:
to:
Transformations
August 20, 2009, at 01:04 PM
by
- Changed lines 40-41 from:
to:
August 20, 2009, at 10:36 AM
by
- Changed line 20 from:
to:
Added line 22:
db_version_table = "version_1_6"; Deleted lines 23-24:
db_version_table = "version_1_6"; August 20, 2009, at 10:35 AM
by
- Added lines 20-24:
db_version_table = "version_1_6"; August 20, 2009, at 10:05 AM
by
- Changed lines 12-20 from:
to:
July 23, 2009, at 02:09 PM
by
- Added lines 99-106:
TEXTOPS module
July 23, 2009, at 11:45 AM
by
- Added lines 75-77:
July 23, 2009, at 11:42 AM
by
- Added line 74:
July 16, 2009, at 10:31 AM
by
- Added lines 29-43:
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 July 06, 2009, at 01:42 PM
by
- Changed line 20 from:
to:
Deleted line 26:
The variable accepts also index $(branch(uri)[1]) for accessing a specific branch (multiple branches can be defined at a moment). The index starts from 0 (first branch). If the index is negative, it is considered the n-th branch from the end ( index -1 means the last branch).To get all branches, use the * index - $(branch(uri)[*]). July 06, 2009, at 01:40 PM
by
- Changed lines 19-28 from:
to:
The variable accepts also index $(branch(uri)[1]) for accessing a specific branch (multiple branches can be defined at a moment). The index starts from 0 (first branch). If the index is negative, it is considered the n-th branch from the end ( index -1 means the last branch).To get all branches, use the * index - $(branch(uri)[*]).
July 03, 2009, at 06:01 PM
by
- Added lines 19-20:
June 29, 2009, at 03:05 PM
by
- Changed line 53 from:
to:
June 29, 2009, at 03:04 PM
by
- Added line 55:
June 29, 2009, at 03:04 PM
by
- Added lines 55-70:
REGISTRAR module
Changed line 76 from:
to:
June 05, 2009, at 08:15 PM
by
- Changed lines 45-48 from:
to:
LOAD_BALANCER module
May 29, 2009, at 03:28 PM
by
- Added lines 30-35:
DIALOG module
May 11, 2009, at 11:44 PM
by
- Added lines 30-38:
DISPATCHER module
May 11, 2009, at 09:47 PM
by
- Added lines 13-18:
Pseudo variables
May 10, 2009, at 05:15 PM
by
- Added lines 37-38:
May 05, 2009, at 01:24 PM
by
- Added lines 13-23:
ALIAS_DB module
April 23, 2009, at 07:32 PM
by
- Changed lines 12-14 from:
to:
Added lines 16-20:
NATHELPER module
Added line 26:
April 09, 2009, at 12:19 PM
by
- Changed lines 16-17 from:
to:
Changed line 23 from:
- New function get_auth_id() - Checks given uri-string username against URI table (if use_uri_table is set) or subscriber table database backend required). Returns true if the user exists in the database, and sets the given variables to the authentication id and realm corresponding to the given uri. to:
April 09, 2009, at 12:18 PM
by
- Added line 12:
Added lines 14-20:
TM module
Changed line 23 from:
- New function get_auth_id(). to:
- New function get_auth_id() - Checks given uri-string username against URI table (if use_uri_table is set) or subscriber table database backend required). Returns true if the user exists in the database, and sets the given variables to the authentication id and realm corresponding to the given uri. April 08, 2009, at 06:49 PM
by
- Changed lines 13-15 from:
URI_DB moduleto:
URI_DB module- New function get_auth_id(). April 06, 2009, at 02:07 PM
by
- Added lines 1-13:
Main -> Releases? -> Version 1.6.x -> Devel 1.6.0(:toc-float Table of Content:) What is new in 1.6.0CoreURI_DB module |