This page has been visited 2479 times.
2. What is new in 3.4.0
2.1 OpenSIPS script
- the dst_blacklist parameter may accept more relaxed rules definitions, as well as a set of flags/modifiers ("expire", "default", "readonly") of the blacklist.
- the nameaddr transformations offer support for multi-nameaddr headers, providing a way of iterating on them.
2.2 OpenSIPS Core
- Enhancement of OpenSIPS blacklists
- the list_blacklists MI function receives an optional parameter, name that filters the output of the blacklists
- the check_blacklists MI function was added to allow checking whether a proto:IP:port+pattern pair matches any blacklist rule
- the check_blacklist MI function checks whether a proto:IP:port+pattern pair matches a specific blacklist
- the add_blacklist_rule MI function adds a new rule to a blacklist
- the del_blacklist_rule MI function remove a rule from a blacklist
- the check_blacklist_rule core function checks whether a proto:IP:port+pattern pair matches a specific blacklist
- the add_blacklist_rule core function adds a new rule to a blacklist
- the del_blacklist_rule core function remove a rule from a blacklist
- the TCP based sockets may have a new "REUSE_PORT"' option
- Core MI functions
- Enhancements of the logging interface
- Logs can now be sent to both standard error and syslog. Each logging consumer can be enabled/disabled separately via the new stderror_enabled and syslog_enabled global parameters or at runtime via the new log_mute_state MI function.
- Additional filtering of the messages by log level, for each consumer, can now be achieved by setting the new stderror_level_filter and syslog_level_filter global parameters or at runtime via the new log_level_filter MI function.
- Logs can now also be printed in a JSON based, structured format, with two schema options: a basic opensips schema and CEE. This is controlled via the new stderror_log_format and syslog_log_format global parameters.
- New log_json_buf_size global parameter for configuring the size of the JSON document printing buffer.
- New log_msg_buf_size global parameter for configuring the size of the buffer used to pint the actual message field in a JSON log.
- New E_CORE_LOG event that is triggered for every log message produced by OpenSIPS. The event logging consumer is enabled via the new log_event_enabled parameter. Additional filtering of the raised events, by the log level of the messages, can be achieved by setting the new log_event_level_filter parameter.
- New shm_memlog_size global parameter which enables in-memory logging of shm operations, for debugging purposes.
- Full re-engineering of how references (from outside the script) to script routes are kept by modules (modparams or function params) in order to solve some systemic issues of the existing reload_routes MI command. The new version is able to cope with any changes in the routes (their order, adding, removing, their content). This applies to the Timer Routes too which may be also fully altered.
2.3 OpenSIPS Modules
2.4 aaa_diameter module 🔗
- Provide an aaa_url connection directly in the module, to be used by the custom dm_send_request() function.
- Enhance the dictionary provided with VENDOR support for applications and AVPs.
2.5 AVPOPS module 🔗
- New avp_shuffle function, for randomizing an AVP's values
2.6 B2B_ENTITIES module 🔗
- Add ability to directly start or accept sessions as a UAC/UAS from script or MI, independently of any controlling "b2b" logic.
- New script functions:
- New MI functions:
- Exported new E_UA_SESSION event to deilver requests/replies belonging to UAC/UAS session started with the above functions.
- New advertised_contact module parameter which sets the Contact to advertise in generated messages for b2b_entities' UAC/UAS sessions.
- New ua_default_timeout module parameter which sets the default maximum duration of b2b_entities' UAC/UAS sessions.
2.7 B2B_LOGIC module 🔗
- Replaced the letter flags of the b2b_bridge() and b2b_init_request() functions with a CSV list of named flags.
- Improved the bridging mechanism in terms of SDP negotiation when using the b2b_bridge() function (or another module triggers a bridging action via the internal API). You can read more about the previous issues and the new mechanisms in this blog article.
- New no-late-sdp flag for the b2b_bridge() function that changes the new default bridging behavior by avoiding late SDP negociation with the new entity.
- New hold flag for the b2b_bridge() function, that puts the old entity on hold before bridging it with the new entity.
- New b2b_bridge_retry() function that can be used to retry a failed bridging action by contacting a new destination.
2.8 CFGUTILS module 🔗
- ts_usec_delta() 5th parameter
2.9 CLUSTERER module 🔗
- new dispatch_jobs module parameter that controls whether jobs(processing replicated data packets) are dispatched from the receiving TCP worker process to free opensips workers. This is enabled by default and should not be changed (because it may decrease performance) unless you encounter issues with high CPU loads in specific circumstances (e.g. "thundering herd" problem).
- new enable_stats module parameter, exposing statistics such as "nodes", "nodes_up" and "nodes_down"
2.10 DIALOG module 🔗
- new delay the deletion functionality added - instead of having the dialog delete on spot, when terminating, the in-memory dialog may be kept longer, for eventual late requests (to be matched against the terminated dialog). See the delete_delay modparam and the $DLG_del_delay script variable.
- Add support for an integer type for dialog values. As such, the variable passed to store_dlg_value() and fetch_dlg_value() can now hold an integer, as well as the value assigned to the $dlg_val variable can now be an integer.
- Dialog flags will now be handled as alphanumerical values instead of integer bit indexes, in the same way as the message and branch scripting flags.
- pinging: the direction and nature of the ping failure (Caller/Callee, OPTIONS/ReINVITE) is now reflected in the $DLG_end_reason dialog status variable
- NEW optional parameter to set_dlg_profile(), giving the ability to clear all profile values before setting a new one. Similar for unset_dlg_profile()
2.11 DISPATCHER module 🔗
- The
probe_mode column was added to the dispatcher table and can be used to indicate whether a destination should be permanently pinged, or just when its state is in probing mode.
- the ds_reload MI command may take an optional extra parameter "inherit_state" to control if the status of the destinations should be inherited or not during reload.
- improved the destination's probing to do it without locking the internal data - this prevents blocking of dispatcher reloading while pinging in progress
2.12 DROUTING module 🔗
- the dr_reload MI command may take an optional extra parameter "inherit_state" to control if the status of the destinations should be inherited or not during reload.
- improved the GW's probing to do it without locking the internal data - this prevents blocking of DR reloading while pinging in progress
2.13 LOAD_BALANCER module 🔗
- improved the destination's probing to do it without locking the internal data - this prevents blocking of LB reloading while pinging in progress
2.14 MID_REGISTRAR module 🔗
2.15 MSRP_UA module 🔗
- New success_report and failure_report parameters for the msrp_ua_send_message MI function that allow you to explicitly request MSRP Reports.
- Export a new E_MSRP_REPORT_RECEIVED event for processing MSRP Reports, failure transaction response and local timeouts for SEND requests.
2.16 NATHELPER module 🔗
2.17 PRESENCE module 🔗
- Enhanced the E_PUBLISH_EVENT event with a new old_etag field, denoting the etag of the presentity prior to the update.
2.18 PYTHON module 🔗
2.19 REGISTRAR module 🔗
- Replaced the letter flags of the save() and lookup() functions with a CSV list of named flags.
- New optional port parameter to is_ip_registered(), allowing a more specific (strict) matching against the available contacts
2.20 REST_CLIENT module 🔗
2.21 RTPENGINE module 🔗
- Export a new E_RTPENGINE_STATUS event that gets triggered when one of the RTPEngine servers change their status.
- When RTPEngine servers are disabled, they are now periodically pinged in a separate process - this spares us from doing the pinging while processing SIP messages.
2.22 SIPMSGOPS module 🔗
2.23 TM module 🔗