[[extend_subscription | Extend Subscription Page ]]

[[devel_course_recordings | Devel Course Recordings ]]

[[thanks_for_subscribing | Subscribe Confirmation Page ]]

[[issue_mailinglist | Critical Issues Mailing List ]]

[[event_notification | Event Notification Interface ]]

!!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

[[dynamicrouting | Dynamic routing modules - module refurbishing]]

[[messagecontext | Context of processed SIP message ]]

[[nattraversal | NAT traversal - module refurbishing ]]

[[b2bua | B2Bua drafting ]]

'''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)

35K3cF <a href="http://igvpzzseaxhh.com/">igvpzzseaxhh</a>, [url=http://reiuanwmkuwd.com/]reiuanwmkuwd[/url], [link=http://dhcpiotgwzts.com/]dhcpiotgwzts[/link], http://ssmwwfskguzd.com/

ZlhzwA <a href="http://sjdqzfvlbxru.com/">sjdqzfvlbxru</a>, [url=http://pdewzohixiih.com/]pdewzohixiih[/url], [link=http://xzrfftergatv.com/]xzrfftergatv[/link], http://lpottfekixjb.com/

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

'''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)

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

'''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")

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

Ability to call database stored procedures in natural way using db

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 ?

'''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.

[[logtraces | Log and traces ]]

[[dynamicrouting | Dynamic routing modules - module refurbishing]]

[[messagecontext | Context of processed SIP message ]]

[[nattraversal | NAT traversal - module refurbishing ]]

[[b2bua | B2Bua drafting ]]

[[dynamicrouting | Dynamic routing modules]]

!!Development -> Sand Box

!!Development -> SandBox

!!Development -> Contributing
----

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