https://www.opensips.org/About/Version-2-3-0

2.  What is new in 2.3.0

2.1  OpenSIPS core

• support for armv6 and armv7 locking
• support for fast-locks on mips and mips64el architectures
• support for native umutex in freebsd
• added a new statistic for the SHM memory groups that prints the maximum memory used of a group
• added content-aware body (multi-part) changing - this allows parsing and modification of the body via the "body parts" list; parts can be modified (with function or lumps), can be deleted and new ones can be added. Any type of modification (and any of them) is allowed. The body is completely rebuild based on the resulting list of body parts. Also we support transparent transitions from no body to body, single part body to multi-part body or the other way around - with automatic update of the Content-Type and Content-Len headers, of course.
• major rework of body and SDP parsing - unified and consistent way of parsing and accessing the body parts (single or multi part body). This results in a transparent way of parsing and freeing the parts content (like SDP or ISUP).
• address potential starvation for the timer tasks - even if the timer tasks have priority in the asyns reactor (for being handled), if all the worker processes are already busy in handling some SIP tasks which takes too long, may lead into a starvation of the timer tasks. For the moment we address this by creating a extra worker processes (similar to the SIP workers) which is dedicated to executing the timer tasks. Still, based on their availability and load, the SIP workers are able to consume timer tasks.
• added the first basic version of an IPC support - this is an internal mechanism that allows any process to pass a job to another process. the IPC support is internally used by the Event Routing module and by the TCP stack. In the next version, more custom existing inter-process communication will be migrated to this generic IPC support. Also, the IPC mechanism opens new possibilities when comes to improvements or creation of new features.

2.2  OpenSIPS script

• new $xlog_level core pseudo-variable that prints the level of message printed at syslog
• new custom index append for $avp variables to allow you to add new values at the end of the list (at the bottom of the stack) - $(avp(name)[append]) = "last value";
• $rb can now take as name a mime, in order to access the body parts by mime : $rb(application/sdp) - get the first SDP body part ; $(rb(application/isup)[-1]) - get the last ISUP body part
• the the xlog messages include now the time and process ID when printing to stderr (to be consistent with the syslog logging)

2.3  Async layer

• new launch() statement to starts a function/job in async mode and continue the script immediately, without waiting for the job to be terminated. A "report" route may be triggered (outside the context of the msg launching the job) when the job is terminated to be able to access the return code and the possible returned data. See for more.
• new internal (non-scripting) support for async I/O operations - internal functions can register FDs into the reactor in order to be triggered when data is available (and run a handler). For example this is internally used by the cgrates module in order to handle its communication with the external cgrates engine
• enhanced the ASYNC API to allows resume via non-FD events (outside I/O reactor scope) ; The resume/suspect logic is reused, but the waiting and triggering can now by done via other means (like event based) rather than being I/O reactor based.

2.4  OpenSIPS Enhanced tracing

Starting with this versions multiple events can be traced, other than sip packets. There are two types of events:

• events that take place when a certain type of SIP packet is processed, events happening in a '''sip context that can be controlled using siptrace module;
• events that don't take place in a sip context that are controlled directly via proto_hep module;

At the moment, OpenSIPS 2.3 supports tracing for the following sip context events:

• xlog messages;
• rest_client module queries ( requests and replies );

These events are controlled via sip_trace function which was enhanced with a new parameter through which one can specify which of these events shall be traced. All these events will be traced in the sip context that is given to the function, that is if rest tracing is activated for a dialog, all rest requests and replies that will occur for that dialog shall be traced.

The following non sip events can be traced:

• transport layer events( currently available for TCP, TLS, WS and WSS transport layers;
• mi commands ( all mi protocols are available );

For these types of events the hep ids defined directly in proto_hep module, since there is no sip context( see mi_fifo exmaple). For the mi commands there is the posibilty to define blacklists or whitlists of commands to be traced in order to avoid tracing commands that are not useful( see mi_fifo example ). For transport layer protocols the unit we are working with is a connection. All protocol events such as connect or accept events, connection closed events for TCP, certificate information and master key for TLS and WSS and http request and reply used during the handshake for WS and WSS. Tracing can be activated via MI ( WSS example ) and the connections that will be traced can be controlled via a filter route in which users will ses source and destination IPs and ports for that connection ( WSS example ).

2.5  OpenSIPS troubleshooting / development

2.6  CGRATES module (new)

• the cgrates module provides an interface to the CGRateS rating eninge. Using this module you can do multi-tenant prepaid and postpaid billing in the OpenSIPS script. Read more information here.

2.7  EVENT ROUTING module (new)

• The Event (based) Routing module, or shortly the EBR module, provides a mechanism that allows different SIP processings (of messages in script) to communicate and synchronize between through OpenSIPS Events.
• This mechanism is based on the Subscribe-Notify concept. Any SIP processing may subscribe to various OpenSIPS Events Upon Event raising, the subscriber will be notified, so it will be able to make use of the data attached to the Event. Note that the Event raising may take place in a completely different SIP processing context, completely unrelated to the subscriber processing.
• The EBR support allows implementation of more advanced SIP scenarios like Push Notification or Call Pickup

2.8  FREESWITCH module (new)

• the freeswitch module acts as a connection manager for FreeSWITCH Event Socket Layer sockets. It currently provides dynamic statistics from FreeSWITCH in order to update routing behavior for the dispatcher and load_balancer modules.

2.9  SIP_I module (new)

• the SIP-I module provides SIP-I to SIP gatewaying and ISUP awarness by offering the possibility of processing ISDN User Part(ISUP) messages encapsulated in SIP. The available operations are: reading and modifying parameters from an ISUP message, removing or adding new optional parameters, adding an ISUP part to a SIP message body. This is done explicitly via script variables and functions. The supported ISUP message types are only the ones that can be included in a SIP message according to the SIP-I(SIP with encapsulated ISUP) protocol defined by ITU-T.

2.10  MID_REGISTRAR module (new)

• the mid_registrar enables a series of scenarios in which OpenSIPS acts as a SIP registration front-end. This novel SIP platform component is able to throttle downSIP registration traffic rates on the way to existing farms of SIP registrars, by extending contact expiration intervals. Moreover, it can also be configured to take over all parallel forking duties for these existing SIP infrastructures.

2.11  RABBITMQ module (new)

• a new RabbitMQ module provides a more flexible and easy to use interface to a RabbitMQ server. Check out more!

2.12  XML module (new)

• the XML module allows the processing of XML documents from the script by exposing a variable that provides access to the elements and their contents and attributes. In this way you can modify, add or remove nodes in the XML tree.

2.13  ACC module

• diameter support has been removed;
• extra variables engine was reworked(including both extra and leg engine); *_extra and *_extra_bye parameters have been replaced with extra_fields with which you can define tags to be used in the script using acc_extra script variable; the variable can be set/modified until the accounting is being made;
• leg variables engine was also reworked; now you can define leg variables for each of the available backends(log, db, aaa, evi); the modparam section is the same as for the extra_fields parameter whereas in the script you can use acc_leg variable to set the leg values; the variable can be indexed with the index of the leg; it accepts both positive index(0 is the first leg) and negative indexes(-1 is the last leg);
• the leg accounting engine is not based anymore on AVPs; each time you want to create a new leg you have to call acc_new_leg function which will create a new leg for you; the value of the last leg shall be accessed with acc_current_leg variable;
• for further information read the docs

2.14  Call Center module

• new queue_pos_param module paramter to report the queue position - the parameter value is the name of an SIP URI parameter to be used to report the position in the waiting queue when sending the call to media server for onwait/queue playback. The position 0 means it is the next call to be delivered to an agent.

2.15  Clusterer module

• the module was reworked and enhanced in order to provide a better node availability detection mechanism and inter-cluster routing of BIN messages (if the link between nodes A and B is down the message might be routed through node C). As there were no explicit probes at the clusterer module level, an active pinging mechanism was introduced which establishes the state of the connections of the current node with other nodes in the cluster at BIN interface level. Based on this, a link-state resembling protocol was implemented in order to learn the cluster topology and compute a routing 'table' used for sending BIN messages between nodes. Also the possibility of adding new nodes to the cluster without additional provisioning for the existing components was introduced.
• new module parameters for tweaking the probing mechanism:
  • ping_interval - the interval in seconds between regular pings sent to a neighbour node
  • ping_timeout - the time in milliseconds to wait for a reply to a previously sent ping before retrying or considering the link with the neighbour node down. This is also the interval between successive retries if the send fails.
  • node_timeout - the time in seconds to wait before pinging is restarted for a failed node
• the module's *_col parameters were changed to reflect the modified DB column names
• the MI command clusterer_list now lists information about the other nodes in the cluster from the current node's perspective
• new MI command clusterer_list_topology that lists the cluster's topology from the current node's perspective as an adjacency list
• for further information read the module documentation

2.16  DB MYSQL module

• new tls_client_domain module parameter - Quickly enable TLS usage for a given MySQL backend

2.17  Dialog module

• the dlg_list and dlg_end_dlg MI commands are now also using (display and accept) the dialog ID as dialog identifier - this is a single unique numerical ID ; Still, the h_label and h_id are accepted as old way to identify the dialogs.
• added new script function get_dialog_vals() for fetching all the values of a dialog found by callid string. The dialog values are returned as a parallel arrays of names and values.

2.18  Dispatcher module

• the module now supports dynamically calculated weights for FreeSWITCH destinations! As such:
  • the weight column type is now "string", as it can hold either an integer weight or a FreeSWITCH ESL socket. However, OpenSIPS still retains internal backwards-compatibility with the previous schema
  • fetch_freeswitch_stats - enables the dynamic weight calculation engine
  • max_freeswitch_weight - control the maximum weight of a FreeSWITCH destination computed using its runtime resource usage
• the round-robin algorithm now supports weights - each destination is chosen until its count reaches the weight, and only then moves to a different destination.
• new module parameter ds_ping_maxfwd - this parameter allows you to set a custom value for inserted Max-Forward header in the SIP ping requests generated by dispatcher module. If not used, it will let TM to add a default value.

2.19  DROUTING module

• the do_routing() accepts now any kind of variable for the routing group parameter; previously this was limited to AVP variables.
• added support for replicating the gateways and carrier status (upon changes) to other OpenSIPS nodes inside a cluster (using the clusterer module and BIN interface). New control parameters were added:
  • replicate_status_to - the cluster ID for replication pool
  • accept_replicated_status - the cluster ID for accepting incoming replication data

2.20  Cachedb_local module

• in previous versions the module had only one "database"(one hash); now multiple such databases can be defined, each of these representing an unique collection having it's own set of keys and values;
• the collections can be defined using cache_collections module parameter;
• each collection should be assigned to a cachedb_url; same collection can be assign to multiple cachedb_urls;
• for more information check the official documentation

2.21  Load Balancer module

• the module now supports dynamically calculated max resource values for FreeSWITCH destinations! As such:
  • resources may also be provisioned with a FreeSWITCH ESL socket URL as "max value" apart from an integer, as shown here
  • fetch_freeswitch_stats - enables the runtime max resource value calculation engine
  • initial_freeswitch_load - the starting "max resource" value, until the first batch of statistics arrive from FreeSWITCH
• preserve destination's status during reload - preserve the status (enabled or not) of the destinations during a data reload from DB.
• more detailed return code for functions starting/continuing the LB process. In case of LB failure, the ret code may be:
  • -1 generic internal error
  • -2 no capacity left
  • -3 no available destinations
  • -4 bad resources
• added support for replicating the destination status (upon changes) to other OpenSIPS nodes inside a cluster (using the clusterer module and BIN interface). New control parameters were added:
  • replicate_status_to - the cluster ID for replication pool
  • accept_replicated_status - the cluster ID for accepting incoming replication data

2.22  MI FIFO module

• trace mi datagram requests
  • command
  • parameters
  • module name
• and replies
  • code
  • reason
  • part of the reply message
• see official documentation;
• add blacklists/whitelists for traced mi commands (see official documentation);

2.23  MI HTTP module

• trace mi datagram requests:
  • command;
  • parameters;
  • module name;
• and replies:
  • code;
  • reason;
  • part of the reply message;
• for more information check the official documentation;
• add blacklists/whitelists for traced mi commands (see official documentation);

2.24  MI JSON module

• trace mi datagram requests:
  • command;
  • parameters;
  • module name;
• and replies:
  • code;
  • reason;
  • part of the reply message;
• for more information check the official documentation;
• add blacklists/whitelists for traced mi commands (see official documentation);

2.25  MI XMLRPC NG module

• trace mi datagram requests:
  • command;
  • parameters;
  • module name;
• and replies:
  • code;
  • reason;
  • part of the reply message;
• for more information check the official documentation;
• add blacklists/whitelists for traced mi commands (see official documentation);

2.26  MI DATAGRAM module

• trace mi datagram requests:
  • command;
  • parameters;
  • module name;
• and replies:
  • code;
  • reason;
  • part of the reply message;
• for more information check the official documentation;
• add blacklists/whitelists for traced mi commands (see official documentation);

2.27  OSP module

• Support for SUBSCRIBE/NOTIFY CNAM;
• Updated for OSP Toolkit 4.12.0 (see official documentation for more information).

2.28  PRESENCE module

• New E_PRESENCE_EXPOSED event that can be triggered over the MI interface and simulates the receiving of a PUBLISH message (see documentation);

2.29  PROTO HEP module

• be able to define hep destinations ( called hep ids ) that will be used by other modules;
• message payloads are now encapsulated using JSON format;
• new extra_correlation chunk used for correlating different types of messages( such as sip with xlog or rest, or transport messages with sip messages);
• new function correlate that sends a correlation message to the selected hep version 3 destination which unifies two correlation ids given from the script;

2.30  PROTO TCP module

• enable tracing for TCP connection events ( information about all accepted and created connections and information concerning closed connections );
• new trace_destination module parameter to define tracing destination;
• new trace_on module parameter to set tracing on and off at startup;
• new trace_filter_route module parameter to define a route which can be used for filtering traced connections;
• new tcp_trace mi function to control tracing ( on/off switch );

2.31  PROTO TLS module

• enable tracing for TLS connection events ( trace certificate info, master key along with information about all accepted and created connections and information concerning closed connections);
• new trace_destination module parameter to define tracing destination;
• new trace_on module parameter to set tracing on and off at startup;
• new trace_filter_route module parameter to define a route which can be used for filtering traced connections;
• new tls_trace mi function to control tracing ( on/off switch );

2.32  PROTO WS module

• enable tracing for WS connection events ( http request and reply used in web socket handshake along with information about all accepted and created connections and information concerning closed connections);
• new trace_destination module parameter to define tracing destination;
• new trace_on module parameter to set tracing on and off at startup;
• new trace_filter_route module parameter to define a route which can be used for filtering traced connections;
• new ws_trace mi function to control tracing ( on/off switch );

2.33  PROTO WSS module

• enable tracing for WSS connection events ( http request and reply used in web socket handshake, certificate info, master key along with information about all accepted and created connections and information concerning closed connections);
• new trace_destination module parameter to define tracing destination;
• new trace_on module parameter to set tracing on and off at startup;
• new trace_filter_route module parameter to define a route which can be used for filtering traced connections;
• new wss_trace mi function to control tracing ( on/off switch );

2.34  Registrar module

• the obsolete functions registered() and is_other_contact() finally removed. You should we their replacements 'is_registered() and is_ip_registered().

2.35  REST client module

• Connection reusage support added for all synchronous requests (see commit 79d02f379
• new connect_poll_interval module parameter - Allows complete control over how quickly we want to detect libcurl's completed TCP handshakes.
• new max_async_transfers module parameter - Maximum number of asynchronous HTTP transfers a single OpenSIPS worker is allowed to run simultaneously.
• new rest_put() script function, including async support (see commit c4807008b)
• ability to trace HTTP traffic using the sip_trace() function from siptrace module

2.36  RTPProxy module

• add support to specify RTPProxy to record both streams in a single file;
• add support for the latest notification mechanism in the RTPProxy master branch;
• add new rtpproxy_stats command that returns statistics about the call, such as packet loss, messages received from each side, etc.;
• add new rtpproxy_all_stats command that returns advanced statistics about the call, such as SSRC changes. This is only available in the RTPProxy master branch.
• add support for mangling RTP session TTL for both caller and callee.

2.37  RTPEngine module

• pass the flags from the rtpengine_offer/answer() functions to rtpengine, even though they are not known by OpenSIPS - loose the flags check restrictions to relax integration with further extensions.
• add new sock_pvar parameter to all rtpengine_* functions that can be used to return the rtpengine socket used for that call;
• add new sdp_pvar parameter to rtpengine_offer/answer/manage() functions that will store the SDP returned by rtpengine - Note that if you store the SDP body in a pvar, it will not be reflected in the outgoing message automatically, you will have to do it manually.
• added new teardown MI command as alias to dlg_end_dlg from dialog module

2.38  SIPMSGOPS module

• following the work on the multi-part body support, the following functions has changed in the module:
  • old filter_body() and strip_body() functions merged under the new remove_body_part() function
  • old has_body() function (not yet removed) is replaced by the new has_body_part() function
  • old add_body() function removed and replaced by the new add_body_part() function

2.39  SIPTRACE module

• use hep ids defined in proto_hep instead of defining the hep ids in siptrace using trace_id module parameter;
• allow tracing multiple types of events(xlog messages, rest HTTP requests and replies) using sip_trace function;

2.40  STATISTICS module

• add support for statistic groups and easy iteration over them in the OpenSIPS script. New control module parameters:
  • stat_groups - define the statistic groups before startup
  • stat_iter_init() - begin iteration over the statistics contained within a group
  • stat_iter_next() - fetch the current statistic, move on to the next one if possible
• allow stats to be updated via variables - the update_stat() function accepts variables for passing the update value.

2.41  TOPOLOGY HIDING module

• new D flag of the topology_hiding() function forces the insertion of the dialog ID (DID) into the Contact Username, rather than Contact URI parameters (as before).

2.42  TM module

• Added support for dynamic branch manipulation - new functions were added to allow remote injecting of new branches into an ongoing transaction:
  • t_inject_branches(source, flags) - injects new branches;
  • t_wait_for_new_branches() - instruct the transaction to wait more (even if all current branches are completed) for possible new branch injections.
• new script variable $T_id to expose the transaction internal ID as an opaque hexa string.
• new t_add_cancel_reason() script function to allow the insertion of a custom Reason header into a CANCEL request.

2.43  TLS MGM module

• support for the latest OpenSSL library version 1.1.0;
• for all module parameters accepting a TLS domain ID in their value, the syntax was changed : "tls_dom:value" was replaced with "[tls_dom]value", to avoid any conflicts between the separator and the actual value.
• 'full DB support added - instead of storing in DB the file path for certificate, private key, CA list and DH params, the DB holds the actual data (as BLOB). So, the TLS configuration is 100% DB driven, no files needed any more.

2.44  USRLOC module

• The E_UL_CONTACT_INSERT, E_UL_CONTACT_UPDATE and E_UL_CONTACT_DELETE events have now more attributes (full set to describe the contact):
  • path string
  • q value
  • socket description
  • branch flags
  • expires
  • uri as former "address"
• when listing contact records via MI command, the Contact ID is also printed (this helps with correlating the in-memory records with the DB records)