Currently you are not logged in.

 Login | Register 

Main

Resources

Training

Events

Development

Resources -> Documentation -> CookBooks -> Scripting variables


This documentation is valid for OpenSIPS v1.9.x / devel.

Table of Content (hide)

  1. 1. Script variables
  2. 2. AVP variables
  3. 3. Pseudo Variables
    1. 3.1 URI in SIP Request's P-Asserted-Identity header
    2. 3.2 Authentication Digest URI
    3. 3.3 Authentication realm
    4. 3.4 Auth username user
    5. 3.5 Auth username domain
    6. 3.6 Auth nonce
    7. 3.7 Auth response
    8. 3.8 Auth nonce
    9. 3.9 Auth opaque
    10. 3.10 Auth algorithm
    11. 3.11 Auth QOP
    12. 3.12 Auth nonce count (nc)
    13. 3.13 Auth whole username
    14. 3.14 Acc username
    15. 3.15 Argument options
    16. 3.16 Branch
    17. 3.17 Branch fields
    18. 3.18 Call-Id
    19. 3.19 Content-Length
    20. 3.20 CSeq number
    21. 3.21 Contact instance
    22. 3.22 Fields of a contact instance
    23. 3.23 Content-Type
    24. 3.24 Domain of destination URI
    25. 3.25 Diversion header URI
    26. 3.26 Diversion "privacy" parameter
    27. 3.27 Diversion "reason" parameter
    28. 3.28 Port of destination URI
    29. 3.29 Transport protocol of destination URI
    30. 3.30 Destination set
    31. 3.31 Destination URI
    32. 3.32 Error class
    33. 3.33 Error level
    34. 3.34 Error info
    35. 3.35 Error reply code
    36. 3.36 Error reply reason
    37. 3.37 From URI domain
    38. 3.38 From display name
    39. 3.39 Forced socket
    40. 3.40 From tag
    41. 3.41 From URI
    42. 3.42 From URI username
    43. 3.43 SIP message buffer
    44. 3.44 Message Flags
    45. 3.45 Message Flags in hexadecimal
    46. 3.46 SIP message ID
    47. 3.47 SIP message length
    48. 3.48 Domain in SIP Request's original URI
    49. 3.49 Port of SIP request's original URI
    50. 3.50 Transport protocol of SIP request original URI
    51. 3.51 SIP Request's original URI
    52. 3.52 Username in SIP Request's original URI
    53. 3.53 Domain in SIP Request's P-Preferred-Identity header URI
    54. 3.54 Display Name in SIP Request's P-Preferred-Identity header
    55. 3.55 Process id
    56. 3.56 Protocol of received message
    57. 3.57 User in SIP Request's P-Preferred-Identity header URI
    58. 3.58 URI in SIP Request's P-Preferred-Identity header
    59. 3.59 Domain in SIP Request's URI
    60. 3.60 Body of request/reply
    61. 3.61 Returned code
    62. 3.62 Remote-Party-ID header URI
    63. 3.63 SIP request's method
    64. 3.64 SIP request's port
    65. 3.65 Transport protocol of SIP request URI
    66. 3.66 SIP reply's reason
    67. 3.67 SIP reply's status
    68. 3.68 Refer-to URI
    69. 3.69 SIP Request's URI
    70. 3.70 Username in SIP Request's URI
    71. 3.71 Q value of the SIP Request's URI
    72. 3.72 Received IP address
    73. 3.73 Received port
    74. 3.74 Script flags
    75. 3.75 Script flags
    76. 3.76 IP source address
    77. 3.77 Source port
    78. 3.78 To URI Domain
    79. 3.79 To display name
    80. 3.80 To tag
    81. 3.81 To URI
    82. 3.82 To URI Username
    83. 3.83 Formatted date and time
    84. 3.84 Branch index
    85. 3.85 String formatted time
    86. 3.86 Current unix time stamp in seconds
    87. 3.87 Current microseconds of the current second
    88. 3.88 Startup unix time stamp
    89. 3.89 User agent header
    90. 3.90 SIP Headers
  4. 4. Escape Sequences
    1. 4.1 Foreground and background colors
    2. 4.2 Examples

OpenSIPS provides multiple type of variables to be used in the routing script. The difference between the types of variables comes from (1) the visibility of the variable (when it is visible), (2) what the variable is attached to (where the variable resides), (3) read-write status of the variable (some types of the variables are read-only and (4) how multiple values (for the same variable are handled).

The OpenSIPS variables can be easily identified in the script as all their names (or notations) starts with the $ sign.

Syntax:
The complete syntax for a pseudo variable is:

$(<context>name(subname)[index]{transformation})

The fields written in green are optional. The fields meaning is:

  • name(compulsory) - the pseudo-variable name(type).
    Ex: pvar, avp, ru, DLG_status, etc.
  • subname - the identifier of a certain pv from the given type.
    Ex: hdr(From), avp(i:25).
  • index - a pv can store more than one value - it can refer to a list of values. You can access a certain value from the list if you specify its index. You can also specify indexes with negative values, -1 means the last inserted, -2 the value before the previous inserted one.
  • transformation - a series of processing actions can be applied on pseudo-variable. You can find the whole list of possible transformations here. The transformations can be cascaded, using the output of one transformation as the input of another.
  • context - the context in which the pseudo0variable will be evaluated. Now there are 2 pv contexts: reply and request. The reply context can be used in the failure route to request for the pseudo-variable to be evaluated in the context of the reply message. The request context can be used if in a reply route is desired for the pv to be evaluated in the context of the corresponding request.

Usage examples:

  • Only name: $ru
  • Name and 'subname: $hdr(Contact)
  • Name and index: $(ct[0])
  • Name, subname and index: $(avp(i:10)[2])
  • Context
    • $(<request>ru) from a reply route will get the Request-URI from the request
    • $(<reply>hdr(Contact)) context can be used from failure route to access information from the reply

Types of variables:

  • script variables - as the name says, these variables are strictly bound to the script routes. The variables are visible only in the routing blocks - they are not message or transaction related, but they are process related (script variables will be inherited by script routes executed by the same OpenSIPS process).
    Script variables are read write and they can have integer or string values. A script variable can have only a single value. A new assignment (or write operation) will overwrite the existing value.
  • AVP - Attribute Value Pair - the AVPs are dynamic variables (as name) that can be created - the AVPS are linked to a singular message or transaction (if stateful processing is used). A message or a transaction will initially (when received or created) have an empty list of AVPS attached to it. During the routing script, the script directly or functions called from script may create new AVPS that will automatically attached to the message/transaction. The AVPS will be visible in all routes where any message (reply or request) of the transaction will be processed - branch_route , failure_route, onreply_route (for this last route you need to enable the TM parameter onreply_avp_mode).
    AVPs are read write and an existing AVP can be even deleted (removed). An AVP may contain multiple values - a new assignment (or write operation) will add a new value to the AVP; the values are kept in "last added first to be used" order (stack).
  • pseudo variables - pseudo-variables (or PV) provide access to information from the processed SIP message (headers, RURI, transport level info, a.s.o) or from OpenSIPS inners (time values, process PID, return code of a function). Depending of what info they provide, the PVs are either bound to the message, either to nothing (global). Most of the PVs are read-only and only several allow write operations. A PV may return several values or only one, depending of the referred info (if can have multiple values or not).
    Standard PV is read-only and returns a single value (if not otherwise documented).
  • escape sequences - escape sequences used to format the strings; they are actually not variables, but rather formatters.

1. Script variables

Naming: **$var(name)**

Hints:

  1. if you want to start using a script variable in a route, better initialize it with same value (or reset it), otherwise you may inherit a value from a previous route that was executed by the same process.
  2. script variables are faster the AVPs, being referenced directly to memory location.
  3. the value of script variables persists over a OpenSIPS process.
  4. a script value can have only one value.

Example of usage:

$var(a) = 2;  # sets the value of variable 'a' to integer '2'
$var(a) = "2";  # sets the value of variable 'a' to string '2'
$var(a) = 3 + (7&(~2)); # arithmetic and bitwise operation
$var(a) = "sip:" + $au + "@" + $fd; # compose a value from authentication username and From URI domain

# using a script variable for tests
if( [ $var(a) & 4 ] ) {
  xlog("var a has third bit set\n");
}

Setting a variable to NULL is actually initializing the value to integer '0'. Script variables don't have NULL value.

2. AVP variables

Naming: **$avp(name)** or **$(avp(name)[N])**

When using the index "N" you can force the AVP to return a certain value (the N-th value). If no index is given, the first value will be returned.

Hints:

  1. to enable AVPs in onreply_route, use "modparam("tm", "onreply_avp_mode", 1)"
  2. if multiple values are used for a single AVP, the values are index in revert order than added
  3. AVPs are part of the transaction context, so they will be visible everywhere where the transaction is present.
  4. the value of an AVP can be deleted

Example of usage:

  1. Transaction persistence example
# enable avps in onreply route
modparam("tm", "onreply_avp_mode", 1)
...
route{
...
$avp(tmp) = $Ts ; # store the current time (at request processing)
...
t_onreply("1");
t_relay();
...
}

onreply_route[1] {
	if (t_check_status("200")) {
		# calculate the setup time
		$var(setup_time) = $Ts - $avp(tmp);
	}
}
  1. Multilple values example
$avp(17) = "one";
# we have a single value
$avp(17) = "two";
# we have two values ("two","one")
$avp(17) = "three";
# we have three values ("three","two","one")

xlog("accessing values with no index: $avp(17)\n");
# this will print the first value, which is the last added value -> "three"

xlog("accessing values with no index: $(avp(17)[2])\n");
# this will print the index 2 value (third one), -> "one"

# remove the last value of the avp; if there is only one value, the AVP itself will be destroyed
$avp(17) = NULL;

# delete all values and destroy the AVP
avp_delete("$avp(17)/g");

# delete the value located at a certain index 
$(avp(17)[1]) = NULL;

#overwrite the value at a certain index
$(avp(17)[0]) = "zero";

The AVPOPS module provides a lot of useful functions to operate AVPs (like checking values, pushing values into different other locations, deleting AVPs, etc).

3. Pseudo Variables

Naming: $name

Hints:

  1. the PV tokens can be given as parameters to different script functions and they will be replaced with a value before the execution of the function.
  2. most of PVs are made available by OpenSIPS core, but there are also module exporting PV (to make available info specific to that module) - check the modules documentation.

Predefined (provided by core) PVs are listed in alphabetical order.

3.1 URI in SIP Request's P-Asserted-Identity header

$ai - reference to URI in request's P-Asserted-Identity header (see RFC 3325)

3.2 Authentication Digest URI

$adu - URI from Authorization or Proxy-Authorization header. This URI is used when calculating the HTTP Digest Response.

3.3 Authentication realm

$ar - realm from Authorization or Proxy-Authorization header

3.4 Auth username user

$au - user part of username from Authorization or Proxy-Authorization header

3.5 Auth username domain

$ad - domain part of username from Authorization or Proxy-Authorization header

3.6 Auth nonce

$an - the nonce from Authorization or Proxy-Authorization header

3.7 Auth response

$auth.resp - the authentication response from Authorization or Proxy-Authorization header

3.8 Auth nonce

$auth.nonce - the nonce string from Authorization or Proxy-Authorization header

3.9 Auth opaque

$auth.opaque - the opaque string from Authorization or Proxy-Authorization header

3.10 Auth algorithm

$auth.alg - the algorithm string from Authorization or Proxy-Authorization header

3.11 Auth QOP

$auth.qop - the value of qop parameter from Authorization or Proxy-Authorization header

3.12 Auth nonce count (nc)

$auth.nc - the value of nonce count parameter from Authorization or Proxy-Authorization header

3.13 Auth whole username

$aU - whole username from Authorization or Proxy-Authorization header

3.14 Acc username

$Au - username for accounting purposes. It's a selective pseudo variable (inherited from acc module). It returns $au if exits or From username otherwise.

3.15 Argument options

$argv - provides access to command line arguments specified with '-o' option. Examples:

   # for option '-o foo=0'
   xlog("foo is $argv(foo) \n");

3.16 Branch

$branch - this variable is used for creating new branches by writing into it the value of a SIP URI. Examples:

   # creates a new branch
   $branch = "sip:new@doamin.org";
   # print its URI
   xlog("last added branch has URI $(branch(uri)[-1]) \n");

3.17 Branch fields

$branch() - this variable provides read/write access to all fields/attributes of an already existing branch (priorly created with append_branch() ). The fields of the branch are:

  • uri - the RURI of the branch (string value)
  • duri - destination URI of the branch (outbound proxy of the branch) (string value)
  • q - q value of the branch (int value)
  • path - the PATH string for this branch (string value)
  • flags - the branch flags of this branch (int value)
  • socket - the local socket to be used for relaying this branch (string value)

The variable accepts also index $(branch(uri)[1]) for accessing a specific branch (multiple branches can be defined at a moment). The index starts from 0 (first branch). If the index is negative, it is considered the n-th branch from the end ( index -1 means the last branch).
To get all branches, use the * index - $(branch(uri)[*]).
Examples:

   # creates the first branch
   append_branch();
   # creates the second branch
   force_send_socket(udp:192.168.1.10:5060);
   $du = "sip:192.168.2.10";
   append_branch("sip:foo@bar.com","0.5");

   # display branches
   xlog("----- branch 0: $(branch(uri)[0]) , $(branch(q)[0]), $(branch(duri)[0]), $(branch(path)[0]), $(branch(flags)[0]), $(branch(socket)[0]) \n");
   xlog("----- branch 1: $(branch(uri)[1]) , $(branch(q)[1]), $(branch(duri)[1]), $(branch(path)[1]), $(branch(flags)[1]), $(branch(socket)[1]) \n");

   # do some changes over the branches
   $branch(uri) = "sip:user@domain.ro";   # set URI for the first branch
   $(branch(q)[0]) = 1000;  # set to 1.00 for the first branch
   $(branch(socket)[1]) = NULL;  # reset the socket of the second branch
   $branch(duri) = NULL;  # reset the destination URI or the first branch

It is R/W variable (you can assign values to it from routing logic)

3.18 Call-Id

$ci - reference to body of call-id header

3.19 Content-Length

$cl - reference to body of content-length header

3.20 CSeq number

$cs - reference to cseq number from cseq header

3.21 Contact instance

$ct - reference to contact instance/body from the contact header. A contact instance is display_name + URI + contact_params. As a Contact header may contain multiple Contact instances and a message may contain multiple Contact headers, an index was added to the $ct variable:

  • $ct -first contact instance from message
  • $(ct[n]) - the n-th contact instance form the beginning of message, starting with index 0
  • $(ct[-n]) - the n-th contact instance form the end of the message, starting with index -1 (the last contact instance)

3.22 Fields of a contact instance

$ct.fields() - reference to the fields of a contact instance/body (see above). Supported fields are:

  • name - display name
  • uri - contact uri
  • q - q param (value only)
  • expires - expires param (value only)
  • methods - methods param (value only)
  • received - received param (value only)
  • params - all params (including names)

Examples:

  • $ct.fields(uri) - the URI of the first contact instance
  • $(ct.fields(name)[1]) - the display name of the second contact instance

3.23 Content-Type

$cT - reference to body of content-type header

3.24 Domain of destination URI

$dd - reference to domain of destination uri

It is R/W variable (you can assign values to it from routing logic)

3.25 Diversion header URI

$di - reference to Diversion header URI

3.26 Diversion "privacy" parameter

$dip - reference to Diversion header "privacy" parameter value

3.27 Diversion "reason" parameter

$dir - reference to Diversion header "reason" parameter value

3.28 Port of destination URI

$dp - reference to port of destination uri

It is R/W variable (you can assign values to it from routing logic)

3.29 Transport protocol of destination URI

$dP - reference to transport protocol of destination uri

3.30 Destination set

$ds - reference to destination set

3.31 Destination URI

$du - reference to destination uri (outbound proxy to be used for sending the request) If loose_route() returns TRUE a destination uri is set according to the first Route header.

It is R/W variable (you can assign values to it from routing logic)

3.32 Error class

$err.class - the class of error (now is '1' for parsing errors)

3.33 Error level

$err.level - severity level for the error

3.34 Error info

$err.info - text describing the error

3.35 Error reply code

$err.rcode - recommended reply code

3.36 Error reply reason

$err.rreason - recommended reply reason phrase

3.37 From URI domain

$fd - reference to domain in URI of 'From' header

3.38 From display name

$fn - reference to display name of 'From' header

3.39 Forced socket

$fs - reference to the forced socket for message sending (if any) in the form proto:ip:port

It is R/W variable (you can assign values to it routing script)

3.40 From tag

$ft - reference to tag parameter of 'From' header

3.41 From URI

$fu - reference to URI of 'From' header

3.42 From URI username

$fU - reference to username in URI of 'From' header

3.43 SIP message buffer

$mb - reference to SIP message buffer

3.44 Message Flags

$mf - reference to message/transaction flags set for current SIP request

It is R/W variable (you can assign values to it from routing logic)

3.45 Message Flags in hexadecimal

$mF -reference to message/transaction flags set for current SIP request in hexa

It is R/W variable (you can assign values to it from routing logic)

3.46 SIP message ID

$mi - reference to SIP message id

3.47 SIP message length

$ml - reference to SIP message length

3.48 Domain in SIP Request's original URI

$od - reference to domain in request's original R-URI

3.49 Port of SIP request's original URI

$op - reference to port of original R-URI

3.50 Transport protocol of SIP request original URI

$oP - reference to transport protocol of original R-URI

3.51 SIP Request's original URI

$ou - reference to request's original URI

3.52 Username in SIP Request's original URI

$oU - reference to username in request's original URI

3.53 Domain in SIP Request's P-Preferred-Identity header URI

$pd - reference to domain in request's P-Preferred-Identity header URI (see RFC 3325)

3.54 Display Name in SIP Request's P-Preferred-Identity header

$pn - reference to Display Name in request's P-Preferred-Identity header (see RFC 3325)

3.55 Process id

$pp - reference to process id (pid)

3.56 Protocol of received message

$pr or $proto - protocol of received message (UDP, TCP, TLS, SCTP)

3.57 User in SIP Request's P-Preferred-Identity header URI

$pU - reference to user in request's P-Preferred-Identity header URI (see RFC 3325)

3.58 URI in SIP Request's P-Preferred-Identity header

$pu - reference to URI in request's P-Preferred-Identity header (see RFC 3325)

3.59 Domain in SIP Request's URI

$rd - reference to domain in request's URI

It is R/W variable (you can assign values to it routing script)

3.60 Body of request/reply

$rb - reference to message body

3.61 Returned code

$rc - reference to returned code by last invoked function

$retcode - same as **$rc**

3.62 Remote-Party-ID header URI

$re - reference to Remote-Party-ID header URI

3.63 SIP request's method

$rm - reference to request's method

3.64 SIP request's port

$rp - reference to port of R-URI

It is R/W variable (you can assign values to it routing script)

3.65 Transport protocol of SIP request URI

$rP - reference to transport protocol of R-URI

3.66 SIP reply's reason

$rr - reference to reply's reason

3.67 SIP reply's status

$rs - reference to reply's status

3.68 Refer-to URI

$rt - reference to URI of refer-to header

3.69 SIP Request's URI

$ru - reference to request's URI

It is R/W variable (you can assign values to it routing script)

3.70 Username in SIP Request's URI

$rU - reference to username in request's URI

It is R/W variable (you can assign values to it routing script)

3.71 Q value of the SIP Request's URI

$ru_q - reference to q value of the R-URI

It is R/W variable (you can assign values to it routing script)

3.72 Received IP address

$Ri - reference to IP address of the interface where the request has been received

3.73 Received port

$Rp - reference to the port where the message was received

3.74 Script flags

$sf - reference to script flags - decimal output

It is R/W variable (you can assign values to it from routing logic)

3.75 Script flags

$sF - reference to script flags - hexa output

It is R/W variable (you can assign values to it from routing logic)

3.76 IP source address

$si - reference to IP source address of the message

3.77 Source port

$sp - reference to the source port of the message

3.78 To URI Domain

$td - reference to domain in URI of 'To' header

3.79 To display name

$tn - reference to display name of 'To' header

3.80 To tag

$tt - reference to tag parameter of 'To' header

3.81 To URI

$tu - reference to URI of 'To' header

3.82 To URI Username

$tU - reference to username in URI of 'To' header

3.83 Formatted date and time

$time(format) - returns the string formatted time according to UNIX date (see: man date).

3.84 Branch index

$T_branch_idx - the index (starting with 1 for the first branch) of the branch for which is executed the branch_route[]. If used outside of branch_route[] block, the value is '0'. This is exported by TM module.

3.85 String formatted time

$Tf - reference string formatted time

3.86 Current unix time stamp in seconds

$Ts - reference to current unix time stamp in seconds

3.87 Current microseconds of the current second

$Tsm - reference to current microseconds of the current second

3.88 Startup unix time stamp

$TS - reference to startup unix time stamp

3.89 User agent header

$ua - reference to user agent header field

3.90 SIP Headers

$(hdr(name)[N]) - represents the body of the N-th header identified by 'name'. If [N] is omitted then the body of the first header is printed. The first header is got when N=0, for the second N=1, a.s.o. To print the last header of that type, use -1, no other negative values are supported now. No white spaces are allowed inside the specifier (before }, before or after {, [, ] symbols). When N='*', all headers of that type are printed.

The module should identify most of compact header names (the ones recognized by OpenSIPS which should be all at this moment), if not, the compact form has to be specified explicitly. It is recommended to use dedicated specifiers for headers (e.g., %ua for user agent header), if they are available -- they are faster.

$(hdrcnt(name)) -- returns number of headers of type given by 'name'. Uses same rules for specifying header names as $hdr(name) above. Many headers (e.g., Via, Path, Record-Route) may appear more than once in the message. This variable returns the number of headers of a given type.

Note that some headers (e.g., Path) may be joined together with commas and appear as a single header line. This variable counts the number of header lines, not header values.

For message fragment below, $hdrcnt(Path) will have value 2 and $(hdr(Path)[0]) will have value <a.com>:

    Path: <a.com>
    Path: <b.com>

For message fragment below, $hdrcnt(Path) will have value 1 and $(hdr(Path)[0]) will have value <a.com>,<b.com>:

    Path: <a.com>,<b.com>

Note that both examples above are semantically equivalent but the variables take on different values.

4. Escape Sequences

These sequences are exported, and mainly used, by xlog module to print messages in many colors (foreground and background) using escape sequences.

4.1 Foreground and background colors

$C(xy) - reference to an escape sequence. ¿x¿ represents the foreground color and ¿y¿ represents the background color.

Colors could be:

  • x : default color of the terminal
  • s : Black
  • r : Red
  • g : Green
  • y : Yellow
  • b : Blue
  • p : Purple
  • c : Cyan
  • w : White

4.2 Examples

A few examples of usage.

...
route {
...
    $avp(uuid)="caller_id";
    $avp(tmp)= $avp(uuid) + ": " + $fu;
    xdbg("$(C(bg))avp(tmp)$(C(xx)) [$avp(tmp)] $(C(br))cseq$(C(xx))=[$hdr(cseq)]\n");
...
}
...

Your VoIP Account

News

OpenSIPS Getting Started

21st of April 2012 OpenSIPS Getting Started Video Tutorial about how to do an installation of OpenSIPS and OpenSIPS-CP...
Watch it now...

OpenSIPS Devel Course

12th of April 2012 Learn about OpenSIPS internals both core and modules...
Read more...

OpenSIPS 1.8.0

22nd of March 2012 OpenSIPS 1.8.0 major release ready...
Read more...

Dynamic Routing

20th of March 2012 Enhancements of DR engine...
Read more...

APT repository

23nd of February 2012 New official APT repository for Debian & Ubuntu
Read more...

OpenSIPS 1.7.2

22nd of February 2012 OpenSIPS 1.7.2 minor release out...
Read more...

SIP Validation Support

20th of February 2012 Prevent malformed SIP messages from propagating through your network
Read more...

DNS Caching Support

13th of February 2012 Cache system for all types of DNS records
Read more...

Distributed Dialog Profiles

9th of February 2012 Shared dialog profiles between multiple instances of OpenSIPS
Read more...

Configuration and Scripting Tool

19th of January 2012 Graphical Configuration and Scripting Tool for OpenSIPS
Read more...

Cassandra driver

05th of January 2012 Cassandra backend for OpenSIPS
Read more...

LUA integration

05th of January 2012 Using LUA scripting with OpenSIPS
Read more...

OpenSIPS Pavilion @ ITExpo 2012

22th of December 2011 OpenSIPS Pavilion booth #535, 1-3 Feb 2012
Read more...

OpenSIPS and HOMER

14th of December 2011 Distributed SIPtracing and SIPcapturing
Read more...

OpenSIPS eBootcamp

12th of December 2011 New Ebootcamp session starting on 15th of February 2012.
Read more...

OpenSIPS 1.7.1

23rd of November 2011 OpenSIPS 1.7.1 minor release out...
Read more...

Ratelimit

3rd of November 2011 Dynamic and distributed support...
Read more...

OpenSIPS VM 1.7.0

1st of November 2011 Live Virtual Machine for OpenSIPS 1.7...
Read more...

MI via HTTP

25th of October 2011 Bultin HTTP server for MI...
Read more...

Events via RabbitMQ

12th of October 2011 Event Interface can push events via RabbitMQ...
Read more...

Key-Value Cache/DBs

6th of October 2011 Script and module support for key-value oriented backend...
Read more...

GRUU support

4th of October 2011 OpenSIPS registrar with GRUU / RFC5627...
Read more...

OpenSIPS 1.8.0 preview

30th of September 2011 What is set to be done for OpenSIPS 1.8.0...
Read more...

OpenSIPS eBootcamp

28th of July 2011 New Ebootcamp session starting on 19th of September.
Read more...

OpenSIPS 1.7.0

12nd of July 2011 OpenSIPS 1.7.0 major release ready...
Read more...

ClueCon 2011

11th of July 2011 Talks and one-day free training
Read more...

New in 1.7.0

6th of July 2011 What is new in OpenSIPS 1.7.0
Read more...

SVN Freeze

30th of June 2011 Testing phase started for 1.7 release
Read more...

Topology Hiding

30th of June 2011 Topology Hiding based on dialog module
Read more...

New AVP naming

23rd of June 2011 A simpler and more efficient way of naming AVPs
Read more...

DB Optimization

22nd of June 2011 Multi-row DB insert operations.
Read more...

Event Notification Interface

26th of May 2011 External interaction via the Event Interface.
Read more...

OpenSIPS eBootcamp

28th of March 2011 New Ebootcamp session starting on 2nd of May.
Read more...

UAC_REGISTRANT module

10th of March 2011 New module to allow OpenSIPS to UAC register.
Read more...

Performance degradation with complexity

08th of March 2011 Tests to show how performance is affected with complexity.
Read more...

Load and performance monitoring

22nd of February 2011 New statistics and traps for OpenSIPS monitoring.
Read more...

OpenSIPS 2.0

17th of February 2011 OpenSIPS 2.0 first code release.
Read more...

OpenSIPS Online Meeting

15th of February 2011 OpenSIPS Online Monthly Meetings started.
Read more...

OpenSIPS Social Event

24th of January 2011 OpenSIPS Social Event - Miami, 3rd of February.
Read more...

OpenSIPS eBootcamp

17th of January 2011 New Ebootcamp session starting on 28th of February.
Read more...

OpenSIPS 1.6.4

20th of December 2010 OpenSIPS 1.6.4 major release ready...
Read more...

OpenSIPS media timeout

16th of December 2010 Ghost call hunting with media timeout ...
Read more...


Edit | History | Print | Recent Changes | Search
Page last modified on March 22, 2012, at 12:55 PM