Resources.DocsCoreVar History

Hide minor edits - Show changes to markup

April 24, 2013, at 01:09 PM by 109.99.235.212 -
Changed lines 1-694 from:

Resources -> Documentation -> CookBooks -> Scripting variables


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

(:toc-float Table of Content:) 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.

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.

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

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.

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

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

Authentication Digest URI

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

Authentication realm

$ar - realm from Authorization or Proxy-Authorization header

Auth username user

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

Auth username domain

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

Auth nonce

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

Auth response

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

Auth nonce

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

Auth opaque

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

Auth algorithm

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

Auth QOP

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

Auth nonce count (nc)

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

Auth whole username

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

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.

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

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

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)

Call-Id

$ci - reference to body of call-id header

Content-Length

$cl - reference to body of content-length header

CSeq number

$cs - reference to cseq number from cseq header

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)

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

Content-Type

$cT - reference to body of content-type header

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)

Diversion header URI

$di - reference to Diversion header URI

Diversion "privacy" parameter

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

Diversion "reason" parameter

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

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)

Transport protocol of destination URI

$dP - reference to transport protocol of destination uri

Destination set

$ds - reference to destination set

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)

Error class

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

Error level

$err.level - severity level for the error

Error info

$err.info - text describing the error

Error reply code

$err.rcode - recommended reply code

Error reply reason

$err.rreason - recommended reply reason phrase

From URI domain

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

From display name

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

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)

From tag

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

From URI

$fu - reference to URI of 'From' header

From URI username

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

SIP message buffer

$mb - reference to SIP message buffer

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)

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)

SIP message ID

$mi - reference to SIP message id

SIP message length

$ml - reference to SIP message length

Domain in SIP Request's original URI

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

Port of SIP request's original URI

$op - reference to port of original R-URI

Transport protocol of SIP request original URI

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

SIP Request's original URI

$ou - reference to request's original URI

Username in SIP Request's original URI

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

Route parameter

$param(idx) - retrieves the parameters of the route. The index can be an integer, or a pseudo-variable (index starts at 1).
Example:

   route {
      ...
      $var(debug) = "DBUG:"
      route(PRINT_VAR, $var(debug), "param value");
      ...
   }

   route[PRINT_VAR] {
      $var(index) = 2;
      xlog("$param(1): The parameter value is <$param($var(index))>\n");
   }

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)

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)

Process id

$pp - reference to process id (pid)

Protocol of received message

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

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)

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

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

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)

Body of request/reply

$rb - reference to message body

Returned code

$rc - reference to returned code by last invoked function

$retcode - same as **$rc**

Remote-Party-ID header URI

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

SIP request's method

$rm - reference to request's method

SIP request's port

$rp - reference to port of R-URI

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

Transport protocol of SIP request URI

$rP - reference to transport protocol of R-URI

SIP reply's reason

$rr - reference to reply's reason

SIP reply's status

$rs - reference to reply's status

Refer-to URI

$rt - reference to URI of refer-to header

SIP Request's URI

$ru - reference to request's URI

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

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)

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)

Received IP address

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

Received port

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

Script flags

$sf - reference to script flags - decimal output

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

Script flags

$sF - reference to script flags - hexa output

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

IP source address

$si - reference to IP source address of the message

Source port

$sp - reference to the source port of the message

To URI Domain

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

To display name

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

To tag

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

To URI

$tu - reference to URI of 'To' header

To URI Username

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

Formatted date and time

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

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.

String formatted time

$Tf - reference string formatted time

Current unix time stamp in seconds

$Ts - reference to current unix time stamp in seconds

Current microseconds of the current second

$Tsm - reference to current microseconds of the current second

Startup unix time stamp

$TS - reference to startup unix time stamp

User agent header

$ua - reference to user agent header field

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.

Escape Sequences

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

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

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");
...
}
...
to:

(:redirect Documentation.Script-CoreVar quiet=1 :)

January 29, 2013, at 05:28 PM by vlad_paiu -
Changed line 4 from:

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

to:

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

January 11, 2013, at 02:50 PM by razvancrainea -
Added lines 449-465:

Route parameter

$param(idx) - retrieves the parameters of the route. The index can be an integer, or a pseudo-variable (index starts at 1).
Example:

   route {
      ...
      $var(debug) = "DBUG:"
      route(PRINT_VAR, $var(debug), "param value");
      ...
   }

   route[PRINT_VAR] {
      $var(index) = 2;
      xlog("$param(1): The parameter value is <$param($var(index))>\n");
   }
Changed line 694 from:

@]

to:

@]

March 22, 2012, at 12:55 PM by vlad_paiu -
Changed line 4 from:

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

to:

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

September 23, 2011, at 12:49 PM by razvancrainea -
Added lines 584-587:

Formatted date and time

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

July 12, 2011, at 06:54 PM by bogdan -
Changed line 1 from:

Resources -> Documentation -> CookBooks -> Scripting variables - devel

to:

Resources -> Documentation -> CookBooks -> Scripting variables

Changed line 4 from:

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

to:

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

July 06, 2011, at 04:28 PM by razvancrainea -
Added lines 527-532:

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

Q value of the SIP Request's URI

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

June 22, 2011, at 01:00 PM by bogdan -
Changed lines 85-91 from:

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

The 'id' can be:

  • "i:number" - AVP name is an integer ID
  • "s:string" - AVP name is a string value
  • "alias" - the name is an AVP alias (use core parameter "avp_aliases" to define an AVP alias to an AVP name.
to:

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

Changed lines 93-96 from:
  1. AVPs with integer IDs are much much faster than the AVPs with string IDs
  2. AVP aliases are resolved at startup time so they have no impact at runtime
  3. an AVP can be deleted
to:
  1. the value of an AVP can be deleted
Deleted lines 99-100:
  1. define "tmp" as alias for "i:17"

avp_aliases="tmp=i:17"

Changed line 120 from:

$avp(i:17) = "one";

to:

$avp(17) = "one";

Changed line 122 from:

$avp(i:17) = "two";

to:

$avp(17) = "two";

Changed line 124 from:

$avp(i:17) = "three";

to:

$avp(17) = "three";

Changed line 127 from:

xlog("accessing values with no index: $avp(i:17)\n");

to:

xlog("accessing values with no index: $avp(17)\n");

Changed line 130 from:

xlog("accessing values with no index: $(avp(i:17)[2])\n");

to:

xlog("accessing values with no index: $(avp(17)[2])\n");

Changed lines 134-135 from:

$avp(i:17) = NULL;

to:

$avp(17) = NULL;

Changed lines 137-138 from:

avp_delete("$avp(i:17)/g");

to:

avp_delete("$avp(17)/g");

Changed lines 140-141 from:

$(avp(i:17)[1]) = NULL;

to:

$(avp(17)[1]) = NULL;

Changed line 143 from:

$(avp(i:17)[0]) = "zero";

to:

$(avp(17)[0]) = "zero";

Added lines 195-219:

Auth nonce

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

Auth opaque

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

Auth algorithm

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

Auth QOP

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

Auth nonce count (nc)

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

Deleted lines 658-659:

avp_aliases="uuid=I:50" ...

Changed lines 662-663 from:
    $avp(i:20)= $avp(uuid) + ": " + $fu;
    xdbg("$(C(bg))avp(i:20)$(C(xx)) [$avp(i:20)] $(C(br))cseq$(C(xx))=[$hdr(cseq)]\n");
to:
    $avp(tmp)= $avp(uuid) + ": " + $fu;
    xdbg("$(C(bg))avp(tmp)$(C(xx)) [$avp(tmp)] $(C(br))cseq$(C(xx))=[$hdr(cseq)]\n");
April 21, 2011, at 11:12 PM by kennardwhite - Add new PV $hdrcnt(name)
Changed lines 593-594 from:
to:

$(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.

February 07, 2011, at 11:36 AM by Tyler - changed a , to a .
Changed line 286 from:

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

to:

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

January 28, 2011, at 11:18 AM by bogdan -
Changed line 201 from:

$ar - the authentication response from Authorization or Proxy-Authorization header

to:

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

January 20, 2011, at 01:00 PM by anca_vamanu -
Changed lines 575-577 from:

Current unix time stamp in milliseconds

$Tsm - reference to current unix time stamp in milliseconds

to:

Current microseconds of the current second

$Tsm - reference to current microseconds of the current second

January 17, 2011, at 01:17 PM by anca_vamanu -
Changed lines 571-573 from:

Current unix time stamp

$Ts - reference to current unix time stamp

to:

Current unix time stamp in seconds

$Ts - reference to current unix time stamp in seconds

Current unix time stamp in milliseconds

$Tsm - reference to current unix time stamp in milliseconds

December 13, 2010, at 08:46 PM by osas - mark $dd and $dp as R/W
Added lines 308-309:

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

Added lines 325-326:

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

December 02, 2010, at 03:45 PM by bogdan -
Changed lines 8-9 from:

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 multipe values (for the same variable are handled).

to:

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

Changed line 20 from:
  • name(compulsory) - the pseudovariable name(type).\\
to:
  • name(compulsory) - the pseudo-variable name(type).\\
Changed lines 25-27 from:
  • transformation - a series of processing actions can be applied on pseudovariable. 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 pseudovariable 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 pseudovarable 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.
to:
  • 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.
Changed lines 44-46 from:

AVPs are read write and an existing AVP can be even deleted (removed). An AVP may contain multiple values - a new assigment (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 varaibles - 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 readonly and only several allow write operations. A PV may return several values or only one, depening of the refered info (if can have multiple values or not).\\
to:

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).\\
Changed lines 49-52 from:
  • escape sequences - escape sequances used to format the strings; they are actually not variables, but rather formators.
to:
  • escape sequences - escape sequences used to format the strings; they are actually not variables, but rather formatters.
Changed line 59 from:
  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 inherite a value from a previous route that was executed by the same process.
to:
  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.
Changed line 69 from:

$var(a) = 3 + (7&(~2)); # arithemetic and bitwise operation

to:

$var(a) = 3 + (7&(~2)); # arithmetic and bitwise operation

Changed lines 90-93 from:
  • "alias" - the name is an AVP alias (use core paramter "avp_aliases" to define an AVP alias to an AVP name.

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

to:
  • "alias" - the name is an AVP alias (use core parameter "avp_aliases" to define an AVP alias to an AVP name.

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.

Changed line 130 from:
  1. we have a sigle value
to:
  1. we have a single value
December 02, 2010, at 03:36 PM by bogdan -
Changed line 103 from:
  1. Transaction persitency example
to:
  1. Transaction persistence example
Changed line 136 from:

xlog("aceesing values with no index: $avp(i:17)\n");

to:

xlog("accessing values with no index: $avp(i:17)\n");

Changed line 139 from:

xlog("aceesing values with no index: $(avp(i:17)[2])\n");

to:

xlog("accessing values with no index: $(avp(i:17)[2])\n");

Changed line 155 from:

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

to:

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

December 02, 2010, at 03:35 PM by bogdan -
Changed line 112 from:

$avp(tmp) = $ts ; # store the current time (at request processing)

to:

$avp(tmp) = $Ts ; # store the current time (at request processing)

Changed line 122 from:
		$var(setup_time) = $ts - $avp(tmp);
to:
		$var(setup_time) = $Ts - $avp(tmp);
November 30, 2010, at 09:30 PM by bogdan -
Changed lines 273-275 from:

CSeq

$cs - reference to body of cseq header

to:

CSeq number

$cs - reference to cseq number from cseq header

October 14, 2010, at 04:06 PM by razvancrainea -
Added lines 211-219:

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");
October 13, 2009, at 11:36 PM by bogdan -
Changed line 4 from:

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

to:

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

September 29, 2009, at 01:47 PM by anca_vamanu -
Changed lines 149-150 from:

$avp(i:17)[1] = NULL;

to:

$(avp(i:17)[1]) = NULL;

Changed line 152 from:

$avp(i:17)[0] = "zero";

to:

$(avp(i:17)[0]) = "zero";

September 25, 2009, at 03:04 PM by anca_vamanu -
Changed line 32 from:
  • Name, subname and index: $(avp(i:10)[2])
to:
  • Name, subname and index: $(avp(i:10)[2])
September 25, 2009, at 03:04 PM by anca_vamanu -
Changed line 13 from:

The complete syntax for a pseudo variable is: \\

to:

The complete syntax for a pseudo variable is:

Changed lines 30-32 from:
  • Name and 'subname: $hdr
to:
  • Name and 'subname: $hdr(Contact)
  • Name and index: $(ct[0])
  • Name, subname and index: $(avp(i:10)[2])
Deleted line 35:
September 25, 2009, at 02:46 PM by anca_vamanu -
Changed lines 12-13 from:

Syntax: The complete syntax for a pseudo variable is:

to:

Syntax:
The complete syntax for a pseudo variable is: \\

September 25, 2009, at 02:46 PM by anca_vamanu -
Added line 14:
Changed lines 16-17 from:

(:nl:) (:nl:)

to:
September 25, 2009, at 02:44 PM by anca_vamanu -
Changed lines 13-14 from:

The complete syntax for a pseudo variable is:

to:

The complete syntax for a pseudo variable is:

Deleted line 14:
September 25, 2009, at 02:44 PM by anca_vamanu -
Added lines 17-18:

(:nl:) (:nl:)

September 25, 2009, at 02:44 PM by anca_vamanu -
Deleted lines 16-17:
Deleted line 17:
September 25, 2009, at 02:38 PM by anca_vamanu -
Changed line 14 from:
to:
Changed line 17 from:


to:
September 25, 2009, at 02:35 PM by anca_vamanu -
Added line 18:
September 25, 2009, at 02:16 PM by anca_vamanu -
Changed line 13 from:

The complete syntax for a pseudo variable is:\\

to:

The complete syntax for a pseudo variable is:

Changed lines 17-18 from:

The fields written in green are optional.\\

to:


The fields written in green are optional.

September 25, 2009, at 01:50 PM by anca_vamanu -
Added line 14:
Added line 16:
September 24, 2009, at 07:33 PM by anca_vamanu -
Changed lines 28-29 from:
  • Only name: $ru
  • Name and 'subname: $hdr
to:
  • Only name: $ru
  • Name and 'subname: $hdr
Changed lines 31-32 from:
  • $(<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
to:
  • $(<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
September 24, 2009, at 07:32 PM by anca_vamanu -
Changed lines 14-16 from:

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

The fileds written in blue are optional.\\

to:

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

The fields written in green are optional.\\

September 24, 2009, at 07:31 PM by anca_vamanu -
Changed line 14 from:

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

to:

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

September 24, 2009, at 07:30 PM by anca_vamanu -
Changed line 14 from:

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

to:

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

September 24, 2009, at 07:30 PM by anca_vamanu -
Changed lines 14-15 from:

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

to:

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

September 24, 2009, at 07:29 PM by anca_vamanu -
Changed lines 14-16 from:

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

to:

$(<context>name(subname)[index]{transformation})
The fileds written in blue are optional.

Changed lines 29-31 from:
    * $(<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 

The fileds written in blue are optional.

to:
  • 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
September 24, 2009, at 07:27 PM by anca_vamanu -
Changed line 14 from:

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

to:

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

September 24, 2009, at 07:26 PM by anca_vamanu -
Changed line 14 from:

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

to:

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

September 24, 2009, at 07:25 PM by anca_vamanu -
Changed line 14 from:

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

to:

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

Changed lines 16-18 from:
  • name(compulsory) - the pseudovariable 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. The value at index 0 is the last inserted value and the first inserted value is the one with the highest index. You can also specify indexes with negative values
to:
  • name(compulsory) - the pseudovariable 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 pseudovariable. 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.
Added lines 24-26:

Usage examples:

  • Only name: $ru
  • Name and 'subname: $hdr
September 24, 2009, at 07:08 PM by anca_vamanu -
Changed lines 16-18 from:
  • name(compulsory) - the pseudovariable name(type).Ex: pvar, avp, ru, DLG, etc.
  • subname - the identifier of a certain pv from the given type. Ex: hdr(From), avp(i:25), DLG().
  • index -
to:
  • name(compulsory) - the pseudovariable 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. The value at index 0 is the last inserted value and the first inserted value is the one with the highest index. You can also specify indexes with negative values
September 24, 2009, at 07:05 PM by anca_vamanu -
Added lines 11-24:

Syntax: The complete syntax for a pseudo variable is:
$(<context>name(subname)[index]{transformation}) The fields meaning is:

  • name(compulsory) - the pseudovariable name(type).Ex: pvar, avp, ru, DLG, etc.
  • subname - the identifier of a certain pv from the given type. Ex: hdr(From), avp(i:25), DLG().
  • index -
  • context - the context in which the pseudovariable 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 pseudovarable 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.
    * $(<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 

The fileds written in blue are optional.

August 20, 2009, at 11:42 AM by anca_vamanu -
Changed line 71 from:
  1. AVPs are part of the transactin context, so they will be visible everywhere where the trasaction is present.
to:
  1. AVPs are part of the transaction context, so they will be visible everywhere where the transaction is present.
Added lines 121-126:
  1. delete the value located at a certain index

$avp(i:17)[1] = NULL;

  1. overwrite the value at a certain index

$avp(i:17)[0] = "zero";

July 06, 2009, at 12:41 PM by bogdan -
Changed lines 526-528 from:

Unix time stamp

$Ts - reference to unix time stamp

to:

Current unix time stamp

$Ts - reference to current unix time stamp

Startup unix time stamp

$TS - reference to startup unix time stamp

July 03, 2009, at 05:00 PM by bogdan -
Added lines 179-189:

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");
June 03, 2009, at 12:34 PM by bogdan -
Changed lines 180-198 from:

Request's first branch

$br - reference to request's first branch

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

Request's all branches

$bR - reference to request's all branches

Branch flags

$bf - reference to branch flags of branch 0 (RURI) - decimal output

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

Branch flags

$bF - reference to branch flags of branch 0 (RURI) - hexa output

to:

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
June 02, 2009, at 01:06 PM by bogdan -
Changed line 214 from:

Contact header

to:

Contact instance

June 02, 2009, at 01:05 PM by bogdan -
Changed lines 216-235 from:

$ct - reference to body of contact header

to:

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

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
May 28, 2009, at 12:07 PM by bogdan -
Deleted lines 497-498:

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

May 11, 2009, at 08:45 PM by bogdan -
Added lines 160-169:

Auth nonce

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

Auth response

$ar - the authentication response from Authorization or Proxy-Authorization header

April 23, 2009, at 10:28 AM by bogdan -
Changed lines 1-5 from:

Resources -> Documentation -> CookBooks -> Scripting variables

to:

Resources -> Documentation -> CookBooks -> Scripting variables - devel


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

November 03, 2008, at 03:59 PM by 81.180.102.217 -
Changed line 13 from:
  • AVP - Attribute Value Pair - the AVPs are dynamic variables (as name) that can be created - the AVPS are linked into a 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).\\
to:
  • 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).\\
October 27, 2008, at 09:07 PM by Sebastian -
Changed lines 4-7 from:

OpenSIPS povides 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 multipe values (for the same variable are handled).

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

to:

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

October 08, 2008, at 08:44 AM by 81.180.102.217 -
Changed lines 1-2 from:

Resources -> Documentation -> Scripting variables

to:

Resources -> Documentation -> CookBooks -> Scripting variables

October 03, 2008, at 12:50 PM by 81.180.102.217 -
Added line 3:

(:toc-float Table of Content:)

September 14, 2008, at 12:31 AM by 88.207.103.142 -
Changed lines 3-6 from:

OpenSIPS povides multiple type of variables to be used in the routing script. The difference between the types of variables comes from (1) the vizibility of the variable (when it is visible), (2) what the variabls 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 multipe values (for the same variable are handled).

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

to:

OpenSIPS povides 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 multipe values (for the same variable are handled).

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

Changed lines 9-12 from:
  • script variables - as the name says, these variables are stricly bound to the script routes. The variables are vizible only in the routing blockes - they are not message or transaction related, but they are process related (script variables will be inharited 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 assigment (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 into a message or transaction (if statefull 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).\\
to:
  • 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 into a 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).\\
July 22, 2008, at 12:35 PM by 81.180.102.217 -
Changed lines 515-517 from:

Examples

to:

Examples

July 22, 2008, at 12:34 PM by 81.180.102.217 -
Added line 26:
Added line 126:
July 22, 2008, at 12:33 PM by 81.180.102.217 -
Changed lines 23-24 from:
  1. Script variables
to:

Script variables

July 22, 2008, at 12:32 PM by 81.180.102.217 -
Changed line 12 from:
  • AVP - Attribute Value Pair - the AVPs are dynamic variables (as name) that can be created - the AVPS are linked into a message or transaction (if statefull 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).''
to:
  • AVP - Attribute Value Pair - the AVPs are dynamic variables (as name) that can be created - the AVPS are linked into a message or transaction (if statefull 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).\\
July 22, 2008, at 12:31 PM by 81.180.102.217 -
Added lines 1-530:

Resources -> Documentation -> Scripting variables

OpenSIPS povides multiple type of variables to be used in the routing script. The difference between the types of variables comes from (1) the vizibility of the variable (when it is visible), (2) what the variabls 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 multipe values (for the same variable are handled).

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

Types of variables:

  • script variables - as the name says, these variables are stricly bound to the script routes. The variables are vizible only in the routing blockes - they are not message or transaction related, but they are process related (script variables will be inharited 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 assigment (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 into a message or transaction (if statefull 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 assigment (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 varaibles - 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 readonly and only several allow write operations. A PV may return several values or only one, depening of the refered 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 sequances used to format the strings; they are actually not variables, but rather formators.

  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 inherite 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)); # arithemetic 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.

AVP variables

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

The 'id' can be:

  • "i:number" - AVP name is an integer ID
  • "s:string" - AVP name is a string value
  • "alias" - the name is an AVP alias (use core paramter "avp_aliases" to define an AVP alias to an AVP name.

When using the index "N" you can force the AVP to returne 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 transactin context, so they will be visible everywhere where the trasaction is present.
  4. AVPs with integer IDs are much much faster than the AVPs with string IDs
  5. AVP aliases are resolved at startup time so they have no impact at runtime
  6. an AVP can be deleted

Example of usage:

  1. Transaction persitency example
# enable avps in onreply route
modparam("tm", "onreply_avp_mode", 1)
# define "tmp" as alias for "i:17"
avp_aliases="tmp=i:17"
...
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(i:17) = "one";
# we have a sigle value
$avp(i:17) = "two";
# we have two values ("two","one")
$avp(i:17) = "three";
# we have three values ("three","two","one")

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

xlog("aceesing values with no index: $(avp(i: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(i:17) = NULL;

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

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

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.

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

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

Authentication Digest URI

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

Authentication realm

$ar - realm from Authorization or Proxy-Authorization header

Auth username user

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

Auth username domain

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

Auth whole username

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

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.

Request's first branch

$br - reference to request's first branch

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

Request's all branches

$bR - reference to request's all branches

Branch flags

$bf - reference to branch flags of branch 0 (RURI) - decimal output

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

Branch flags

$bF - reference to branch flags of branch 0 (RURI) - hexa output

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

Call-Id

$ci - reference to body of call-id header

Content-Length

$cl - reference to body of content-length header

CSeq

$cs - reference to body of cseq header

Contact header

$ct - reference to body of contact header

Content-Type

$cT - reference to body of content-type header

Domain of destination URI

$dd - reference to domain of destination uri

Diversion header URI

$di - reference to Diversion header URI

Diversion "privacy" parameter

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

Diversion "reason" parameter

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

Port of destination URI

$dp - reference to port of destination uri

Transport protocol of destination URI

$dP - reference to transport protocol of destination uri

Destination set

$ds - reference to destination set

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)

Error class

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

Error level

$err.level - severity level for the error

Error info

$err.info - text describing the error

Error reply code

$err.rcode - recommended reply code

Error reply reason

$err.rreason - recommended reply reason phrase

From URI domain

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

From display name

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

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)

From tag

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

From URI

$fu - reference to URI of 'From' header

From URI username

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

SIP message buffer

$mb - reference to SIP message buffer

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)

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)

SIP message ID

$mi - reference to SIP message id

SIP message length

$ml - reference to SIP message length

Domain in SIP Request's original URI

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

Port of SIP request's original URI

$op - reference to port of original R-URI

Transport protocol of SIP request original URI

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

SIP Request's original URI

$ou - reference to request's original URI

Username in SIP Request's original URI

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

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)

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)

Process id

$pp - reference to process id (pid)

Protocol of received message

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

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)

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

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

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)

Body of request/reply

$rb - reference to message body

Returned code

$rc - reference to returned code by last invoked function

$retcode - same as **$rc**

Remote-Party-ID header URI

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

SIP request's method

$rm - reference to request's method

SIP request's port

$rp - reference to port of R-URI

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

Transport protocol of SIP request URI

$rP - reference to transport protocol of R-URI

SIP reply's reason

$rr - reference to reply's reason

SIP reply's status

$rs - reference to reply's status

Refer-to URI

$rt - reference to URI of refer-to header

SIP Request's URI

$ru - reference to request's URI

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

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)

Received IP address

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

Received port

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

Script flags

$sf - reference to script flags - decimal output

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

Script flags

$sF - reference to script flags - hexa output

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

IP source address

$si - reference to IP source address of the message

Source port

$sp - reference to the source port of the message

To URI Domain

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

To display name

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

To tag

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

To URI

$tu - reference to URI of 'To' header

To URI Username

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

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.

String formatted time

$Tf - reference string formatted time

Unix time stamp

$Ts - reference to unix time stamp

User agent header

$ua - reference to user agent header field

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.

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

Escape Sequences

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

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

Examples

A few examples of usage.

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

Page last modified on April 24, 2013, at 01:09 PM