User Tools

Site Tools


cookbooks:devel:pseudovariables

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
cookbooks:devel:pseudovariables [2020/03/17 08:43]
miconda [$env(NAME) - environment variables]
cookbooks:devel:pseudovariables [2020/07/17 08:12] (current)
miconda
Line 1: Line 1:
 {{ :cookbooks:devel:pseudovariables.png?200|}} {{ :cookbooks:devel:pseudovariables.png?200|}}
-====== Kamailio SIP Server v5.4.x (devel): Pseudo-Variables ======+====== Pseudo-Variables ====== 
 + 
 +Version: Kamailio SIP Server v5.5.x (devel)
  
 ===== Introduction ===== ===== Introduction =====
Line 248: Line 250:
 **$fn** - reference to display name of 'From' header **$fn** - reference to display name of 'From' header
  
-==== $fs - Forced socket ====+==== $fs - Forced Send Socket ====
  
-**$fs** - reference to the forced socket for message sending (if any) in the form proto:ip:port+**$fs** - reference to the forced send socket for the SIP message (if any) in the form "proto:ip:port". It is the socket from where Kamailio is going to send out the message.
  
 <fc #0000ff>It is R/W variable (you can assign values to it directly in configuration file). Transport proto can be omitted when assigning value, in which case it is taken from destination URI of the message.</fc> <fc #0000ff>It is R/W variable (you can assign values to it directly in configuration file). Transport proto can be omitted when assigning value, in which case it is taken from destination URI of the message.</fc>
 +
 +Example:
 +
 +<code c>
 +listen=udp:1.2.3.4:5060
 +...
 +$fs = "udp:1.2.3.4:5060";
 +</code>
 +
 +==== $fsn - Forced Send Socket Name ====
 +
 +**$fsn** - reference to the name of the forced send socket for the SIP message. The name can be assigned to this variable to select a send socket via its name.
 +
 +<code c>
 +listen=udp:1.2.3.4:5060 name "s1"
 +...
 +$fsn = "s1";
 +...
 +$fs = "udp:1.2.3.4:5060";
 +xdbg("name for forced send socket: $fsn\n");
 +</code>
  
 ==== $ft - From tag ==== ==== $ft - From tag ====
Line 272: Line 295:
  
 Note that changing the From: header may break backwards compatibility with SIP 1.0 devices. Note that changing the From: header may break backwards compatibility with SIP 1.0 devices.
 +
 ==== $fU - From URI username ==== ==== $fU - From URI username ====
  
Line 279: Line 303:
  
 Note that changing the From: header may break backwards compatibility with SIP 1.0 devices. Note that changing the From: header may break backwards compatibility with SIP 1.0 devices.
 +
 +==== $fUl - From URI Username Length ====
 +
 +**$fUl** - length of the username in the From URI
 +
 ==== $mb - SIP message buffer ==== ==== $mb - SIP message buffer ====
  
Line 331: Line 360:
  
 **$oU** - reference to username in request's original URI **$oU** - reference to username in request's original URI
 +
 +==== $oUl - Original R-URI Username Length ====
 +
 +**$oUl** - the length of the username in the original R-URI
  
 ==== $pd - Domain in P-Preferred-Identity header URI ==== ==== $pd - Domain in P-Preferred-Identity header URI ====
Line 455: Line 488:
  
 <fc #0000ff>It is R/W variable (you can assign values to it directly in configuration file)</fc> <fc #0000ff>It is R/W variable (you can assign values to it directly in configuration file)</fc>
 +
 +==== $rUl - R-URI Username Length ====
 +
 +**$rU** - the length of the username in R-URI
  
 ==== $rv - SIP message version ==== ==== $rv - SIP message version ====
Line 594: Line 631:
  
 **$tU** - reference to username in URI of 'To' header **$tU** - reference to username in URI of 'To' header
 +
 +==== $tUl - To URI Username Length ====
 +
 +**$tU** - the length of the username in To URI
  
 ==== $Tb - Startup timestamp ==== ==== $Tb - Startup timestamp ====
Line 714: Line 755:
 ===== $xavp(id) - XAVPs ===== ===== $xavp(id) - XAVPs =====
  
-xavp - extended AVP'- are structures that can store multiple values. They work like a stack, much like AVPs, and are attached to SIP transactions. Each xavp has a name and can contain multiple named values, the structure name and the value name are separated by <nowiki>=></nowiki> like <nowiki>$xavp(root=>branch)</nowiki> where "root" is the name of the structure and branch is a named value. To assign a value use+**xavp** eXtended AVPs - are variables that can store multiple values, which can also be grouped in a structure-like fashion. Their value can be a string, an integer number or a list of named values (child values). 
 + 
 +They work like a stack, similar to AVPs, and are attached to SIP transactions and automatically destroyed when the transaction is finished. 
 + 
 +Each xavp has a string name and can contain a string, and integer or a list of named values. The structure name (or root list name) and the value name (or field name, or child value name) are separated by <nowiki>=></nowiki> like <nowiki>$xavp(root=>field)</nowiki> where "root" is the name of the structure and "field" is the name of the (child) value. 
 + 
 +To assign a single value use: 
 + 
 +<code c> 
 +$xavp(root)="string value"; 
 +$xavp(root)=intnumber; 
 +</code> 
 + 
 +To assign a named value use
 <code c> <code c>
-$xavp(root=>branch)="value";+$xavp(root=>field)="string value"
 +$xavp(root=>field)=intnumber;
 </code> </code>
  
 Like avps, xavp act like a stack. To refer to an existing value, use an index. The newest xavp has index zero [0]. Like avps, xavp act like a stack. To refer to an existing value, use an index. The newest xavp has index zero [0].
 +
 <code c> <code c>
-$xavp(root[0]=>newbranch)=12;+$xavp(root[0]=>field)=12;
 </code> </code>
  
 If you assign a value without an index, a new xavp is allocated and the old one is pushed up the stack, becoming index [1]. Old index [1] becomes [2] etc. If you assign a value without an index, a new xavp is allocated and the old one is pushed up the stack, becoming index [1]. Old index [1] becomes [2] etc.
 +
 <code c> <code c>
-$xavp(example=>name)="one"; +# new item (person => [(lastname = "Smith")]) 
-#create new +$xavp(person=>lastname)="Smith"; 
-$xavp(example=>name)="two"; + 
-#add extra value to "two+add new item (person => [(lastname = "Doe")]) 
-$xavp(example[0]=>value)="John"; +$xavp(person=>lastname)="Doe"; 
-#add value to first variable - "one+ 
-$xavp(example[1]=>value)="Anna";+# add another named value to the last example item 
 +#   (person => [(firstname="John"), (lastname = "Doe")]) 
 +$xavp(person[0]=>firstname)="John"; 
 + 
 +# add another named value to first example item 
 +#   (person => [(firstname="Alice"), (lastname = "Smith")]) 
 +xavp(person[1]=>firstname)="Alice";
 </code> </code>
  
Line 738: Line 802:
 Another example: Another example:
 <code c> <code c>
-Create new xavp+create new (the first) root xavp with a named value of string type
 $xavp(sf=>uri)="sip:10.10.10.10"; $xavp(sf=>uri)="sip:10.10.10.10";
  
-#assign values+add named values (child values)
 $xavp(sf[0]=>fr_timer)=10; $xavp(sf[0]=>fr_timer)=10;
 $xavp(sf[0]=>fr_inv_timer)=15; $xavp(sf[0]=>fr_inv_timer)=15;
 $xavp(sf[0]=>headers)="X-CustomerID: 1234\r\n"; $xavp(sf[0]=>headers)="X-CustomerID: 1234\r\n";
  
-#create new xavp, moving previous one to sf[1]+# create new (the second) root xavp with a named value of string type, moving previous one to sf[1]
 $xavp(sf=>uri)="sip:10.10.10.11"; $xavp(sf=>uri)="sip:10.10.10.11";
 +# add named values (child values)
 $xavp(sf[0]=>fr_timer)=20; $xavp(sf[0]=>fr_timer)=20;
 $xavp(sf[0]=>fr_inv_timer)=35; $xavp(sf[0]=>fr_inv_timer)=35;
  
-#Create a third xavp+create new (the thirdxavp with a named value of string type, moving previous one to sf[1] and the other one to sf[2]
 $xavp(sf=>uri)="sip:10.10.10.12"; $xavp(sf=>uri)="sip:10.10.10.12";
 +# add named values (child values)
 $xavp(sf[0]=>fr_timer)=10; $xavp(sf[0]=>fr_timer)=10;
 $xavp(sf[0]=>fr_inv_timer)=15; $xavp(sf[0]=>fr_inv_timer)=15;
Line 758: Line 824:
 </code> </code>
  
-xavps are read and write variables. You can create multilevel xavps, as xavps may contain xavps.+xavps are read and write variables.
  
 +===== $xavu(id) - XAVUs =====
 +
 +Similar to XAVPs, but with single value items, therefore there are no indexes in the naming format. XAVUs are also stored in transaction context and destroyed when the transaction is terminated.
 +
 +Examples:
 +
 +<code c>
 +$xavu(x) = 123; # <- set the value
 +$xavu(x) = 234; # <- update to the value, not adding to a list like for xavps
 +$xavu(x) = $null; # <- delete the xavu
 +$xavu(a=>b) = "xyz"; # <- two level naming supported
 +</code>
 +
 +===== $xavi(id) - XAVIs =====
 +
 +Similar to XAVPs, but with key names are case insensitive. XAVIs are also stored in transaction context and destroyed when the transaction is terminated.
 +
 +
 +Examples:
 +
 +<code c>
 +$xavi(WhatEver=>FoO) = 123; # <- set the value
 +# $xavi(whatever[0]=>foo) == 123
 +</code>
 ===== $hdr(name) - Headers ===== ===== $hdr(name) - Headers =====
  
Line 1850: Line 1940:
 ==== $tls_peer_server_name ==== ==== $tls_peer_server_name ====
 The SNI server name of the peer The SNI server name of the peer
 +
 +==== $tls_peer_raw_cert ====
 +The raw PEM-encoded client certificate. String type.
 +
 +==== $tls_my_raw_cert ====
 +The raw PEM-encoded client certificate. String type.
 +
 +==== $tls_peer_urlencoded_cert ====
 +The PEM-encoded client certificate, urlencoded. String type.
 +
 +==== $tls_my_urlencoded_cert ====
 +The PEM-encoded client certificate, urlencoded. String type.
 ===== SIP Message Attributes ===== ===== SIP Message Attributes =====
  
cookbooks/devel/pseudovariables.1584430997.txt.gz · Last modified: 2020/03/17 08:43 by miconda