Freeswitch: Channel Variables

Channel variables are used to manipulate dialplan execution, to control call progress, and to provide options to applications. They play a pervasive role, as frequently consults channel variables as a way to customize processing prior to a channel's creation, during call progress, and after the channel hangs up. 

Variable Expansion

We rely on variable expansion to create flexible, reusable dialplans:

• $${variable} is expanded once when first parses the configuration on startup or after invoking reloadxml. It is suitable for variables that do not change, such as the domain of a single-tenant server. That is why $${domain} is referenced so frequently in the vanilla dialplan examples. 
• ${variable} is expanded during each pass through the dialplan, so it is used for variables that are expected to change, such as the ${destination_number} or ${sip_to_user} fields.

Channel Variables in the XML Dialplan

Channel variables are set, appropriately enough, with the set application:

 <action application="set" data="var_name=var value"/>
 

Reading channel variables requires the ${} syntax:

 <action application="log" data="INFO The value in the var_name chan var is ${var_name}"/>
 <condition field="${var_name}" expression="some text">
 

Scoped Variables

Channel variables used to be global to the session. As of b2c3199f, it is possible to set variables that only exist within a single application execution and any subsequent applications under it. For example, applications can use scoped variables for named input params:

 <action application="log" data="INFO myvar is '${myvar}'"/>
 <action application="log" data="%[myvar=Hello]INFO myvar is '${myvar}'"/>
 <action application="log" data="INFO myvar is '${myvar}'"/>
 <action application="myapp" data="%[var1=val1,var2=val2]mydata"/>
 

Channel Variables in Dial Strings

The variable assignment syntax for dial strings differs depending on which scope they should apply to:

• {foo=bar} is only valid at the beginning of the dial string. It will set the same variables on every channel, but does not do so for enterprise bridging/originate.
• <foo=bar> is only valid at the beginning of a dial string. It will set the same variables on every channel, including all thos in an enterprise bridging/originate.
• [foo=bar] goes before each individual dial string and will set the variable values specified for only this channel.

Examples

Set foo variable for all channels implemented and chan=1 will only be set for blah, while chan=2 will only be set for blah2:

 {foo=bar}[chan=1]sofia/default/blah@baz.com,[chan=2]sofia/default/blah2@baz.com
 

Set multiple variables by delimiting with commas:

 [var1=abc,var2=def,var3=ghi]sofia/default/blah@baz.com
 

To have variables in [] override variables in {}, set local_var_clobber=true inside {}. You must also set local_var_clobber=true when you want to override channel variables that have been exported to your b-legs in your dialplan. In this example, the legs for blah1@baz.com and johndoe@example.com would be set to offer SRTP (RTP/SAVP) while janedoe@acme.com would not receive an SRTP offer (she would see RTP/AVP instead):

 {local_var_clobber=true,rtp_secure_media=true}sofia/default/blah1@baz.com|sofia/default/johndoe@example.com|rtp_secure_media=false]sofia/default/janedoe@acme.com 
 

Escaping/Redefining Delimiters

Commas are the default delimiter inside variable assignment tags. In some cases (like in absolute_codec_string), we may need to define variables whose values contain literal commas that should not be interpreted as delimiters. 

We can redefine the delimiter for a variable using ^^ followed by the desired delimiter:

 ^^;one,two,three;four,five,six;seven,eight,nine
 

To set absolute_codec_string=PCMA@8000h@20i@64000b,PCMU@8000h@20i@64000b,G729@8000h@20i@8000b in a dial string:

 {absolute_codec_string=^^:PCMA@8000h@20i@64000b:PCMU@8000h@20i@64000b:G729@8000h@20i@8000b,leg_time_out=10,process_cdr=b_only}
 

This approach does not work when setting sip_h_*, sip_rh_*, and sip_ph headers. To pass a comma into the contents of a private header, escape the comma with a backslash:

 {sip_h_X-My-Header=one\,two\,three,leg_time_out=10,process_cdr=b_only}
 

Exporting Channel Variables in Bridge Operations

Variables from one call leg (A) can be exported to the other call leg (B) by using the export_vars variable. Its value is a comma separated list of variables that should propagate across calls.

 <action application="set" data="export_vars=myvar,myvar2,foo,bar"/>
 

To set a variable on the A-leg and add it to the export list, use the export application:

 <action application="export" data="myvar=true"/>
 

Using Channel Variables in Dialplan Condition Statements

Channel variables can be used in conditions, refer to XML Dialplan Conditions for more information.

(warning) Some channel variables may not be set during the dialplan parsing phrase. See Inline Actions.

Custom Channel Variables

We are not constrained to the channel variables that, its modules, and applications define. It is possible to set any number of unique channel variables for any purpose. They can also be logged in CDR. 

The set application can be used to set any channel variable:

 <action application="set" data="lead_id=2e4b5966-0aaf-11e8-ba89-0ed5f89f718b"/>
 <action application="set" data="campaign_id=333814"/>
 <action application="set" data="crm_tags=referral new loyal" /> 
 

In a command issued via mod_xml_rpc or mod_event_socket:

 originate {lead_id=2e4b5966-0aaf-11e8-ba89-0ed5f89f718,campaign_id=333814}sofia/mydomain.com/18005551212@1.2.3.4 15555551212
 

Values with spaces must be enclosed by quotes:

 originate {crm_tags='referral new loyal'}sofia/mydomain.com/18005551212@1.2.3.4 15555551212
 

Channel Variable Manipulation

Channel variables can be manipulated for varied results. For example, a channel variable could be trimmed to get the first three digits of a phone number. Manipulating Channel Variables discusses this in detail.

Channel Variable Scope Example

Consider this example:

 <extension name="test" continue="false">
   <condition field="destination_number" expression="^test([0-9]+)$">
     <action application="set" data="fruit=tomato" /> <!-- Set variable in local channel -->
     <action application="export" data="veggie=tomato" /> <!-- Set variable in local channel and export it to new channels we bridge to -->
     <action application="bridge" data="{meat=tomato}sofia/gateway/testaccount/1234" /><!-- bridge new channel and set variable only in new channel -->
   </condition>
 </extension>
 

Leg A (the channel that called the dial plan) will have these variables set:

 fruit: tomato
 veggie: tomato
 

Leg B (the channel created with sofia/gateway/testaccount/1234) will have these variables set:

 fruit: tomato
 meat: tomato
 

Accessing Channel Variables in Other Environments

In addition to the dialplan, channel variables can be set in other environments as well.

In a  module, written in C:

 switch_channel_set_variable(channel,"name","value");
 char* result = switch_channel_get_variable(channel,"name");  
 char* result = switch_channel_get_variable_partner(channel,"name");
 

In the console (or fs_cli, implemented in mod_commands): 

 uuid_getvar <uuid> <name>
 uuid_setvar <uuid> <name> [<value>]
 uuid_setvar_multi <uuid> <name>=<value>[;<name>=<value>[;...]] 
 

Alternatively, call uuid_dump to get all the variables, or use the eval command, adding the prefix variable_ to the key:

 uuid_dump <uuid>
 eval uuid:<uuid> ${variable_<name>}
 

In an event socket, just extend the above with the api prefix:

 api uuid_getvar <uuid> <name>
 

In Lua, there are several ways to interact with variables. In the freeswitch.Session() invocation that creates a new Session object, variables go in square brackets:

 s = freeswitch.Session("[myname=myvars]sofia/localhost/1003")
 

With the new Session object s:

 local result1 = s:getVariable("myname") -- "myvars"
 s:setVariable("name", "value")
 local result2 = s:getVariable("name") -- "value"
 

Info Application Variable Names (variable_xxxx)

Some variables, as shown from the info app, may have variable_ in front of their names. For example, if you pass a header variable called type from the proxy server, it will get displayed as variable_sip_h_type in. To access that variable, you should strip off the variable_, and just do ${sip_h_type}. Other variables shown in the info app are prepended with channel, which should be stripped as well. The example below show a list of info app variables and the corresponding channel variable names:

 <action application="set" data="initial_callee_id_name='${user_data(${dialed_extension}@${domain_name} var effective_caller_id_name)}'"/>
 

|

sip_codec_negotiation accepts «scrooge» & «greedy» as values. This means you can change codec negotiation on a per call basis. |