Development -> New Design -> Stage 1 implementation

This page has been visited 31686 times.

1.  What is available

The current experimental implementation acts as a simple RURI-based (with full DNS resolving) SIP proxy/relay. UDP and TCP protocols are supported (with multiple interfaces). The routing logic is hardcoded (for the moment) to simply do RURI based forwarding in stateless mode (no transaction or dialog support yet).

Available functionalities:

• configuration script with a section-based structure, used for global parameters (no support for routing logic yet)
• UDP and TCP transport protocols, multi-interface definition ; transport protocols are compiled as external libraries to core and loaded dynamically on demand (if an UDP interface is defined in cfg, the UDP protocol library will be loaded)
• asynchronous core reactor for managing blocking events (network ops, DNS queries, DB ops)
• thread based parallel processing - tasks are generated by different entities (like reactor indicating a new available read, timer triggering a new routine to be executed, DNS resolving being ready, DB operation being ready) and dispatched (with priorities and queuing) to a pool of available threads. All tasks are dispatched over all threads.
• timer thread - just fire tasks and push them to the worker threads (via dispatcher) to be executed
• SIP parser - parsing SIP packages (for TCP we now avoid double parsing - in old OpenSIPS, the messages were parsed first when read (to see where it ends) and secondly when parsed for routing)
• SIP message changes - old approach (with changes stored in lump for later insertion) was dropped - changes are now realtime (and can be seen from further processing). Data is partitioned at header level (each header is individually modified in realtime)
• DNS resolver - asynchronous DNS resolver (NAPTR, SRV, A) based on c-ares library. DNS caching or DNS failover not yet implemented.
• DB interface - DB core interface in place, MYSQL and POSTGRES asynchronous modules to be released in the next weeks
• Management Interface - same 'feel and look' MI support as for the old OpenSIPS; Only FIFO backend is available.

According to the OpenSIPS New Design, the current implementation covers the OpenSIPS Core, layers L0 and L1 plus the DB support.

2.  Where to get code

Code is available via GIT repository hosted on SourceForge. To get a copy of the code, do:

• for a read-only copy (if you are not an OpenSIPS developer on SF):

    git clone git://opensips.git.sourceforge.net/gitroot/opensips/sip_server sip_server_2

• for a read-write copy (if you are an OpenSIPS developer on SF):

    git clone ssh://SF_USERNAME@opensips.git.sourceforge.net/gitroot/opensips/sip_server sip_server_2

Once you have the sources, you can simply compile by :

   make all

Sub-options:

   make protos - compile only protocol libraries (TCP and UDP)
   make modules - compile only core modules (only mi_fifo for the moment)
   make - compile only core

Dependencies: compiling OpenSIPS Experimental core requires C-Ares library (and devel package) on your machine. Both lib and devel packages are widely available on all operating systems / distros.

If you encounter compiling/linking problems, please report to us via the devel mailing list.

A sample of config file is provided in the repository, under etc/opensips.cfg . To start opensips, do:

    ./opensips -f etc/opensips.cfg

3.  Configuration option

The configuration file is parameter oriented (not routing script here). The parameters are grouped in sections with the format:

   [section1]
   param1 = value
   param2 = value

   [section2]
   paramX = value
   ...

3.1  "core" section

• daemon = 1/0 - if OpenSIPS should become daemon
• chidlren = N - how many worker threads should be created
• working_dir = path - directory to be used as working direction by OpenSIPS at runtime
• chroot_dir = path - directory to change do after OpenSIPS starts
• user = ID/name - system user to be used by OpenSIPS at runtime
• group = ID/name - system group to be used by OpenSIPS at runtime
• do_coredump = 1/0 - if OpenSIPS should coredump when crashing
• rt_coredump = 1/0 - if OpenSIPS should do realtime coredump (per thread) or at the end (per process)
• open_files = N - limit of open files
• pid_file = file - file for OpenSIPS to write its PID
• pgid_file = file - file for OpenSIPS to write its PGID

3.2  "log" section

• debug = N - logging level to be used by OpenSIPS (4=DBG, 3=INFO, 2=NOTICE, 2=WARN, -1=ERR, -2=CRIT, -3=ALERT)
• memlog = N - log level to be used for printing memory debug info
• memdump = N - log level to be used for printing memory dumps
• log_syslog = 0/1 - if OpenSIPS should log to syslog or standard error
• log_name = NAME - what name to be used by OpenSIPS when logging to syslog
• log_facility = FACILITY = - what log facility to be used by OpenSIPS when logging to syslog

3.3  "net" section

• listen = [proto:]IP[:port] - listening interface to be used by OpenSIPS
• net_tos = N - TOS to be used for sending traffic
• udp_maxbuffer = N - size in bytes for the maximum size of the UDP buffer
• udp_min_size = N - what's the minim size of a UDP SIP message in order to be considered valid (otherwise discarded)
• tcp_max_size = N - maximum size (in bytes) for a TCP package
• tcp_via_alias = 1/0 - if OpenSIPS should do aliasing for the TCP connections
• tcp_lifetime = N - lifetime (seconds) of a TCP connection after the last data sent/received
• tcp_max_connections = N - maximum number of TCP connections to be allowed

3.4  "modules" section

• path = PATH - path where the core modules are installed
• load = MODULE_NAME - load a given core module

4.  Credits

People involved in the developement of OpenSIPS Experimental (alphabetical order):

• Andrei DRAGUS - andrei@opensips.org
• Bogdan IANCU - bogdan@opensips.org
• Vlad PAIU - vladpaiu@opensips.org