Development -> Sand Box

This section is intended to be a place where people involved in OpenSIPS development can incubate, share and corroborate their ideas with the rest of the developers.

Shortly, this is a place for collectively build up new ideas.

How it works?

If you have a totally new topic, please create a new subpage and start writing down your ideas.

If you want to contribute to an existing topic, please go and update the corresponding sub-page.

Please do not create multiple subpages for the same / similar topics.

Please respect your fellow developers and do not mess up with their writings.

Topics

Dynamic routing modules - module refurbishing

Context of processed SIP message

NAT traversal - module refurbishing

B2Bua drafting

Event Notification Interface

Critical Issues Mailing List

Subscribe Confirmation Page

Extend Subscription Page

Devel Course Recordings

Log and traces

Generally speaking, opensips traces are very difficult to follow It would be nice if function calls and variables operations values could be traced in a more friendly manner. That would help troubleshooting. Also online trace activation (MI command ?) and ability to restrict tracing by IP or by registered user. Ability to dump SIP message once modified.

Language changes

• Separate module loading and configuration from routing in different files
• unify the variable naming and access

Access to headers or pseudo variables $msg.headername (ex: $msg.from, $msg.from.user, $msg.from.param["tag"], $msg.route[1], $msg.via[i] ) Access to AVPs and variables (ex : $avp.name = "value") and script variables (ex: $var.name = "value" )

• uniform usage of pseudo variable, fixed argument, avps, and script variables in all function calls and operations.

Another related topic: access to application servers. Seas is neat but what we need is ability to access HTTP servers and get back results. JSON ?

Database access

Ability to call database stored procedures in natural way.

Support for database manual or automated failover: definition of two servers per db_uri, one active one backup.

modparam("url_db", "url_active", "url_backup")

Memory management

new internal memory allocator that would automatically garbage collect memory

• after message is processed (core)
• after transaction is finished (attached to TM module)
• after dialog is closed / expired (attached to dialog module)