(:nl:)>>messagehead<<

Alex? — 23 February 2026, 10:56

 - Better facilities for string manipulation: I often find myself wanting to extract a substring based on some kind of separator, and whilst it is possible its a few to many lines of code
 - Functions: I currently use routes as a replacement for functions. Returning values from routes has some traps for new players.

 - Inline code execution: This needs to be done with adequate safeguards in place to prevent exploits being accidently created by the scrip author. This feels like it will create some kind of security issue down the road. For security conscious users, there should be a way to disable this mode if it gets added. I can just imagine a carefully crafted sip packet resulting in code execution or the ability to leak user creds.

• evaluate major issues with this feature. Any roadblocks?

• evaluate / extend? the Python scripting support

• avoid redundant, copy-pasted code (modparam("dialog", modparam("dialog", modparam("dialog", modparam("dialog", modparam("dialog"...)

• avoid redundant, copy-pasted code (modparam("dialog", modparam("dialog", modparam("dialog", ...)

Development -> Topics? -> OpenSIPS 4.0 Development Plan

Development -> Topics? -> OpenSIPS 4.0 Development Plan

• get rid of lazy evaluation! Why is the convoluted "lumps" API useful in the first place? Why can't we just keep all SIP message editing real-time (more intuitive too!), along with a clean codebase (with no lump application headaches and bugs!)?

• get rid of lazy evaluation! Why is the convoluted "lumps" API useful in the first place? Why can't we just keep all SIP message editing real-time (more intuitive too!), along with a clean code-base (no lump application headaches and bugs!)?

• get rid of lazy evaluation! Why is the "lumps" API useful in the first place? Why can't we just keep all SIP message editing real-time?

• improve the module function API so it offers param validation/ranges/possible values + proper error reporting, as well as standardizing new parameter types (lists, dictionaries)

• inline code execution (alternative language): Do we want this / Is it feasible?

• allow $var(foo) = "sip:$var(user)@$var(domain)";

• inline code execution: Do we want this / Is it feasible?

MI Restructuring

• [NEW] RabbitMQ consumer

• B2B: rework such that we drop XML-based logic in favor of OpenSIPS script-based logic!

OpenSIPS Scripting Alternatives

• evaluate / extend the Python scripting support

• new class of MI commands for controlling calls

Module Improvements

• B2B: rework such that we drop XML-based flows in favor of OpenSIPS script-based flows!

• get rid of lazy evaluation! Why is the "lumps" API useful in the first place? Why can't we just keep things real-time?

• get rid of lazy evaluation! Why is the "lumps" API useful in the first place?

• add native preprocessing support (read more here)

• add native preprocessing support (read more here

Development -> Topics -> OpenSIPS 4.0 Development Plan

(:title OpenSIPS 4.0 Development Plan:) This page has been visited 22 times. (:toc-float Table of Content:)

OpenSIPS Scripting Language

• allow any input type to any function (no more: "this parameter does not support pvars", etc.)
• script parameters: get rid of annoying (and redundant) quotes around integers and variables
• remove redundant copy-paste code (modparam("dialog", modparam("dialog", modparam("dialog", ...)

Interacting w/ OpenSIPS

reload scripting routes

• evaluate major issues with this feature
• group existing tree + adjacent code into a "holder" structure. This allows two script to be run in parallel: the newly reloaded one, and the old one which is still running the already started calls.
• question: can script reloading work well without full dialog state?

simplifying MI interaction

• unified MI input/output: JSON data
• get rid of intermediary/abstracted command state: MI trees, nodes and attributes

Internal Rework

• push all fixup_get_XXX_value() logic further up into the core, so modules receive ready-to-use inputs without requiring any bloat code
• improve the module function API so it offers param validation/ranges/possible values, as well as standardizing new parameter types (lists, dictionaries)

(:commentboxchrono:)