<?xml version="1.0" encoding='ISO-8859-1'?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [

<!-- Include general documentation entities -->
<!ENTITY % docentities SYSTEM "../../../../doc/docbook/entities.xml">
%docentities;

]>

<!-- Module User's Guide -->

<chapter>

	<title>&adminguide;</title>

	<section>
	<title>Overview</title>
	<para>
		This is a module that enables media streams to be proxied
		via an &rtp; proxy. The only &rtp; proxy currently known to work
		with this module is
		<ulink url="https://github.com/sipwise/rtpengine">Sipwise rtpengine</ulink>.
		The rtpengine module is a modified version of the original
		rtpproxy module using a new control protocol. The module is
		designed to be a drop-in replacement for the old module from
		a configuration file point of view, however due to the
		incompatible control protocol, it only works with &rtp; proxies
		which specifically support it.
	</para>
	</section>

	<section>
	<title>Recommended Version</title>
	<para>
		This control module is compatible with a wide range of versions
		of Sipwise rtpengine. The version numbers follow the schema
		<quote>mrXX.Y.ZZZ</quote>, with <quote>XX</quote> being the major
		release number, <quote>Y</quote> the minor release number, and
		<quote>ZZZ</quote> the patch level suffix. Releases with
		<quote>Y</quote> equalling 5 are LTS releases and receive bug
		fixes for several years. The recommended version therefore is
		either the latest LTS release on the latest patch level (e.g.
		<quote>mr12.5.1.46</quote>), or the latest non-LTS release if
		newer features are desired (e.g. <quote>mr13.4.1.5</quote>).

		This version of &kamailio; includes a field in the control
		protocol which is not supported by versions of rtpengine older
		than <quote>mr12.4</quote> and will trigger a warning log message
		in these older versions. This is purely cosmetic.
	</para>
	</section>

	<section>
	<title>Usage With Multiple RTPEngine Instances</title>
	<para>
		The rtpengine module can support multiple RTPEngine instances for
		balancing/distribution and control/selection purposes.
	</para>
	<para>
		The module allows definition of several sets of RTPEngines.
		Load-balancing will be performed over a set and the admin has the
		ability to choose what set should be used. The set is selected via
		its id - the id being defined with the set. Refer to the
		<quote>rtpengine_sock</quote> module parameter definition for syntax
		description.
	</para>
	<para>
		The balancing inside a set is done automatically by the module based on
		the weight of each RTPEngine from the set. The default weight is 1, if
		another RTPEngine should be used twice as often as the first one, one
		would specify the weight 2 for this server, for example.
	</para>
	<para>
		The selection of the set is done from script prior using
		rtpengine_delete(), rtpengine_offer(), rtpengine_answer() or
		rtpengine_manage() functions - see the set_rtpengine_set() function.
	</para>
	<para>
	        Another way to select the set is to define setid_avp
	        module parameter and assign setid to the defined avp
	        before calling rtpengine_offer() or rtpengine_manage()
	        function.  If forwarding of the requests fails and
	        there is another branch to try, remember to unset the
	        avp after calling rtpengine_delete() function.
	</para>
	<para>
		For backward compatibility reasons, a set with no id take by default
		the id 0. Also if no set is explicitly set before
		rtpengine_delete(), rtpengine_offer() or rtpengine_answer()
		the 0 id set will be used.
	</para>
	<para>
		IMPORTANT: if you use multiple sets, take care and use the same set for
		both rtpengine_offer()/rtpengine_answer() and rtpengine_delete()!!
		If the set was selected using setid_avp, the avp needs to be
		set only once before rtpengine_offer() or rtpengine_manage() call.
	</para>
	<para>
		From the current implementation point of view, the sets of rtpengine nodes
		are in shared memory(shm), so all processes can see a common list of nodes.
		There is no locking when setting the nodes enabled/disabled (to keep the
		memory access as fast as possible). Thus, problems related to node state
		might appear for concurrent processes that might set the nodes
		enabled/disabled (e.g. by fifo command). These robustness problems are overcome as follows.
	</para>

	<para>
		If the current process sees the selected node as disabled, the node is
		<emphasis>force tested</emphasis> before the current process actually
		accepts the disabled state. If the test succeeds, the process will set
		the node as enabled (but other concurrent process might still see it as disabled).
	</para>

	<para>
		If the current process sees the selected node as enabled, it does no additional checks
		and sends the command which will fail in case the machine is actually broken.
		The process will set the node as disabled (but other concurrent process might still see it as enabled).
	</para>

	<para>
		The 'kamctl fifo' commands (including rtpengine ones) are executed by an exclusive
		process which operate on the same shared memory node list.
	</para>

	<para>
		All the nodes are pinged in the beginning by all the processes,
		even if the node list is shared memory.
	</para>
	</section>

	<section>
	<title>Dependencies</title>
	<section>
		<title>&kamailio; Modules</title>
		<para>
		The following modules must be loaded before this module:
			<itemizedlist>
			<listitem>
			<para>
				<emphasis>tm module</emphasis> - (optional) if you want to
				have rtpengine_manage() fully functional
			</para>
			</listitem>
			<listitem>
			<para>
				<emphasis>lwsc module</emphasis> - (optional) if you plan to use
				<quote>wsapi</quote>	parameter
			</para>
			</listitem>
			</itemizedlist>
		</para>
	</section>
	<section>
		<title>External Libraries or Applications</title>
		<para>
		The following libraries or applications must be installed before
		running &kamailio; with this module loaded:
			<itemizedlist>
			<listitem>
			<para>
				<emphasis>None</emphasis>.
			</para>
			</listitem>
			</itemizedlist>
		</para>
	</section>
	</section>

	<section>
	<title>Parameters</title>
	<section id="rtpengine.p.rtpengine_sock">
		<title><varname>rtpengine_sock</varname> (string)</title>
		<para>
		Definition of socket(s) used to connect to (a set) &rtp; proxy. It may
		specify an IPv4/IPv6 UDP socket or a websocket URI.
		</para>
		<para>
		<emphasis>
			Default value is <quote>NONE</quote> (disabled).
		</emphasis>
		</para>
		<example>
		<title>Set <varname>rtpengine_sock</varname> parameter</title>
		<programlisting format="linespecific">
...
# single rtproxy
modparam("rtpengine", "rtpengine_sock", "udp:localhost:12221")
# IPv6 UDP
modparam("rtpengine", "rtpengine_sock", "udp6:localhost:12221")
# websocket
modparam("rtpengine", "rtpengine_sock", "ws://localhost:12221/")
# websocket with TLS
modparam("rtpengine", "rtpengine_sock", "wss://localhost:12221/")
# multiple rtproxies for LB with weights (missing weight defaults to 1)
modparam("rtpengine", "rtpengine_sock",
	"udp:localhost:12221=2 udp:localhost:12222=1")
# multiple sets of multiple rtproxies
modparam("rtpengine", "rtpengine_sock",
	"1 == udp:localhost:12221 udp:localhost:12222")
modparam("rtpengine", "rtpengine_sock",
	"2 == udp:localhost:12225")
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.p.rtpengine_disable_tout">
		<title><varname>rtpengine_disable_tout</varname> (integer)</title>
		<para>
		Once an &rtp; proxy was found unreachable and marked as disabled, the rtpengine
		module will not attempt to establish communication to that &rtp; proxy for
		rtpengine_disable_tout seconds.
		</para>
		<para>
		<emphasis>
			Default value is <quote>60</quote>.
		</emphasis>
		</para>
		<para>
			Can be set at runtime, e.g.:
			<programlisting>
			$ &sercmd; cfg.set_now_int rtpengine rtpengine_disable_tout 20
			</programlisting>
		</para>
		<example>
		<title>Set <varname>rtpengine_disable_tout</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "rtpengine_disable_tout", 20)
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.p.aggressive_redetection">
		<title><varname>aggressive_redetection</varname> (integer)</title>
		<para>
		This parameter determines what happens when all potential rtpengines are found
		to be unreachable. If enabled, the sip server will send pings to all rtpengines,
		else no rtpengine will be queried until its rtpengine_disable_tout timeout passes.
		</para>
		<para>
		<emphasis>
			Default value is <quote>0</quote> (disabled).
		</emphasis>
		</para>
		<para>
			Can be set at runtime, e.g.:
			<programlisting>
			$ &sercmd; cfg.set_now_int rtpengine aggressive_redetection 1
			</programlisting>
		</para>
		<example>
		<title>Set <varname>aggressive_redetection</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "aggressive_redetection", 1)
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.p.rtpengine_tout_ms">
		<title><varname>rtpengine_tout_ms</varname> (integer)</title>
		<para>
		Timeout value expressed in milliseconds in waiting for reply from &rtp; proxy.
		</para>
		<para>
		<emphasis>
			Default value is <quote>1000</quote>.
		</emphasis>
		</para>
		<para>
			Can be set at runtime, e.g.:
			<programlisting>
			$ &sercmd; cfg.set_now_int rtpengine rtpengine_tout_ms 1000
			</programlisting>
		</para>
		<example>
		<title>Set <varname>rtpengine_tout_ms</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "rtpengine_tout_ms", 2000)
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.p.rtpengine_allow_op">
		<title><varname>rtpengine_allow_op</varname> (integer)</title>
		<para>
		Enable this setting to allow finishing the current sessions while denying new sessions for deactivated nodes.
		</para>
		<para>Nodes can be <emphasis>manually deactivated </emphasis> via kamctl command i.e. "disabled(permanent)" nodes.
		Probably the manually deactivated machine is still running (did not crash).
		</para>
		<para>
		This is <emphasis>useful</emphasis> when deactivating a node for maintenance and
		reject new sessions but allow current ones to finish.
		</para>
		<para>
		The behaviour is the same for a rtpengine deleted table node.
		When the node is deleted from the table and the table reloaded (see nh_reload_rtpp)
		the node actually is disabled(permanent) and hidden for display.
		Next time the same node will be added in the table, and the database content
		reloaded, the re-activated node will be updated and re-displayed.
		</para>
		<para>
		<emphasis>
		Default value is <quote>0</quote> to keep the current behaviour.
		</emphasis>
		</para>
		<para>
		<emphasis>
		If value set to <quote>1</quote> it will send commands to all disabled nodes for the
		existing call.
		</emphasis>
		</para>
		<para>
		<emphasis>
		If value set to <quote>2</quote> it will send commands only to manually disabled
		nodes. (Not when timeout is disabled or node broken)
		</emphasis>
		</para>
		<example>
		<title>Set <varname>rtpengine_allow_op</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "rtpengine_allow_op", 1)
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.p.queried_nodes_limit">
		<title><varname>queried_nodes_limit</varname> (integer)</title>
		<para>
		The total number of nodes inside a set (sets are configurable via rtpengine_sock function) to be queried
		before giving up establishing a session. This brings more flexibility in case checking all rtpengines
		would take too long. Max limit is 30.
		</para>
		<para>
		<emphasis>
			By default all nodes in a set are tried before giving up communicating with the rtpengines.
		</emphasis>
		</para>
		<para>
			Can be set at runtime, e.g.:
			<programlisting>
			$ &sercmd; cfg.set_now_int rtpengine queried_nodes_limit 5
			</programlisting>
		</para>
		<example>
		<title>Set <varname>queried_nodes_limit</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "queried_nodes_limit", 5)
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.p.rtpengine_retr">
		<title><varname>rtpengine_retr</varname> (integer)</title>
		<para>
		How many times the module should retry to send and receive after
		timeout was generated.
		</para>
		<para>
		<emphasis>
			Default value is <quote>5</quote>.
		</emphasis>
		</para>
		<para>
			Can be set at runtime, e.g.:
			<programlisting>
			$ &sercmd; cfg.set_now_int rtpengine rtpengine_retr 5
			</programlisting>
		</para>
		<example>
		<title>Set <varname>rtpengine_retr</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "rtpengine_retr", 2)
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.p.extra_id_pv">
		<title><varname>extra_id_pv</varname> (string)</title>
		<para>
			The parameter sets the PV definition to use when the <quote>via-branch</quote>
			parameter is used on rtpengine_delete(), rtpengine_offer(),
			rtpengine_answer() or rtpengine_manage() command.
		</para><para>
			Default is empty, the <quote>via-branch</quote> parameter may not be used then.
		</para>
		<example>
		<title>Set <varname>extra_id_pv</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "extra_id_pv", "$avp(extra_id)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.setid_avp">
		<title><varname>setid_avp</varname> (string)</title>
		<para>
			The parameter defines an AVP that, if set,
			determines which &rtp; proxy set
			rtpengine_offer(), rtpengine_answer(),
			rtpengine_delete(), and rtpengine_manage()
			functions use.
		</para>
		<para>
			There is no default value.
		</para>
		<example>
		<title>Set <varname>setid_avp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "setid_avp", "$avp(setid)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.force_send_interface">
		<title><varname>force_send_interface</varname> (string)</title>
		<para>
			Forces all control messages between the &sip; proxy and
			the &rtp; proxy to be sent from the specified local
			interface. Both IPv4 and IPv6 addresses are supported. If
			not specified, the default interface selected by the
			operating system will be used.
			Note: when rtpengine_sock is an IPv6 link-local address,
			one _must_ set this parameter in order to successfully connect to RTP engine.
			This is necessarily because OS needs additional scope_id hint to communicate
			over IPv6 link locals. The scope_id is resolved based on the given IPv6.
		</para>
		<para>
			There is no default value.
		</para>
		<example>
		<title>Set <varname>force_send_interface</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "force_send_interface", "10.3.7.123")
modparam("rtpengine", "force_send_interface", "2001:8d8:1ff:10c0:9a90:96ff:fea8:fd99")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.read_sdp_pv">
		<title><varname>read_sdp_pv</varname> (string)</title>
		<para>
			If this parameter is set to a valid AVP or script var specifier, rtpengine
			will take the input SDP from this pv instead of the message body.
		</para>
		<para>
			There is no default value.
		</para>
		<example>
		<title>Set <varname>read_sdp_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "read_sdp_pv", "$var(sdp)")
...
route {
	...
	$var(sdp) = $rb + "a=foo:bar\r\n";
	rtpengine_manage();
}
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.write_sdp_pv">
		<title><varname>write_sdp_pv</varname> (string)</title>
		<para>
			If this parameter is set to a valid AVP or script var specifier, the
            		SDP returned by rtpengine in the offer/answer operations
            		is returned in the specified variable instead of the
            		message body.
		</para>
		<para>
			There is no default value.
		</para>
		<example>
		<title>Set <varname>write_sdp_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "write_sdp_pv", "$avp(sdp)")
...
route {
	...
	rtpengine_manage();
	set_body("$avp(sdp)a=baz123\r\n", "application/sdp");
}
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.write_sdp_pv_mode">
		<title><varname>write_sdp_pv_mode</varname> (int)</title>
		<para>
			If this parameter is set to 1, the returned SDP is written to pv
			and also set to message body.
		</para>
		<para>
			Default value: 0 (write SDP only to pv).
		</para>
		<example>
		<title>Set <varname>write_sdp_pv_mode</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "write_sdp_pv", "$avp(sdp)")
modparam("rtpengine", "write_sdp_pv_mode", 1)
...
route {
	...
	rtpengine_manage();
	xinfo("new sdp: $avp(sdp)\n");
}
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.rtp_inst_pvar">
		<title><varname>rtp_inst_pvar</varname> (string)</title>
		<para>
			A pseudo variable to store the chosen RTP Engine IP address.
			If this parameter is set, the IP address and port of the instance chosen will be stored in the given variable.
		</para>
		<para>
			By default, this parameter is not set.
		</para>
		<example>
		<title>Set <varname>rtp_inst_pvar</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "rtp_inst_pvar", "$avp(RTP_INSTANCE)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.hash_table_size">
		<title><varname>hash_table_size</varname> (integer)</title>
		<para>
			To maintain information about a selected rtp machine node for a given call, entries are added in a hashtable of (callid, node) pairs.
			This parameter sets the size of the hash table. Default value is 256.
		</para>
		<para>
			NOTE: If configured size is <emphasis>less than</emphasis> 1, the size will be defaulted to 1.
		</para>
		<example>
		<title>Set <varname>hash_table_size</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "hash_table_size", 123)
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.hash_table_tout">
		<title><varname>hash_table_tout</varname> (integer)</title>
		<para>
			Number of seconds after an rtpengine hash table entry is marked for deletion.
			By default, this parameter is set to 3600 (seconds).
		</para>
		<para>
			To maintain information about a selected rtp machine node for a given call,
			entries are added in a hashtable of (callid, node) pairs.
			When command comes the callid is looked up in this table. If found, the
			chosen node is used. If not found, choose a new node, insert the callid in
			the hashtable and return the chosen node.
		</para>
		<para>
			NOTE: In the current implementation, the actual deletion happens <emphasis>on the fly</emphasis>,
			while insert/remove/lookup the hastable, <emphasis>only</emphasis>
			for the entries in the insert/remove/lookup path.
		</para>
		<para>
			NOTE: When configuring this parameter, one should consider maximum call time
			VS shared memory for unfinished calls.
		</para>
		<example>
		<title>Set <varname>hash_table_tout</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "hash_table_tout", 300)
...
</programlisting>
                </example>
        </section>




	<section id="rtpengine.p.db_url">
		<title><varname>db_url</varname> (string)</title>
		<para>
			The rtpengine database url. If present and valid, it activates database mode.
			In this mode the node information is read from database, not from configuration modparam parameters.
		</para>
		<para>
			By default, the database url is NULL (not set).
		</para>
		<example>
		<title>Set <varname>db_url</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "db_url", "mysql://pass@localhost/db")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.table_name">
		<title><varname>table_name</varname> (string)</title>
		<para>
			The rtpengine table name. If database mode is activated (i.e. valid db_url),
			sets the name of the rtpengine table, on startup.
		</para>
		<para>
			By default, the rtpengine table name is "rtpengine".
		</para>
		<para>
			NOTE: One needs to add the version of the rtpengine table in the version table.
			The current version is version 1.
		</para>
		<example>
		<title>Set <varname>table_name</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "table_name", "rtpengine_table_name")
...
</programlisting>
		</example>

		<example>
		<title>Setup <varname>rtpengine</varname> table</title>
<programlisting format="linespecific">
mysql> describe rtpengine;
+----------+------------------+------+-----+---------------------+-------+
| Field    | Type             | Null | Key | Default             | Extra |
+----------+------------------+------+-----+---------------------+-------+
| setid    | int(10) unsigned | NO   | PRI | 0                   |       |
| url      | varchar(64)      | NO   | PRI | NULL                |       |
| weight   | int(10) unsigned | NO   |     | 1                   |       |
| disabled | int(1)           | NO   |     | 0                   |       |
| stamp    | datetime         | NO   |     | 1900-01-01 00:00:01 |       |
+----------+------------------+------+-----+---------------------+-------+

mysql> select * from rtpengine;
+-------+----------------------------+--------+----------+---------------------+
| setid | url                        | weight | disabled | stamp               |
+-------+----------------------------+--------+----------+---------------------+
|     0 | udp:rtpengine1.domain:8800 |      1 |        0 | 2016-03-10 10:30:54 |
|     0 | udp:rtpengine2.domain:8800 |      1 |        1 | 2016-03-10 10:30:54 |
+-------+----------------------------+--------+----------+---------------------+

mysql> select * from version;
+---------------------------+---------------+
| table_name                | table_version |
+---------------------------+---------------+
| rtpengine                 |             1 |
+---------------------------+---------------+
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.setid_col">
		<title><varname>setid_col</varname> (string)</title>
		<para>
			Column name for the "setid" in the rtpengine table.
			If database mode is activated (i.e. valid db_url),
			set the setid of rtp nodes according to this column, on startup.
			The MySQL value for this column should be INT UNSIGNED.
		</para>
		<para>
			By default, the column name is "setid".
		</para>
		<example>
		<title>Set <varname>setid_col</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "setid_col", "setid_column_name")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.url_col">
		<title><varname>url_col</varname> (string)</title>
		<para>
			Column name for the url in the rtpengine table. If database mode is activated (i.e. valid db_url),
			set the url of rtp nodes according to this column, on startup.
			The MySQL value for this column should be VARCHAR.
		</para>
		<para>
			By default, the column name is "url".
		</para>
		<example>
		<title>Set <varname>url_col</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "url_col", "url_column_name")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.weight_col">
		<title><varname>weight_col</varname> (string)</title>
		<para>
			Column name for weight in the rtpengine table. If database mode is activated (i.e. valid db_url),
			set the weight of rtp nodes according to this column, on startup. The column value has
			priority over the URL weight.
			The MySQL value for this column should be INT UNSIGNED.
		</para>
		<para>
			By default, the column name is "weight".
		</para>
		<example>
		<title>Set <varname>weight_col</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "weight_col", "weight_column_name")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.disabled_col">
		<title><varname>disabled_col</varname> (string)</title>
		<para>
			Column name in the rtpengine table. If database mode is activated (i.e. valid db_url),
			set the state of rtp nodes according to this column, on startup.
			The MySQL value for this column should be INT.
		</para>
		<para>
			By default, the column name is "disabled".
		</para>
		<example>
		<title>Set <varname>disabled_col</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "disabled_col", "disabled_column_name")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.setid_default">
		<title><varname>setid_default</varname> (integer)</title>
		<para>
			The default set of nodes to be used.
		</para>
		<para>
			By default, the setid is 0.
		</para>
		<para>
			NOTE that if setid_avp is configured, this value will be ignored and
			the active set will be chosen according to the setid_avp.
		</para>
		<example>
		<title>Set <varname>setid_default</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "setid_default", 11)
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.media_duration">
		<title><varname>media_duration</varname> (string)</title>
		<para>
			The name of a pseudovariable to be filled in with the length of the
			media being played back after a call to <quote>play_media</quote>,
			expressed in milliseconds. It's set to -1 if the length of the media
			could not be determined.
		</para>
		<para>
			By default, this parameter is not set.
		</para>
		<example>
		<title>Set <varname>media_duration</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "media_duration", "$avp(MEDIA_DURATION)")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.mos_min_pv">
		<title><varname>mos_min_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the minimum encountered MOS (Mean Opinion
			Score) value for the call. The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_min_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_pv", "$avp(mos_min)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_at_pv">
		<title><varname>mos_min_at_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the timestamp of when the minimum MOS value
			was encountered during the call, such as <quote>0:30</quote> for 30 seconds
			after the start of the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_min_at_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_at_pv", "$avp(mos_min_at)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_packetloss_pv">
		<title><varname>mos_min_packetloss_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of packetloss in percent
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_min_packetloss_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_packetloss_pv", "$avp(mos_min_packetloss)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_jitter_pv">
		<title><varname>mos_min_jitter_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of jitter in milliseconds
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_min_jitter_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_jitter_pv", "$avp(mos_min_jitter)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_roundtrip_pv">
		<title><varname>mos_min_roundtrip_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time in microseconds
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_min_roundtrip_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_roundtrip_pv", "$avp(mos_min_roundtrip)")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.mos_max_pv">
		<title><varname>mos_max_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the maximum encountered MOS value for the call.
			The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_max_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_pv", "$avp(mos_max)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_at_pv">
		<title><varname>mos_max_at_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the timestamp of when the maximum MOS value
			was encountered during the call, such as <quote>0:30</quote> for 30 seconds
			after the start of the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_max_at_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_at_pv", "$avp(mos_max_at)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_packetloss_pv">
		<title><varname>mos_max_packetloss_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of packetloss in percent
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_max_packetloss_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_packetloss_pv", "$avp(mos_max_packetloss)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_jitter_pv">
		<title><varname>mos_max_jitter_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of jitter in milliseconds
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_max_jitter_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_jitter_pv", "$avp(mos_max_jitter)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_roundtrip_pv">
		<title><varname>mos_max_roundtrip_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time in microseconds
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_max_roundtrip_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_roundtrip_pv", "$avp(mos_max_roundtrip)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_pv">
		<title><varname>mos_average_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) MOS value for the call.
			The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_average_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_pv", "$avp(mos_average)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_packetloss_pv">
		<title><varname>mos_average_packetloss_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) amount of packetloss
			in percent
			present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_average_packetloss_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_packetloss_pv", "$avp(mos_average_packetloss)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_jitter_pv">
		<title><varname>mos_average_jitter_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) amount of jitter
			in milliseconds
			present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_average_jitter_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_jitter_pv", "$avp(mos_average_jitter)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_roundtrip_pv">
		<title><varname>mos_average_roundtrip_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) packet round-trip
			time in milliseconds
			present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_average_roundtrip_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_roundtrip_pv", "$avp(mos_average_roundtrip)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_samples_pv">
		<title><varname>mos_average_samples_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the number of samples used to determine
			the other <quote>average</quote> MOS data points.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<example>
		<title>Set <varname>mos_average_samples_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_samples_pv", "$avp(mos_average_samples)")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.mos_A_label_pv">
		<title><varname>mos_A_label_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold a custom label used in rtpengine signalling.
			If set, all the statistics pseudovariables with the <quote>_A</quote> suffix will
			be filled in
			with statistics only from the call legs that match the label given in this
			variable. You need to fill this variable before invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote>. Variable value should match the
			<emphasis>label=</emphasis> flag on <quote>rtpengine_offer</quote>,
			<quote>rtpengine_answer</quote>, or <quote>rtpengine_manage</quote>.
		</para>
		<para>
			There is no default value.
		</para>
		<example>
		<title>Set <varname>mos_A_label_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_A_label_pv", "$avp(mos_A_label)")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.mos_min_A_pv">
		<title><varname>mos_min_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the minimum encountered MOS value for the call.
			The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_A_pv", "$avp(mos_min_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_at_A_pv">
		<title><varname>mos_min_at_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the timestamp of when the minimum MOS value
			was encountered during the call, such as <quote>0:30</quote> for 30 seconds
			after the start of the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_at_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_at_A_pv", "$avp(mos_min_at_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_packetloss_A_pv">
		<title><varname>mos_min_packetloss_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of packetloss in percent
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_packetloss_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_packetloss_A_pv", "$avp(mos_min_packetloss_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_jitter_A_pv">
		<title><varname>mos_min_jitter_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of jitter in milliseconds
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_jitter_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_jitter_A_pv", "$avp(mos_min_jitter_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_roundtrip_A_pv">
		<title><varname>mos_min_roundtrip_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time in microseconds
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_roundtrip_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_roundtrip_A_pv", "$avp(mos_min_roundtrip_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_roundtrip_leg_A_pv">
		<title><varname>mos_min_roundtrip_leg_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time of the specific call leg
			in microseconds at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_roundtrip_leg_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_roundtrip_leg_A_pv", "$avp(mos_min_roundtrip_leg_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_A_pv">
		<title><varname>mos_max_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the maximum encountered MOS value for the call.
			The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_A_pv", "$avp(mos_max_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_at_A_pv">
		<title><varname>mos_max_at_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the timestamp of when the maximum MOS value
			was encountered during the call, such as <quote>0:30</quote> for 30 seconds
			after the start of the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_at_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_at_A_pv", "$avp(mos_max_at_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_packetloss_A_pv">
		<title><varname>mos_max_packetloss_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of packetloss in percent
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_packetloss_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_packetloss_A_pv", "$avp(mos_max_packetloss_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_jitter_A_pv">
		<title><varname>mos_max_jitter_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of jitter in milliseconds
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_jitter_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_jitter_A_pv", "$avp(mos_max_jitter_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_roundtrip_A_pv">
		<title><varname>mos_max_roundtrip_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time in microseconds
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_roundtrip_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_roundtrip_A_pv", "$avp(mos_max_roundtrip_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_roundtrip_leg_A_pv">
		<title><varname>mos_max_roundtrip_leg_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time of the specific
			call leg in microseconds at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_roundtrip_leg_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_roundtrip_leg_A_pv", "$avp(mos_max_roundtrip_leg_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_A_pv">
		<title><varname>mos_average_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) MOS value for the call.
			The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_A_pv", "$avp(mos_average_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_packetloss_A_pv">
		<title><varname>mos_average_packetloss_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) amount of packetloss
			in percent
			present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_packetloss_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_packetloss_A_pv", "$avp(mos_average_packetloss_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_jitter_A_pv">
		<title><varname>mos_average_jitter_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) amount of jitter
			in milliseconds
			present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_jitter_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_jitter_A_pv", "$avp(mos_average_jitter_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_roundtrip_A_pv">
		<title><varname>mos_average_roundtrip_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) packet round-trip
			time in microseconds present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_roundtrip_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_roundtrip_A_pv", "$avp(mos_average_roundtrip_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_roundtrip_leg_A_pv">
		<title><varname>mos_average_roundtrip_leg_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) packet round-trip
			time of the specific call leg in microseconds present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_roundtrip_leg_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_roundtrip_leg_A_pv", "$avp(mos_average_roundtrip_leg_A)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_samples_A_pv">
		<title><varname>mos_average_samples_A_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the number of samples used to determine
			the other <quote>average</quote> MOS data points.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_samples_A_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_samples_A_pv", "$avp(mos_average_samples_A)")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.mos_B_label_pv">
		<title><varname>mos_B_label_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold a custom label used in rtpengine signalling.
			If set, all the statistics pseudovariables with the <quote>_B</quote> suffix will
			be filled in
			with statistics only from the call legs that match the label given in this
			variable. You need to fill this variable before invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote>. Variable value should match the
			<emphasis>label=</emphasis> flag on <quote>rtpengine_offer</quote>,
			<quote>rtpengine_answer</quote>, or <quote>rtpengine_manage</quote>.
		</para>
		<para>
			There is no default value.
		</para>
		<example>
		<title>Set <varname>mos_B_label_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_B_label_pv", "$avp(mos_B_label)")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.mos_min_B_pv">
		<title><varname>mos_min_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the minimum encountered MOS value for the call.
			The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_B_pv", "$avp(mos_min_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_at_B_pv">
		<title><varname>mos_min_at_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the timestamp of when the minimum MOS value
			was encountered during the call, such as <quote>0:30</quote> for 30 seconds
			after the start of the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_at_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_at_B_pv", "$avp(mos_min_at_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_packetloss_B_pv">
		<title><varname>mos_min_packetloss_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of packetloss in percent
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_packetloss_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_packetloss_B_pv", "$avp(mos_min_packetloss_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_jitter_B_pv">
		<title><varname>mos_min_jitter_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of jitter in milliseconds
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_jitter_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_jitter_B_pv", "$avp(mos_min_jitter_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_roundtrip_B_pv">
		<title><varname>mos_min_roundtrip_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time in microseconds
			at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_roundtrip_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_roundtrip_B_pv", "$avp(mos_min_roundtrip_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_min_roundtrip_leg_B_pv">
		<title><varname>mos_min_roundtrip_leg_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time of the specific call leg
			in microseconds at the time the minimum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_min_roundtrip_leg_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_min_roundtrip_leg_B_pv", "$avp(mos_min_roundtrip_leg_B)")
...
</programlisting>
		</example>
	</section>


	<section id="rtpengine.p.mos_max_B_pv">
		<title><varname>mos_max_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the maximum encountered MOS value for the call.
			The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_B_pv", "$avp(mos_max_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_at_B_pv">
		<title><varname>mos_max_at_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the timestamp of when the maximum MOS value
			was encountered during the call, such as <quote>0:30</quote> for 30 seconds
			after the start of the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_at_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_at_B_pv", "$avp(mos_max_at_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_packetloss_B_pv">
		<title><varname>mos_max_packetloss_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of packetloss in percent
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_packetloss_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_packetloss_B_pv", "$avp(mos_max_packetloss_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_jitter_B_pv">
		<title><varname>mos_max_jitter_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the amount of jitter in milliseconds
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_jitter_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_jitter_B_pv", "$avp(mos_max_jitter_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_roundtrip_B_pv">
		<title><varname>mos_max_roundtrip_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time in microseconds
			at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_roundtrip_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_roundtrip_B_pv", "$avp(mos_max_roundtrip_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_max_roundtrip_leg_B_pv">
		<title><varname>mos_max_roundtrip_leg_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the packet round-trip time of the specific
			call leg in microseconds at the time the maximum MOS value was encountered;
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_A_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_max_roundtrip_leg_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_max_roundtrip_leg_B_pv", "$avp(mos_max_roundtrip_leg_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_B_pv">
		<title><varname>mos_average_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) MOS value for the call.
			The value typically has a range of 1.0 through 5.0.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_B_pv", "$avp(mos_average_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_packetloss_B_pv">
		<title><varname>mos_average_packetloss_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) amount of packetloss
			in percent
			present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_packetloss_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_packetloss_B_pv", "$avp(mos_average_packetloss_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_jitter_B_pv">
		<title><varname>mos_average_jitter_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) amount of jitter
			in milliseconds
			present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_jitter_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_jitter_B_pv", "$avp(mos_average_jitter_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_roundtrip_B_pv">
		<title><varname>mos_average_roundtrip_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) packet round-trip
			time in microseconds present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_roundtrip_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_roundtrip_B_pv", "$avp(mos_average_roundtrip_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_roundtrip_leg_B_pv">
		<title><varname>mos_average_roundtrip_leg_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the average (median) packet round-trip
			time of the specific call leg in microseconds present throughout the call.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_roundtrip_leg_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_roundtrip_leg_B_pv", "$avp(mos_average_roundtrip_leg_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.mos_average_samples_B_pv">
		<title><varname>mos_average_samples_B_pv</varname> (string)</title>
		<para>
			The name of a pseudovariable to hold the number of samples used to determine
			the other <quote>average</quote> MOS data points.
		</para>
		<para>
			There is no default value.
		</para>
		<para>
			This value is filled in after invoking <quote>rtpengine_delete</quote>,
			<quote>rtpengine_query</quote>, or <quote>rtpengine_manage</quote> if the
			command resulted in a deletion of the call (or call branch).
		</para>
		<para>
			Only call legs matching the rtpengine label given in the <quote>mos_B_label_pv</quote>
			will be used in calculating this statistics value.
		</para>
		<example>
		<title>Set <varname>mos_average_samples_B_pv</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "mos_average_samples_B_pv", "$avp(mos_average_samples_B)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.dtmf_event_callid">
		<title><varname>dtmf_event_callid</varname> (string)</title>
		<para>
			The name of a pseudovariable to be filled in with the callid of the triggered dtmf event.
		</para>
		<para>
			By default, this parameter is not set.
		</para>
		<example>
		<title>Set <varname>dtmf_event_callid</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "dtmf_event_callid", "$avp(dtmf_event_callid)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.dtmf_event_source_tag">
		<title><varname>dtmf_event_source_tag</varname> (string)</title>
		<para>
			The name of a pseudovariable to be filled in with the source tag that triggered the dtmf event.
		</para>
		<para>
			By default, this parameter is not set.
		</para>
		<example>
		<title>Set <varname>dtmf_event_source_tag</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "dtmf_event_source_tag", "$avp(dtmf_event_source_tag)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.dtmf_event_timestamp">
		<title><varname>dtmf_event_timestamp</varname> (string)</title>
		<para>
			The name of a pseudovariable to be filled in with the timestamp when the dtmf event was triggered.
		</para>
		<para>
			By default, this parameter is not set.
		</para>
		<example>
		<title>Set <varname>dtmf_event_timestamp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "dtmf_event_timestamp", "$avp(dtmf_event_timestamp)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.dtmf_event">
		<title><varname>dtmf_event</varname> (string)</title>
		<para>
			The name of a pseudovariable to be filled in with the triggered DTMF value.
		</para>
		<para>
			By default, this parameter is not set.
		</para>
		<example>
		<title>Set <varname>dtmf_event</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "dtmf_event", "$avp(dtmf_event)")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.control_cmd_tos">
		<title><varname>control_cmd_tos</varname> (integer)</title>
		<para>
			The parameter is used to set the value of <quote>type of service (tos)</quote> for the
			control commands (such as rtpengine_offer(), rtpengine_answer() etc).
		</para>
		<para>
			There is no default value. By default this feature is not used.
		</para>
		<para>
			The values not falling into the range <quote>0-255</quote> will be simply ignored.
		</para>
		<example>
		<title>Set <varname>control_cmd_tos</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "control_cmd_tos", 144)
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.hash_algo">
		<title><varname>hash_algo</varname> (integer)</title>
		<para>
			Hashing algorithm to be used in node selection algorithm. Now there are 3 possibilities: legacy
			algorithm - 0 (very basic hash over callid), SHA1 - 1 (apply sha1 over the callid and calculate hash) or
			CRC32 - 2 (calculate crc32 sum over the callid).
		</para>
		<para>
			Default value is 0, legacy algorithm.
		</para>
		<para>
			The values not falling into the range <quote>0-2</quote> are ignored.
		</para>
		<example>
		<title>Set <varname>hash_algo</varname> parameter</title>
<programlisting format="linespecific">
...
### use SHA1 instead of legacy algorithm
modparam("rtpengine", "hash_algo", 1)

### use CRC32 instead of legacy algorithm
modparam("rtpengine", "hash_algo", 2)
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.wsapi">
		<title><varname>wsapi</varname> (string)</title>
		<para>
			Configure a backend API for websocket usage. Currently the only supported setting is
			<quote>lwsc</quote> (libwebsockets). If unset, then the websocket protocol cannot be used.
		</para>
		<example>
		<title>Set <varname>wsapi</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("rtpengine", "wsapi", "lwsc")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.dtmf_events_sock" xreflabel="dtmf_events_sock">
		<title><varname>dtmf_events_sock</varname> (string)</title>
		<para>
		Definition of IPv4/IPv6 UDP socket used to receive dtmf events from RTPEngine.
		</para>
		<para>
		DTMF events coming from RTPEngine will trigger rtpengine:dtmf-event route.
		</para>
		<para>
			<emphasis>
				Default value is <quote>NONE</quote> (disabled).
			</emphasis>
		</para>
		<example>
		<title>Set <varname>dtmf_events_sock</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "dtmf_events_sock", "127.0.0.1:2223")
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.p.ping_mode">
		<title><varname>ping_mode</varname> (integer)</title>
		<para>
		Specify if the RTPEngine instances have to be pinged at startup to
		detect if they are active. Set it to 0 to disable pinging and to 1
		to activate pinging.
		</para>
		<para>
		<emphasis>
			Default value is <quote>1</quote>.
		</emphasis>
		</para>
		<example>
		<title>Set <varname>ping_mode</varname> parameter</title>
		<programlisting format="linespecific">
...
modparam("rtpengine", "ping_mode", 0)
...
</programlisting>
		</example>
	</section>

	</section>

<section id="rtpengine.p.ping_interval">
	<title><varname>ping_interval</varname> (integer)</title>
	<para>
		Specify the interval in seconds between pings to all rtpengines registered.
	</para>
	<para>
		<emphasis>
			Default value is <quote>60</quote>.
		</emphasis>
	</para>
	<example>
	<title>Set <varname>ping_interval</varname> parameter</title>
	<programlisting format="linespecific">
...
modparam("rtpengine", "ping_interval", 10)
...
	</programlisting>
	</example>
</section>

	<section>
	<title>Functions</title>
	<section id="rtpengine.f.set_rtpengine_set">
		<title>
		<function moreinfo="none">set_rtpengine_set(setid[, setid])</function>
		</title>
		<para>
		Sets the ID of the &rtp; proxy set to be used for the next
		rtpengine_delete(), rtpengine_offer(), rtpengine_answer()
		or rtpengine_manage() command. The parameter can be an integer or
		a config variable holding an integer.
		</para>
		<para>
		A second set ID can be specified to daisy-chain two &rtp; proxies.
		The two set IDs must be distinct from each other and there must not
		be any overlap in the proxies present in both sets. In this use case,
		the request (offer, answer, etc) is first sent to an &rtp; proxy from
		the first set, which rewrites the &sdp; body and sends it back to the
		module. The rewritten &sdp; body is then used to make another request
		to an &rtp; proxy from the second set, which rewrites the &sdp; body
		another time and sends it back to the module to be placed back into the
		&sip; message. This is useful if you have a set of &rtp; proxies that
		the caller must use, and another distinct set of &rtp; proxies that the
		callee must use.
		</para>
		<para>
		This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
		BRANCH_ROUTE.
		</para>
		<example>
		<title><function>set_rtpengine_set</function> usage</title>
		<programlisting format="linespecific">
...
set_rtpengine_set("2");
rtpengine_offer();
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.f.rtpengine_offer">
		<title>
		<function moreinfo="none">rtpengine_offer([flags][,via-branch])</function>
		</title>
		<para>
		Rewrites &sdp; body to ensure that media is passed through
		an &rtp; proxy. To be invoked
		on INVITE for the cases the &sdp; bodies are in INVITE and 200 OK and on 200 OK
		when &sdp; bodies are in 200 OK and ACK.
		</para>
		<para>
		The function will return true on success and false (-1) on various failures,
		like using rtp_engine_offer() on a SIP MESSAGE request or communication with
		rtpengine fails.
		</para>
		<para>Meaning of the parameters is as follows:</para>
		<itemizedlist>
			<listitem>
			<para>
			<emphasis>flags</emphasis> - flags to turn on some features.
			</para>
			<para>The <quote>flags</quote> string is a list of space-separated items. Each item
			is either an individual token, or a token in <quote>key=value</quote> format. The
			possible tokens are described below.</para>
			<itemizedlist>
				<listitem><para>
				<emphasis>via-branch=...</emphasis> - Include the <quote>branch</quote>
				value of one of the <quote>Via</quote> headers in the request to the
				&rtp; proxy. Possible values are:
				<quote>1</quote> - use the first <quote>Via</quote> header;
				<quote>2</quote> - use the second <quote>Via</quote> header;
				<quote>auto</quote> - use the first <quote>Via</quote> header if this is
				a request, or the second one if this is a reply;
				<quote>extra</quote> - don't take the value from a header, but instead use
				the value of the <quote>extra_id_pv</quote> variable;
				<quote>next</quote> - use the branch ID generated by &kamailio; for the
				next outgoing branch;
				<quote>auto-next</quote> - use <quote>next</quote> in requests and
				<quote>1</quote> in replies;
				<quote>auto-extra</quote> - use <quote>extra</quote> in requests and
				<quote>1</quote> in replies.
				This can be used to create one media session per branch
				on the &rtp; proxy. When sending a subsequent <quote>delete</quote> command to
				the &rtp; proxy, you can then stop just the session for a specific branch when
				passing the flag '1' or '2' in the <quote>rtpengine_delete</quote>, or stop
				all sessions for a call when not passing one of those two flags there. This is
				especially useful if you have serially forked call scenarios where the &rtp; proxy
				gets an <quote>offer</quote> command for a new branch, and then a
				<quote>delete</quote> command for the previous branch, which would otherwise
				delete the full call, breaking the subsequent <quote>answer</quote> for the
				new branch. <emphasis>This flag is only supported by the Sipwise rtpengine
				&rtp; proxy at the moment!</emphasis>
				</para></listitem>
				<listitem><para>
				<emphasis>asymmetric</emphasis> - flags that UA from which message is
				received doesn't support symmetric &rtp;. Disables learning of endpoint addresses
				in the Sipwise rtpengine proxy.
				</para></listitem>
				<listitem><para>
				<emphasis>no-redis-update</emphasis> - this flag can be used by Kamailio in order
				to tell rtpengine not to persist the call into Redis upon receiving offer/answer()
				control commands. If flag is not set, default action is rtpengine persists call
				to redis.
				</para></listitem>
				<listitem><para>
				<emphasis>force-answer</emphasis> - force <quote>answer</quote>, that is,
				only rewrite &sdp; when corresponding session already exists
				in the &rtp; proxy. By default is on when the session is to be
				completed.  This is only necessary when the offer was sent by <function>rtpengine_offer()</function>, and
				the answer is handled by <function>rtpengine_manage()</function>.
				</para></listitem>
				<listitem><para>
				<emphasis>direction=...</emphasis> - this option specifies a logical network
				interface and should be given exactly twice. It enables &rtp; bridging between
				different addresses or networks of the same family (e.g. IPv4 to IPv4). The
				first instance of the option
				specifies the interface that the originator of this message should be using,
				while the second instance specifies the interface that the target should be
				using. For example, if the &sip; message was sent by an endpoint on a private
				network and will be sent to an endpoint on the public internet, you would use
				<quote>direction=priv direction=pub</quote> if those two logical network
				interfaces were called <quote>priv</quote> and <quote>pub</quote> in your
				&rtp; proxy's configuration respectively. The direction must only be specified
				in for initial &sdp; offer; answers or subsequent offers can omit this option.
				</para></listitem>
				<listitem><para>
				<emphasis>internal, external</emphasis> - shorthand for
				<quote>direction=internal</quote> and <quote>direction=external</quote>
				respectively. Useful for brevity or as legacy option if the &rtp; proxy only
				supports two network interfaces instead of multiple, arbitrarily named ones.
				</para></listitem>
				<listitem><para>
				<emphasis>address-family=...</emphasis> - instructs the &rtp; proxy that the
				recipient of this &sdp; body expects to see addresses of a particular family.
				Possible values are <quote>IP4</quote> and <quote>IP6</quote>. For example,
				if the &sdp; body contains IPv4 addresses but the recipient only speaks IPv6,
				you would use <quote>address-family=IP6</quote> to bridge between the two
				address families.
				</para><para>
				Sipwise rtpengine remembers the address family preference of each party after
				it has seen an &sdp; body from them. This means that normally it is only
				necessary to explicitly specify the address family in the <quote>offer</quote>,
				but not in the <quote>answer</quote>.
				</para><para>
				Note: Please note, that this will only work properly with non-dual-stack user-agents or with
				dual-stack clients according to RFC6157 (which suggest ICE for Dual-Stack implementations).
				This short-cut will not work properly with RFC4091 (ANAT) compatible clients, which suggests
				having different m-lines with different IP-protocols grouped together.
				</para></listitem>
				<listitem><para>
				<emphasis>force</emphasis> - instructs the &rtp; proxy to ignore marks
				inserted by another &rtp; proxy in transit to indicate that the
				session already goes through another proxy. Allows creating
				a chain of proxies. Not supported and ignored by Sipwise rtpengine.
				</para></listitem>
				<listitem><para>
				<emphasis>trust-address</emphasis> - flags that IP address in &sdp; should
				be trusted. Starting with rtpengine 3.8, this is the default behaviour.
				In older versions, without this flag the &rtp; proxy ignores the address in
				the &sdp; and uses source address of the &sip; message as media
				address which is passed to the &rtp; proxy.
				</para></listitem>
				<listitem><para>
				<emphasis>SIP-source-address</emphasis> - the opposite of
				<emphasis>trust-address</emphasis>. Restores the old default behaviour
				of ignoring endpoint addresses in the &sdp; body.
				</para></listitem>
				<listitem><para>
				<emphasis>received-from=IP</emphasis> - Configure the SIP-source-address IP
				explicitly, which will be useful when two kamailio is cascaded where first kamailio
				is handling NAT and second kamailio RTPEngine.
				</para></listitem>
				<listitem><para>
				<emphasis>replace-origin</emphasis> - flags that IP from the origin
				description (o=) should be also changed.
				</para></listitem>
				<listitem><para>
				<emphasis>replace-session-connection</emphasis> - flags to change the session-level
				&sdp; connection (c=) IP if media description also includes
				connection information.
				</para></listitem>
				<listitem><para>
				<emphasis>symmetric</emphasis> - flags that for the UA from which
				message is received, support symmetric &rtp; must be forced. Does nothing with
				the Sipwise rtpengine proxy as it is the default.
				</para></listitem>
				<listitem><para>
				<emphasis>repacketize=NN</emphasis> - requests the &rtp; proxy to perform
				re-packetization of &rtp; traffic coming from the UA which
				has sent the current message to increase or decrease payload
				size per each &rtp; packet forwarded if possible.  The NN is the
				target payload size in ms, for the most codecs its value should
				be in 10ms increments, however for some codecs the increment
				could differ (e.g. 30ms for GSM or 20ms for G.723).  The
				&rtp; proxy would select the closest value supported by the codec.
				This feature could be used for significantly reducing bandwith
				overhead for low bitrate codecs, for example with G.729 going
				from 10ms to 100ms saves two thirds of the network bandwith.
				Not supported by Sipwise rtpengine.
				</para></listitem>
				<listitem><para>
				<emphasis>ICE=...</emphasis> - controls the &rtp; proxy's behaviour
				regarding ICE attributes within the &sdp; body. Possible values
				are: <quote>force</quote> -
				discard any ICE attributes already present in the &sdp; body
				and then generate and insert new ICE data, leaving itself
				as the <emphasis>only</emphasis> ICE candidates;
				<quote>force-relay</quote> -
				discard any <quote>relay</quote> type ICE attributes already present
				in the &sdp; body and then generate and insert itself
				as the <emphasis>only</emphasis> ICE <quote>relay</quote> candidates;
				<quote>remove</quote> instructs the &rtp; proxy to discard
				any ICE attributes and not insert any new ones into the &sdp;.
				The default (if no <quote>ICE=...</quote> is given at all),
				new ICE data will only be generated
				if no ICE was present in the &sdp; originally; otherwise
				the &rtp; proxy will only insert itself as
				<emphasis>additional</emphasis> ICE candidate. Other
				&sdp; substitutions (c=, m=, etc) are unaffected by this flag.
				</para></listitem>
				<listitem><para>
				<emphasis>RTP, SRTP, DTLS, AVP, AVPF</emphasis> - These flags control the &rtp;
				transport protocol that should be used towards the recipient of
				the &sdp;. If none of them are specified, the protocol given in
				the &sdp; is left untouched. Otherwise, the <quote>SRTP</quote> flag indicates that
				SRTP should be used, while <quote>RTP</quote> indicates that both SRTP and AVPF should
                                not be used. <quote>AVPF</quote> indicates that the advanced RTCP profile with feedback
				messages should be used, and <quote>AVP</quote> indicates that the regular RTCP profile
				should be used. See also the next set of flags below.
				</para></listitem>
				<listitem><para>
				<emphasis>RTP/AVP, RTP/SAVP, UDP/TLS/RTP/SAVP, RTP/AVPF, RTP/SAVPF, UDP/TLS/RTP/SAVPF</emphasis> - these
				serve as an alternative, more explicit way to select between the different &rtp; protocols
				and profiles supported by the &rtp; proxy. For example, giving the flag
				<quote>RTP/SAVPF</quote> has the same effect as giving the two flags
				<quote>SRTP AVPF</quote>.
				</para></listitem>
				<listitem><para>
				<emphasis>to-tag</emphasis> - force inclusion of the <quote>To</quote> tag.
				Normally, the <quote>To</quote> tag is always included when present, except
				for <quote>delete</quote> messages. Including the <quote>To</quote> tag in
				a <quote>delete</quote> messages allows you to be more selective about which
				dialogues within a call are being torn down.
				</para></listitem>
				<listitem><para>
				<emphasis>to-tag=...</emphasis> - use the specified string as <quote>To</quote>
				tag instead of the actual <quote>To</quote> tag from the &sip; message, and
				force inclusion of the tag in the message as per above.
				</para></listitem>
				<listitem><para>
				<emphasis>from-tag=...</emphasis> - use the specified string as
				<quote>From</quote> tag instead of the actual <quote>From</quote>
				tag from the &sip; message.
				</para></listitem>
				<listitem><para>
				<emphasis>call-id=...</emphasis> - use the specified string as
				<quote>Call-ID</quote> instead of the actual <quote>Call-ID</quote>
				from the &sip; message.
				</para></listitem>
				<listitem><para>
				<emphasis>rtcp-mux-demux</emphasis> - if rtcp-mux (RFC 5761) was
				offered, make the &rtp; proxy accept the offer, but not offer it to the
				recipient of this message.
				</para></listitem>
				<listitem><para>
				<emphasis>rtcp-mux-reject</emphasis> - if rtcp-mux was offered, make the
				&rtp; proxy reject the offer, but still offer it to the recipient. Can be
				combined with <quote>rtcp-mux-offer</quote> to always offer it.
				</para></listitem>
				<listitem><para>
				<emphasis>rtcp-mux-offer</emphasis> - make the &rtp; proxy offer rtcp-mux
				to the recipient of this message, regardless of whether it was offered
				originally or not.
				</para></listitem>
				<listitem><para>
				<emphasis>rtcp-mux-accept</emphasis> - if rtcp-mux was offered, make the
				&rtp; proxy accept the offer and also offer it to the recipient of this
				message. Can be combined with <quote>rtcp-mux-offer</quote> to always offer it.
				</para></listitem>
				<listitem><para>
				<emphasis>media-address=...</emphasis> - force a particular media address to
				be used in the &sdp; body. Address family is detected automatically.
				</para></listitem>
				<listitem><para>
				<emphasis>TOS=...</emphasis> - change the IP TOS value for all outgoing &rtp;
				packets within the entire call in both directions. Only honoured in an
				<quote>offer</quote>, ignored for an <quote>answer</quote>. Valid values are
				0 through 255, given in decimal. If this option is not specified, the TOS
				value will revert to the default TOS (normally 184). A value of -1 may be used
				to leave the currently used TOS unchanged.
				</para></listitem>
				<listitem><para>
				<emphasis>delete-delay=...</emphasis> - override the default delay (in seconds)
				before a call is actually deleted from memory. Can be set to zero to effectuate
				immediate deletion. This option only makes sense for <emphasis>delete</emphasis>
				operations.
				</para></listitem>
				<listitem><para>
				<emphasis>strict-source</emphasis> - instructs the &rtp; proxy to check the
				source addresses of all incoming &rtp; packets and drop the packets if the
				address doesn't match.
				</para></listitem>
				<listitem><para>
				<emphasis>media-handover</emphasis> - the antithesis of
				<emphasis>strict-source</emphasis>. Instructs the &rtp; proxy not only to accept
				mismatching &rtp; source addresses (as it normally would), but also to accept
				them as the new endpoint address of the opposite media flow. Not recommended
				as it allows media streams to be hijacked by an attacker.
				</para></listitem>
				<listitem><para>
				<emphasis>DTLS=...</emphasis> - influence the behaviour of DTLS-SRTP. Possible
				values are <quote>no</quote> or <quote>off</quote> to suppress offering or
				accepting DTLS-SRTP, and <quote>passive</quote> to prefer participating in
				DTLS-SRTP in a passive role.
				</para></listitem>
				<listitem><para>
				<emphasis>SDES-off</emphasis> - don't offer SDES when it normally would. In an SRTP
				context, this leaves DTLS-SRTP as the only other option.
				</para></listitem>
				<listitem><para>
				<emphasis>SDES-unencrypted_srtp, SDES-unencrypted_srtcp,
				SDES-unauthenticated_srtp</emphasis> - these directly reflect the SDES session
				parameters from RFC 4568 and will make the &rtp; proxy offer these parameters
				when offering SDES.
				</para></listitem>
				<listitem><para>
				<emphasis>SDES-encrypted_srtp, SDES-encrypted_srtcp,
				SDES-authenticated_srtp</emphasis> - the opposites of the flags above. Useful
				if accepting these parameters is not desired and they should be rejected instead.
				</para></listitem>
				<listitem><para>
				<emphasis>SDES-nonew</emphasis> - don't add any new crypto suites into the offer.
				This means, offered SDES crypto suites will be accepted, meanwhile no new is going
				to be generated by RTPEngine. It takes precedence over the `SDES-no` and `SDES-only`
				flags, if used in combination.
				</para></listitem>
				<listitem><para>
				<emphasis>SDES-pad</emphasis> - RFC 4568 (section 6.1) is somewhat ambiguous regarding
				the base64 encoding format of `a=crypto` parameters added to an SDP body. The default
				interpretation is that trailing `=` characters used for padding should be omitted. With
				this flag set, these padding characters will be left in place.
				</para></listitem>
				<listitem><para>
				<emphasis>unidirectional</emphasis> - allows kernelization of one-way streams
				in the Sipwise rtpengine proxy. This is especially useful when the first call leg is handled
				by some rtpengine machine while the second call leg is handled by other rtpengine machine.
				</para></listitem>
				<listitem><para>
				<emphasis>record-call=on</emphasis> - instructs RTPEngine to record the session. Use
				it in rtpengine_offer() to start recording immediately and save the call metadata,
				as alternative to start_recording().
				</para></listitem>
				<listitem><para>
				<emphasis>metadata</emphasis> - a generic metadata string. The metadata will be  used when
                                recording calls to provide custom additional information. More details about this are found
                                in the rtpengine README.
				</para></listitem>
				<listitem><para>
				<emphasis>codec-transcode=...</emphasis> - allows codecs to be added to the list of offered codecs even
				if they were not present in the original list of codecs. In this case, the transcoding engine
				will be engaged. Only codecs that are supported for both decoding and encoding can be added in
				this manner. More details about this are found in the rtpengine README.
				</para></listitem>

				<listitem><para>
				<emphasis>codec-set=...</emphasis> - set codec options (bitrate etc) for codecs that are implicitly
				accepted for transcoding from the offering side.
				</para></listitem>

				<listitem><para>
				<emphasis>codec-strip=...</emphasis> - strips given codec from sdp
				</para></listitem>

				<listitem><para>
				<emphasis>codec-offer=...</emphasis> - offer given codec from sdp.
				More details about this are found in the rtpengine README.
				</para></listitem>

				<listitem><para>
				<emphasis>codec-except=...</emphasis> - same as <emphasis>codec-offer</emphasis> but preserves original order
				</para></listitem>

				<listitem><para>
				<emphasis>codec-mask=...</emphasis> - similar to strip except that codecs listed here will still be accepted
				and used for transcoding on the offering side. Useful only in combination with codec-transcode. <emphasis>all</emphasis> keyword
				can be used to mask all offered codecs
				</para></listitem>

				<listitem><para>
				<emphasis>codec-accept=...</emphasis> - similar to `mask` and `consume` but doesn't remove the codec from the list of
				offered codecs. This means that a codec listed under `accept` will still be offered
				to the remote peer, but if the remote peer rejects it, it will still be accepted
				towards the original offerer and then used for transcoding. It is a more selective
				version of what the `always transcode` flag does.
				</para></listitem>

				<listitem><para>
				<emphasis>codec-consume=...</emphasis> - identical to mask but enables the transcoding engine even if no other transcoding
				related options are given.
				</para></listitem>

				<listitem><para>
				<emphasis>T.38=decode</emphasis> - if the offered &sdp; contains a media section
				advertising T.38 over UDPTL, translate it to a regular audio media section
				over RTP. By default, PCMU and PCMA will be used as audio codecs, but that can
				be overridden using the codec options described above. Other transport protocols
				(e.g. SRTP) can also be selected in the same way. If the offered &sdp; does not
				contain a T.38 section, then this flag has no effect.
				</para></listitem>

				<listitem><para>
				<emphasis>T.38=force</emphasis> - any audio media section (over RTP) in the
				offered &sdp; will be translated into a T.38 section over UDPTL.
				</para></listitem>

				<listitem><para>
				<emphasis>T.38=stop</emphasis> - stops a previously established T.38 to audio
				gateway and reverts the session back to media passthrough. This is useful when
				handling a rejected T.38 offer.
				</para></listitem>

				<listitem><para>
				<emphasis>label=...</emphasis> - adds a label to a current stream, that later
				can be used to get call quality stats, see <quote>mos_A_label_pv</quote>
				and <quote>mos_B_label_pv</quote> parameters.
				</para></listitem>
			</itemizedlist>
			<para>
			 Check also the documentation of RTPEngine, these flags are documented there as well:
			<ulink url="https://github.com/sipwise/rtpengine">https://github.com/sipwise/rtpengine</ulink>.
			</para>
			</listitem>
			<listitem>
			<para>
			<emphasis>via-branch</emphasis> - provide the via-branch taken from one of SIP message Via headers.
			</para>
			<para>The <quote>via-branch</quote> parameter helps to match NG command (offer, answer, delete etc.) to particular monologue.
			It does the same job as the <quote>via-branch</quote> option flag, but it also enables alternative parsing behavior,
			when option flags are passed to rtpengine using bencode string format and is then parsed there.
			The benefit of the second approach is that any new flags supported by rtpengine
			will automatically be supported without having to worry about support in the control module.
			Regardless whether the flags parsing is done by the module or daemon,
			a functional behavior remains the same and has no difference in terms of SDP processing.
			Possible values are the same as for the <quote>via-branch</quote> option flag.
			If the newer approach is to be applied, but no <quote>via-branch</quote> is meant to be
			added for identfication, then <quote>none</quote> can be given instead.
			This parameter can be applied for the rtpengine versions equal or later than mr12.4.</para>
			</listitem>
		</itemizedlist>
		<para>
		This function can be used from ANY_ROUTE.
		</para>
		<example>
		<title><function>rtpengine_offer</function> usage</title>
		<programlisting format="linespecific">
route {
...
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (rtpengine_offer())
                t_on_reply("1");
        } else {
            t_on_reply("2");
        }
    }
    if (is_method("ACK") &amp;&amp; has_body("application/sdp"))
        rtpengine_answer();
...
}

onreply_route[1]
{
...
    if (has_body("application/sdp"))
        rtpengine_answer();
...
}

onreply_route[2]
{
...
    if (has_body("application/sdp"))
        rtpengine_offer();
...
}
...
if (has_body("application/sdp")) {
		if (rtpengine_offer("codec-mask=all codec-transcode=PCMU codec-transcode=PCMA"))
				t_on_reply("1");
}

...
</programlisting>
                </example>
		<example>
			<title><function>rtpengine_offer</function> usage to force transcoding from opus to PCMU</title>
		<programlisting format="linespecific">
route {
...
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (rtpengine_offer("codec-mask=opus codec-accept=opus codec-strip=PCMU codec-transcode=PCMU"))
                t_on_reply("1");
        }
    }
...
}

onreply_route[1]
{
...
    if (has_body("application/sdp"))
        rtpengine_answer("codec-strip=PCMU codec-strip=PCMA");
...
}
...
</programlisting>
                </example>


		<example>
		<title><function>rtpengine_offer</function> usage of via-branch parameter</title>
		<programlisting format="linespecific">
route {
...
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (rtpengine_offer("replace-origin replace-session-connection strict-source label=callee OSRTP-accept transport-protocol=RTP/AVP address-family=IP4", "auto-next"))
                t_on_reply("1");
        }
    }
...
}
		</programlisting>
		</example>
	</section>
	<section id="rtpengine.f.rtpengine_answer">
		<title>
			<function moreinfo="none">rtpengine_answer([flags][,via-branch])</function>
		</title>
		<para>
		Rewrites &sdp; body to ensure that media is passed through
		an &rtp; proxy. To be invoked
		on 200 OK for the cases the &sdp; bodies are in INVITE and 200 OK and on ACK
		when &sdp; bodies are in 200 OK and ACK.
		</para>
		<para>
		See rtpengine_offer() function description above for the meaning of the
		parameters.
		</para>
		<para>
		This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
		FAILURE_ROUTE, BRANCH_ROUTE.
		</para>
		<example>
		<title><function>rtpengine_answer</function> usage</title>
		<para>
		See rtpengine_offer() function example above for example.
		</para>
		</example>
	</section>
	<section id="rtpengine.f.rtpengine_info">
		<title>
		<function moreinfo="none">rtpengine_info([flags][,via-branch])</function>
		</title>
		<para>
		Send an updated offer to rtpengine. This is meant to be used when processing
		Trickle ICE &sdp; Fragments that are carried in &sip; INFO messages
		and are proxied to endpoints that do not support ICE. With a matching
		content type, the &sdp; fragment is used to update rtpengine's list of ICE
		candidates. No new &sdp; is returned and so the &sip; INFO message should
		be consumed after calling this function.
		</para>
		<para>
		While this function supports the same flags as <quote>rtpengine_offer</quote>
		et al, it is not normally necessary to provide any.
		</para>
		<para>
		This function can be used from ANY_ROUTE.
		</para>
		<example>
		<title><function>rtpengine_info</function> usage</title>
		<programlisting format="linespecific">
...
rtpengine_info();
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.f.rtpengine_delete">
		<title>
		<function moreinfo="none">rtpengine_delete([flags][,via-branch])</function>
		</title>
		<para>
		Tears down the RTP proxy session for the current call.
		This populates the statistics pseudovariables (such <quote>mos_min_pv</quote> etc).
		</para>
		<para>
		See rtpengine_offer() function description above for the meaning of the
		parameters. Note that not all flags make sense for a <quote>delete</quote>.
		</para>
		<para>
		This function can be used from ANY_ROUTE.
		</para>
		<example>
		<title><function>rtpengine_delete</function> usage</title>
		<programlisting format="linespecific">
...
rtpengine_delete();
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.f.rtpengine_destroy">
		<title>
		<function moreinfo="none">rtpengine_destroy([flags][,via-branch])</function>
		</title>
		<para>
		Same as rtpengine_delete().
		</para>
		<example>
		<title><function>rtpengine_destroy</function> usage</title>
		<programlisting format="linespecific">
...
rtpengine_destroy();
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.f.rtpengine_query">
		<title>
		<function moreinfo="none">rtpengine_query([flags][,via-branch])</function>
		</title>
		<para>
		Queries the &rtp; proxy about the current status and statistics of a running
		call. This populates the statistics pseudovariables (such <quote>mos_min_pv</quote> etc).
		</para>
		<para>
		See rtpengine_offer() function description above for the meaning of the
		parameters. Note that not all flags make sense for a <quote>query</quote>.
		</para>
		<para>
		This function can be used from ANY_ROUTE.
		</para>
		<example>
		<title><function>rtpengine_query</function> usage</title>
		<programlisting format="linespecific">
...
rtpengine_query();
...
</programlisting>
		</example>
	</section>
	<section id="rtpengine.f.rtpengine_query_v">
		<title>
		<function moreinfo="none">rtpengine_query_v(fmt, var)</function>
		</title>
		<para>
		Queries the &rtp; proxy about the current status and statistics of a running
		call, converts the response to JSON according to fmt and sets the variable
		var with the result.
		</para>
		<para>
		The fmt parameter can be 'j' for compacted JSON and 'jp' for pretty-formatted
		JSON.
		</para>
		<para>
		The var parameter has to be the name of a writable variable.
		</para>
		<para>
		This function can be used from ANY_ROUTE.
		</para>
		<example>
		<title><function>rtpengine_query_v</function> usage</title>
		<programlisting format="linespecific">
...
if(rtpengine_query_v("j", "$var(rdata)")) {
    xinfo("rtpengine query response: $var(rdata)\n");
}
...
</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.rtpengine_manage">
	<title>
		<function moreinfo="none">rtpengine_manage([flags][,via-branch])</function>
	</title>
		<para>
		Manage the RTPEngine session - it combines the functionality of
		rtpengine_offer(), rtpengine_answer() and rtpengine_delete(), detecting
		internally based on message type and method which one to execute.
		</para>
		<para>
		It can take the same parameters as <function>rtpengine_offer()</function>.
		The flags parameter to rtpengine_manage() can be a configuration variable
		containing the flags as a string.
		</para>
		<para>
		Functionality:
		</para>
		<itemizedlist>
		<listitem>
			<para>
			If INVITE with &sdp;, then do <function>rtpengine_offer()</function>
			</para>
		</listitem>
		<listitem>
			<para>
			If INVITE with &sdp;, when the tm module is loaded, mark transaction with
			internal flag FL_SDP_BODY to know that the 1xx and 2xx are for
			<function>rtpengine_answer()</function>
			</para>
		</listitem>
		<listitem>
			<para>
			If ACK with &sdp;, then do <function>rtpengine_answer()</function>
			</para>
		</listitem>
		<listitem>
			<para>
			If BYE or CANCEL, or called within a FAILURE_ROUTE[], then call
			<function>rtpengine_delete()</function>. Be careful with calling
			this function after resuming a suspended transaction (e.g., after
			t_continue()), because the context of executed route is FAILURE
			ROUTE (in other words, rtpengine_manage() in the route block of
			t_continue() does the same as in failure_route; use a branch route
			to engage rtpengine for a forwarded branch after resuming the
			transaction).
			</para>
		</listitem>
		<listitem>
			<para>
			It does nothing if used inside event_route[tm:branch-failure:...]
			</para>
		</listitem>
		<listitem>
			<para>
			If reply to INVITE with code >= 300 do <function>rtpengine_delete()</function>
			</para>
		</listitem>
		<listitem>
			<para>
			If reply with &sdp; to INVITE having code 1xx and 2xx, then
			do <function>rtpengine_answer()</function> if the request had &sdp; or tm is not loaded,
			otherwise do <function>rtpengine_offer()</function>
			</para>
		</listitem>
	</itemizedlist>

		<para>
		This function can be used from ANY_ROUTE.
		</para>
		<example>
		 <title><function>rtpengine_manage</function> usage</title>
		<programlisting format="linespecific">
...
rtpengine_manage();
...
</programlisting>
		</example>
        </section>

	<section id="rtpengine.f.start_recording">
		<title>
		<function moreinfo="none">start_recording([flags])</function>
		</title>
		<para>
		This function will send a signal to the &rtp; relay to record
		the &rtp; stream flowing through it. See also the option
		<quote>record-call=on</quote> for rtpengine_manage()/rtpengine_offer(),
		which offers an alternative for call recording, saving also call
		metadata from SDP.
		</para>
		<para>
		It can take the same parameters as <function>rtpengine_manage()</function>.
		The flags parameter to start_recording can be a configuration variable
		containing the flags as a string.
		The call-id flag can be used to start recording for a different call.
		</para>
		<para>
		This function can be used from REQUEST_ROUTE and ONREPLY_ROUTE.
		</para>
		<example>
		<title><function>start_recording</function> usage</title>
		<programlisting format="linespecific">
...
start_recording();
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.stop_recording">
		<title>
		<function moreinfo="none">stop_recording([flags])</function>
		</title>
		<para>
		This function will send a signal to the &rtp; relay to stop recording
		the &rtp; stream flowing through it. See also the option
		<quote>record-call=off</quote> for rtpengine_manage()/rtpengine_offer(),
		which offers an alternative for call recording.
		</para>
		<para>
		It can take the same parameters as <function>rtpengine_manage()</function>.
		The flags parameter to start_recording can be a configuration variable
		containing the flags as a string.
		The call-id flag can be used to stop recording for a different call.
		</para>
		<para>
		This function can be used from REQUEST_ROUTE and ONREPLY_ROUTE.
		</para>
		<example>
		<title><function>stop_recording</function> usage</title>
		<programlisting format="linespecific">
...
stop_recording();
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.block_dtmf">
		<title>
		<function moreinfo="none">block_dtmf([flags])</function>
		</title>
		<para>
		This function will instruct the &rtp; proxy to start blocking DTMF
		event packets (RFC 4733). DTMF events will still be processed by the
		&rtp; proxy, but they won't be forwarded to the receiving peer.
		</para>
		<para>
		The call-id flag can be used to block DTMF for a different call.
		</para>
		<para>
		Without any flags given, DTMF events will be blocked for the entire call.
		It's possible to block DTMF directionally only for individual participants.
		If the <quote>directional</quote> flag is given, DTMF events will be
		blocked for the UA with the currently matching <quote>From</quote> tag.
		Events can be blocked for a different UA either by specifying an alternative
		<quote>from-tag=...</quote>, or by matching UAs against the media address
		they advertised in the &sdp; using the <quote>address=...</quote> flag
		(which can contain either an IPv4 or IPv6 address).
		</para>
		<para>
		This function can be used from REQUEST_ROUTE and ONREPLY_ROUTE.
		</para>
		<example>
		<title><function>block_dtmf</function> usage</title>
		<programlisting format="linespecific">
...
block_dtmf();
block_dtmf("directional");
block_dtmf("address=192.168.42.42");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.unblock_dtmf">
		<title>
		<function moreinfo="none">unblock_dtmf([flags])</function>
		</title>
		<para>
		Reverses the effects of a previously issued <function>block_dtmf</function> call.
		See above for a description of which flags can be used.
		</para>
		<para>
		If DTMF events were previously blocked for individual UAs, then unblocking DTMF
		events for the entire call (i.e. no flags given) will not remove these blocks.
		The flag <quote>all</quote> can be used to achieve this.
		</para>
		<example>
		<title><function>unblock_dtmf</function> usage</title>
		<programlisting format="linespecific">
...
unblock_dtmf();
unblock_dtmf("all");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.block_media">
		<title>
		<function moreinfo="none">block_media([flags])</function>
		</title>
		<para>
		Analogous to <quote>block_dtmf</quote>, but blocks media &rtp; packets
		instead of DTMF events. When media is blocked, DTMF events still pass
		through the &rtp; proxy.
		</para>
		<para>
		See <quote>block_dtmf</quote> for a description of the flags that can be used.
		</para>
		<example>
		<title><function>block_media</function> usage</title>
		<programlisting format="linespecific">
...
block_media();
block_media("directional");
block_media("address=192.168.42.42");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.unblock_media">
		<title>
		<function moreinfo="none">unblock_media([flags])</function>
		</title>
		<para>
		Analogous to <quote>unblock_dtmf</quote>, but applies to media &rtp; packets instead
		of DTMF events.
		</para>
		<para>
		See <quote>unblock_dtmf</quote> for a description of the flags that can be used.
		</para>
		<example>
		<title><function>unblock_media</function> usage</title>
		<programlisting format="linespecific">
...
unblock_media();
unblock_media("all");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.silence_media">
		<title>
		<function moreinfo="none">silence_media([flags])</function>
		</title>
		<para>
		Identical to <quote>block_media</quote> except that media &rtp; packets are not
		simply blocked, but instead have their audio payload replaced by silence audio.
		This is only supported for certain trivial audio codecs (e.g. G.711, G.722).
		</para>
		<para>
		See <quote>block_dtmf</quote> for a description of the flags that can be used.
		</para>
		<example>
		<title><function>silence_media</function> usage</title>
		<programlisting format="linespecific">
...
silence_media();
silence_media("directional");
silence_media("address=192.168.42.42");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.unsilence_media">
		<title>
		<function moreinfo="none">unsilence_media([flags])</function>
		</title>
		<para>
		Identical to <quote>unblock_media</quote> except that it's the counterpart to
		<quote>silence_media</quote>.
		</para>
		<para>
		See <quote>unblock_dtmf</quote> for a description of the flags that can be used.
		</para>
		<example>
		<title><function>unsilence_media</function> usage</title>
		<programlisting format="linespecific">
...
unsilence_media();
unsilence_media("all");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.start_forwarding">
		<title>
		<function moreinfo="none">start_forwarding([flags])</function>
		</title>
		<para>
		Controls the PCM forwarding feature of the recording daemon. Unlike the
		recording feature, PCM forwarding can be done directionally for individual
		call participants only, therefore this command takes the same flags as
		the media/DTMF blocking commands above.
		</para>
		<para>
		See <quote>block_dtmf</quote> for a description of the flags that can be used.
		</para>
		<example>
		<title><function>start_forwarding</function> usage</title>
		<programlisting format="linespecific">
...
start_forwarding();
start_forwarding("directional");
start_forwarding("address=192.168.42.42");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.stop_forwarding">
		<title>
		<function moreinfo="none">stop_forwarding([flags])</function>
		</title>
		<para>
		Analogous to <quote>unblock_dtmf</quote>, but controls the PCM forwarding feature
		instead of DTMF blocking.
		</para>
		<para>
		See <quote>unblock_dtmf</quote> for a description of the flags that can be used.
		</para>
		<example>
		<title><function>stop_forwarding</function> usage</title>
		<programlisting format="linespecific">
...
stop_forwarding();
stop_forwarding("all");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.play_media">
		<title>
		<function moreinfo="none">play_media([flags])</function>
		</title>
		<para>
		Instructs rtpengine to play a prerecorded announcement to the selected
		call participant, either from a local file or from a file stored in a
		database. The participant must be selected using the same flags as are
		described under the <quote>block_dtmf</quote> function. If none of these
		flags are given, then the <quote>From</quote> tag from the current &sip;
		message context is used.
		</para>
		<para>
		If successful, the <quote>media_duration</quote> pseudovariable is filled
		in with the duration of the media being played, expressed in milliseconds.
		If the length of the media could not be determined, it's set to -1.
		</para>
		<example>
		<title><function>play_media</function> usage</title>
		<programlisting format="linespecific">
...
play_media("file=/use/share/media/hello.wav");
play_media("from-tag=tfugklbildfydrtuykgfv db-id=12345");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.stop_media">
		<title>
		<function moreinfo="none">stop_media([flags])</function>
		</title>
		<para>
		Stops the playback of media previously started by <quote>play_media</quote>.
		Media playback is automatically stopped when the end of the media file is reached,
		so this function is only useful to prematurely stop playback.
		</para>
		<example>
		<title><function>stop_media</function> usage</title>
		<programlisting format="linespecific">
...
stop_media();
stop_media("from-tag=5yqaeriguhxcikxj");
...
		</programlisting>
		</example>
	</section>

	<section id="rtpengine.f.play_dtmf">
		<title>
		<function moreinfo="none">play_dtmf([flags])</function>
		</title>
		<para>
		Injects a DTMF event into the media stream. Depending on which codecs were
		negotiated, this either injects an RFC 2833/4733 DTMF event, or an in-band PCM
		DTMF tone into the audio stream. The flag <quote>inject DTMF</quote> must have
		been present in both offer and answer messages when the call was established,
		which forces all audio to go through rtpengine's transcoding engine.
		</para>
		<para>
		Usage is similar to <quote>play_media</quote> with the following exceptions.
		The selected party is not the party that will receive the DTMF event, but rather
		the party which is generating the event. This is to support DTMF
		events that are carried in &sip; INFO messages. Instead of specifying a media file,
		a DTMF event code must be specified, as well as optionally a duration and the volume.
		The <quote>code</quote> can be a number 0 through 15, or a DTMF digit (0-9, A-D, *, #).
		The <quote>duration</quote> is specified in milliseconds and defaults to 250, within
		a range of 100-5000. The <quote>volume</quote> is specified in absolute decibels, with
		a default of -8 db.
		</para>
		<para>
		Multiple consecutive DTMF events can be queued up by calling this function multiple
		times consecutively. RTPengine will play out the DTMF events in sequence, separated
		by a default pause of 100 ms. An alternative pause length can be given through the
		<quote>pause</quote> option, between 100 and 5000 ms.
		</para>
		<example>
		<title><function>play_dtmf</function> usage</title>
		<programlisting format="linespecific">
...
play_dtmf("from-tag=5yqaeriguhxcikxj code=#");
play_dtmf("code=1 volume=5 duration=300 pause=150");
...
		</programlisting>
		</example>
	</section>


	</section>

	<section>
		<title>Exported Pseudo Variables</title>
		<section id="rtpengine.pv.rtpestat">
			<title><function moreinfo="none">$rtpestat</function></title>
			<para>
			Returns the &rtp; statistics from the &rtp; relay. The &rtp; statistics from the &rtp; relay
			are provided as a string and it does contain several packet counters. The statistics
			must be retrieved before the session is deleted	(before <function>rtpengine_delete()</function>).
			</para>

		<example>
		<title>$rtpestat Usage</title>
		<programlisting format="linespecific">
...
    append_hf("X-RTP-Statistics: $rtpestat\r\n");
...
    # $rtpestat = RTP: 54846 bytes, 1447 packets, 0 errors; RTCP: 336 bytes, 3 packets, 0 errors
...
		</programlisting>
		</example>
	        </section>
		<section id="rtpengine.pv.rtpstat">
			<title><function moreinfo="none">$rtpstat</function></title>
			<para>
				Same as $rtpestat.
			</para>
	        </section>

	</section>

	<section>
		<title>RPC Commands</title>

	<section id="rtpengine.r.reload">
			<title><function moreinfo="none">rtpengine.reload</function></title>
			<para>
				Reloads the database node table content <emphasis>if configured</emphasis>.
				Returns specific message related to success, failure and no db_url configured.
			</para>
			<para>
				NOTE: The current behaviour updates the nodes state or creates new ones or
				hides old ones, based on the database content. If allow_op modparam is enabled,
				the sessions are still allowed to finish for the hidden old nodes.
			</para>
			<para>
				The execution of this command is limited to 10 seconds intervals.
			</para>
			<example>
			<title>
				<function moreinfo="none">rtpengine.reload</function> usage</title>
			<programlisting format="linespecific">
...
$ &kamcmd; rtpengine.reload
...
			</programlisting>
			</example>
		</section>

		<section id="rtpengine.r.enable">
			<title><function moreinfo="none">rtpengine.enable proxy_url/all 0/1</function></title>
			<para>
			Enables a &rtp; proxy if the second parameter value is greater than 0. Disables it if a zero value is given.
			The first parameter is either a specific &rtp; proxy url (exactly as defined in
			the config file) or the keyword <emphasis>all</emphasis>.
			The second parameter value must be a number in decimal.
			</para>
			<para>
				When try to enable the &rtp; proxy, an application ping command is sent to it.
				If it fails, the proxy is not enabled.
				Displays <emphasis>success</emphasis> or <emphasis>fail</emphasis> when try to enable/disable.
			</para>
			<para>
			NOTE: If a &rtp; proxy is defined multiple times (in the same or different sets), all of its instances will be enabled/disabled.
			</para>
			<para>
			NOTE: If a &rtp; proxy is in the disabled permanent state and one tries to enable it, even if the ping fails,
			it is moved to a disabled temporary state and a recheck_ticks are given to it.
			While the recheck_ticks are grater than 0, the proxy is considered disabled temporary,
			and it is not taken into consideration for sending data.
			When the recheck_ticks are 0, the proxy is retested <emphasis>when trying to send data</emphasis>
			(not automatically retested), and data can be sent to it on success.
			</para>
			<para>
			NOTE: If you specify an IPv6 &rtp;, the proxy url must be prefixed  with <emphasis>::</emphasis>
			to escape the :: from the IPv6 address. See the example below.
			</para>
			<example>
			<title>
			<function moreinfo="none">rtpengine.enable</function> usage</title>
			<programlisting format="linespecific">
...
$ &kamcmd; rtpengine.enable udp:192.168.2.133:8081 0
$ &kamcmd; rtpengine.enable ::udp6:fe80::9a90:96ff:fea8:fd99:9999 1
$ &kamcmd; rtpengine.enable all 1
...
			</programlisting>
			</example>
		</section>

		<section id="rtpengine.r.show">
			<title><function moreinfo="none">rtpengine.show proxy_url/all</function></title>
			<para>
			Displays all the &rtp; proxies and their information: set and
			status (disabled or not, weight and recheck_ticks). If a &rtp; proxy has been disabled by
			nh_enable_rtpp mi command a "(permanent)" quote will appear when printing the disabled status.
			This is to differentiate from a temporary disable due to the proxy being not found responsive
			by kamailio. In addition, when disabled permanent, recheck_ticks have no meaning and "N\A"
			is printed instead of the value.
			</para>
			<para>
			It takes either a specific &rtp; proxy url (exactly as defined in
			the config file) or the keyword <emphasis>all</emphasis> as a parameter.
			</para>
			<para>
			NOTE: When specify the IPv6 &rtp; proxy url one must prefix it with <emphasis>::</emphasis>
			to escape the :: from the IPv6 address. See the example below.
			</para>
			<example>
			<title>
				<function moreinfo="none">rtpengine.show</function> usage</title>
			<programlisting format="linespecific">
...
$ &kamcmd; rtpengine.show udp:192.168.2.133:8081
$ &kamcmd; rtpengine.show ::udp6:fe80::9a90:96ff:fea8:fd99:9999
$ &kamcmd; rtpengine.show all
...
			</programlisting>
			</example>
		</section>

		<section id="rtpengine.m.ping">
			<title><function moreinfo="none">rtpengine.ping proxy_url/all</function></title>
			<para>
			Sends an application ping command to the &rtp; proxy. If the proxy does not respond,
			it will be disabled, but not permanent. If the proxy responds, no action is taken.
			Displays the ping result, i.e.
			<emphasis>success</emphasis> or <emphasis>fail</emphasis> when try to ping.
			</para>
			<para>
			It takes either a specific &rtp; proxy url (exactly as defined in
			the config file) or the keyword <emphasis>all</emphasis> as a parameter.
			</para>
			<para>
			NOTE: When specify the IPv6 &rtp; proxy url one must prefix it with <emphasis>::</emphasis>
			to escape the :: from the IPv6 address. See the example below.
			</para>
			<example>
			<title>
				<function moreinfo="none">rtpengine.ping</function> usage</title>
			<programlisting format="linespecific">
...
$ &kamcmd; rtpengine.ping udp:192.168.2.133:8081
$ &kamcmd; rtpengine.ping ::udp6:fe80::9a90:96ff:fea8:fd99:9999
$ &kamcmd; rtpengine.ping all
...
			</programlisting>
			</example>
		</section>

	    <section id="rtpengine.m.show_hash_total">
			<title><function moreinfo="none">rtpengine.get_hash_total</function></title>
			<para>
				Print the total number of hash entries in the hash table at a given moment.
			</para>
			<example>
			<title>
				<function moreinfo="none">rtpengine.get_hash_total</function> usage</title>
			<programlisting format="linespecific">
...
$ &kamcmd; rtpengine.get_hash_total
...
			</programlisting>
			</example>
		</section>

	</section>

	<section id="rtpengine.ex.event_routes">
        <title>Event routes</title>
        <section>
			<title>
			<function moreinfo="none">rtpengine:dtmf-event</function>
			</title>
			<para>
			When defined, the module calls event_route[rtpengine:dtmf-event]
			when a DTMF is received.
			</para>
			<programlisting  format="linespecific">
...
event_route[rtpengine:dtmf-event] {
    xlog("L_INFO", "callid: $avp(dtmf_event_callid)\n");
	xlog("L_INFO", "source_tag: $avp(dtmf_event_source_tag)\n");
	xlog("L_INFO", "timestamp: $avp(dtmf_event_timestamp)\n");
	xlog("L_INFO", "dtmf: $avp(dtmf_event)\n");
}
...
			</programlisting>
		</section>
    </section>
</chapter>
