|
@@ -0,0 +1,1364 @@
|
|
|
+<!-- Drouting Module User's Guide -->
|
|
|
+
|
|
|
+<chapter>
|
|
|
+ <title>&adminguide;</title>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Overview</title>
|
|
|
+ <section>
|
|
|
+ <title>Introduction</title>
|
|
|
+
|
|
|
+ <para>Dynamic Routing is a module for selecting (based on multiple
|
|
|
+ criteria) the the best gateway/destination to be used for delivering a
|
|
|
+ certain call. Least Cost Routing (LCR) is a special case of dynamic
|
|
|
+ routing - when the rules are ordered based on costs. Dynamic Routing
|
|
|
+ comes with many features regarding routing rule selection:
|
|
|
+ </para>
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem><para>prefix based</para></listitem>
|
|
|
+ <listitem><para>caller/group based</para></listitem>
|
|
|
+ <listitem><para>time based</para></listitem>
|
|
|
+ <listitem><para>priority based</para></listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ <para>
|
|
|
+ , processing :
|
|
|
+ </para>
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem><para>stripping and prefixing</para></listitem>
|
|
|
+ <listitem><para>default rules</para></listitem>
|
|
|
+ <listitem><para>inbound and outbound processing</para></listitem>
|
|
|
+ <listitem><para>script route triggering</para></listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ <para>
|
|
|
+ and failure handling:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem><para>serial forking</para></listitem>
|
|
|
+ <listitem><para>weight based GW selection</para></listitem>
|
|
|
+ <listitem><para>random GW selection</para></listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+</section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Features</title>
|
|
|
+ <para>
|
|
|
+ The dynamic routing implementation for &kamailio; is designed with the
|
|
|
+ following properties:
|
|
|
+ </para>
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ routing info (destinations, rules, groups) are stored in a database and
|
|
|
+ loaded into memory at start up time; reload at runtime via MI command
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ load balancing or random selection of the destinations (from a given set)
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ able to handle large volume of routing info (300K of rules) with minimal
|
|
|
+ speed/time and memory consumption penalties
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ script integration - Pseudo variables support in functions; scripting
|
|
|
+ route triggering when rules are matched
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ bidirectional behavior - inbound and outbound processing (strip and
|
|
|
+ prefixing when sending and receiving from a destination/GW)
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ blacklisting - the module allows definition of backlists based on the
|
|
|
+ destination IPs. This blacklists are to be used to prevent malicious
|
|
|
+ forwarding to GWs (based on DNS lookups) when the script logic does
|
|
|
+ none-GE forwarding (like foreign domains).
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ </itemizedlist>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Performance</title>
|
|
|
+ <para>
|
|
|
+ There were several tests performed regarding the performance of the module
|
|
|
+ when dealing with a large number of routing rules.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The tests were performed with a set of 383000 rules and to values were
|
|
|
+ measured:
|
|
|
+ </para>
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem><para>time to load from DB</para></listitem>
|
|
|
+ <listitem><para>used shared memory</para></listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ <para>
|
|
|
+ The time to load was varying between 4 seconds and 8 seconds, depending of
|
|
|
+ the caching of the DB client - the first load was the slowest (as the DB
|
|
|
+ query hits the disk drive); the following are faster as data is already
|
|
|
+ cached in the DB client. So technically speaking, the time to load (without
|
|
|
+ the time to query which is DB type dependent) is ~4 seconds
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ After loading the data into shared memory ~ 96M of memory were used
|
|
|
+ exclusively for the DR data.
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Routing Rule Definition</title>
|
|
|
+ <para>
|
|
|
+ Dynamic routing rules are stored in a database, in four tables:
|
|
|
+ </para>
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <para>one for storing the gateway definitions
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>one for storing the routing rule definitions
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>one for storing the users mappings over groups
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>one for storing a list of gateways, so you don't have to enter all
|
|
|
+ the elements every time you need it
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ <section>
|
|
|
+ <title>Gateway Addresses</title>
|
|
|
+ <para>
|
|
|
+ Default name for the table storing gateway addresses is
|
|
|
+ <quote>dr_gateways</quote>.
|
|
|
+ Gateway addresses are stored in a separate table because of need to
|
|
|
+ access them independent of Dynamic Routing processing (e.g., adding/
|
|
|
+ removing gateway PRI prefix before/after performing other operation
|
|
|
+ -- receiving/relaying to gateway).
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <table>
|
|
|
+ <title>Definition of table dr_gateways</title>
|
|
|
+ <tgroup cols="4">
|
|
|
+ <thead>
|
|
|
+ <row>
|
|
|
+ <entry>Column name</entry>
|
|
|
+ <entry>Type</entry>
|
|
|
+ <entry>Default value</entry>
|
|
|
+ <entry>Description</entry>
|
|
|
+ </row>
|
|
|
+ </thead>
|
|
|
+ <tbody>
|
|
|
+ <row>
|
|
|
+ <entry>gwid</entry>
|
|
|
+ <entry>integer</entry>
|
|
|
+ <entry>auto increment</entry>
|
|
|
+ <entry>unique identifier for GW</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>type</entry>
|
|
|
+ <entry>unsigned int</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>type/class of GW</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>address</entry>
|
|
|
+ <entry>varchar(128)</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>address of the gateway</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>strip</entry>
|
|
|
+ <entry>unsigned int</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>no of digits to strip</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>pri_prefix</entry>
|
|
|
+ <entry>varchar(255)</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>PRI prefix of the gateway</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>description</entry>
|
|
|
+ <entry>varchar(128)</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>description of the gateway</entry>
|
|
|
+ </row>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+ </table>
|
|
|
+
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Once a rule is matched, the STRIP number of digits are removed from the
|
|
|
+ username part of the RURI and then the PRI prefix has to be added to the
|
|
|
+ request URI before forwarding the call to the gateway.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ <table>
|
|
|
+ <title>Sample dr_gateways records</title>
|
|
|
+ <tgroup cols="6">
|
|
|
+ <thead>
|
|
|
+ <row>
|
|
|
+ <entry>gwid</entry>
|
|
|
+ <entry>type</entry>
|
|
|
+ <entry>address</entry>
|
|
|
+ <entry>strip</entry>
|
|
|
+ <entry>pri_prefix</entry>
|
|
|
+ <entry>description</entry>
|
|
|
+ </row>
|
|
|
+ </thead>
|
|
|
+ <tbody>
|
|
|
+ <row>
|
|
|
+ <entry>1</entry>
|
|
|
+ <entry>10</entry>
|
|
|
+ <entry>10.10.10.10:5080</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>2222</entry>
|
|
|
+ <entry>Gateway 1</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>2</entry>
|
|
|
+ <entry>10</entry>
|
|
|
+ <entry>10.10.10.10</entry>
|
|
|
+ <entry>2</entry>
|
|
|
+ <entry>3333</entry>
|
|
|
+ <entry>Gateway 2</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>3</entry>
|
|
|
+ <entry>20</entry>
|
|
|
+ <entry>10.10.10.11</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>Gateway 3</entry>
|
|
|
+ </row>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+ </table>
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Destination/GW lists</title>
|
|
|
+ <para>
|
|
|
+ For each rule, you can set a list of destinations to be used. The list is
|
|
|
+ comma or pipe separated enumeration of the destinations. The module
|
|
|
+ will use (one by one) each destination from the list (in the given order).
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Also the module allows the usage of groups in the destination lists. A
|
|
|
+ group of destinations is delimited by semi-colon char. inside the whole
|
|
|
+ destination list ( like: 2,4;5,78,23;4;7;2 ). The destinations from
|
|
|
+ within a group may be act differently (like load-balancing, random
|
|
|
+ selection, etc), depending of the <quote>sort_order</quote> module
|
|
|
+ parameter - more about this is available under the module paramters
|
|
|
+ section.
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Routing Rules</title>
|
|
|
+ <para>
|
|
|
+ Default name for the table storing rule definitions is
|
|
|
+ <quote>dr_rules</quote>.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ <table>
|
|
|
+ <title>Definition of dr_rules table</title>
|
|
|
+ <tgroup cols="4">
|
|
|
+ <thead>
|
|
|
+ <row>
|
|
|
+ <entry>Column name</entry>
|
|
|
+ <entry>Type</entry>
|
|
|
+ <entry>Default</entry>
|
|
|
+ <entry>Description</entry>
|
|
|
+ </row>
|
|
|
+ </thead>
|
|
|
+ <tbody>
|
|
|
+ <row>
|
|
|
+ <entry>ruleid</entry>
|
|
|
+ <entry>integer</entry>
|
|
|
+ <entry>auto</entry>
|
|
|
+ <entry>UID of the rule</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>groupid</entry>
|
|
|
+ <entry>varchar(255)</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>list of routing group IDs</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>prefix</entry>
|
|
|
+ <entry>varchar(64)</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>destination prefix for this route</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>timerec</entry>
|
|
|
+ <entry>varchar(255)</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>time recurrence for this rule</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>priority</entry>
|
|
|
+ <entry>integer</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>priority of the rule</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>routeid</entry>
|
|
|
+ <entry>integer</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>route block to be execute</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>gwlist</entry>
|
|
|
+ <entry>varchar(255)</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>the list with GWs to be used</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>description</entry>
|
|
|
+ <entry>varchar(128)</entry>
|
|
|
+ <entry></entry>
|
|
|
+ <entry>description of this rule</entry>
|
|
|
+ </row>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+ </table>
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ <orderedlist numeration="loweralpha">
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>groupid column</emphasis>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Each user must be member of only one routing group. It must be
|
|
|
+ specified in user's profile.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>prefix column</emphasis>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Destination URI must start with prefix value to match the rule.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>time rec column</emphasis>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ A date-time expression that defines the time recurrence to match for
|
|
|
+ current rule. Time recurrences are based closely on the specification
|
|
|
+ of recurring intervals of time in the Internet Calendaring and Scheduling
|
|
|
+ Core Object Specification (calendar COS), RFC 2445. The set of attributes
|
|
|
+ used in routing rule specification is subset of time recurrence attributes
|
|
|
+ used by Call Processing Language (CPL). These attributes are (extracted
|
|
|
+ from CPL draft 09):
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ <table>
|
|
|
+ <title>Time recurrence attributes</title>
|
|
|
+ <tgroup cols="2">
|
|
|
+ <thead>
|
|
|
+ <row>
|
|
|
+ <entry>Attribute</entry>
|
|
|
+ <entry>Description</entry>
|
|
|
+ </row>
|
|
|
+ </thead>
|
|
|
+ <tbody>
|
|
|
+ <row>
|
|
|
+ <entry>dastard</entry>
|
|
|
+ <entry>Start of interval (RFC 2445 DATE-TIME)</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>duration</entry>
|
|
|
+ <entry>Length of interval (RFC 2445 DURATION)</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>freq</entry>
|
|
|
+ <entry>Frequency of recurrence (secondly,minutely,hourly, daily,weekly,
|
|
|
+ monthly, or yearly).</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>until</entry>
|
|
|
+ <entry>bound of recurrence (RFC 2445 DATE-TIME)</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>interval</entry>
|
|
|
+ <entry>How often the recurrence repeats</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>byday</entry>
|
|
|
+ <entry>List of days of the week</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>bymonthday</entry>
|
|
|
+ <entry>List of days of the month</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>byyearday</entry>
|
|
|
+ <entry>List of days of the year</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>byweekno</entry>
|
|
|
+ <entry>List of weeks of the year</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>bymonth</entry>
|
|
|
+ <entry>List of months of the year</entry>
|
|
|
+ </row>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+ </table>
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ The value stored in database has the format of:
|
|
|
+ <![CDATA[
|
|
|
+ <dtstart>|<duration>|<freq>|<until>|<interval>|<byday>|<bymonthday>|<byyearday>|<byweekno>|<bymonth>
|
|
|
+ ]]>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ When an attribute is not specified, the corresponding place must be left
|
|
|
+ empty, whenever another attribute that follows in the list has to be
|
|
|
+ specified.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Detailed description of time recurrence attributes:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>dtstart</emphasis> - specifies the beginning of the first
|
|
|
+ period.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>duration</emphasis> - specifies the duration of the period.
|
|
|
+ For a recurring interval, the <quote>duration</quote> parameter MUST
|
|
|
+ be small enough such that subsequent intervals do not overlap.
|
|
|
+ For non-recurring intervals, durations of any positive length are
|
|
|
+ permitted, zero-length duration means <quote>forever</quote>.
|
|
|
+ Negative-length durations are not allowed.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>freq</emphasis> - takes one of the following values:
|
|
|
+ <quote>daily</quote>,
|
|
|
+ to specify repeating periods based on an interval of a day or more;
|
|
|
+ <quote>weekly</quote>, to specify repeating periods based on an
|
|
|
+ interval of a week or more; <quote>monthly</quote>, to specify
|
|
|
+ repeating periods based on an interval of a month or more; and
|
|
|
+ <quote>yearly</quote>, to specify repeating periods based
|
|
|
+ on an interval of a year or more. These values are not case-sensitive.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>until</emphasis> - defines an iCalendar COS DATE or DATE-TIME
|
|
|
+ value which bounds the recurrence rule in an inclusive manner. If the
|
|
|
+ value specified by <quote>until</quote> is synchronized with the
|
|
|
+ specified
|
|
|
+ recurrence, this date or date-time becomes the last instance of the
|
|
|
+ recurrence. If not present, the recurrence is considered to repeat
|
|
|
+ forever.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>interval</emphasis> - contains a positive integer
|
|
|
+ representing how often the recurrence rule repeats. The default value
|
|
|
+ is <quote>1</quote>, meaning every day for a <quote>daily</quote> rule,
|
|
|
+ every week for a <quote>weekly</quote>
|
|
|
+ rule, every month for a <quote>monthly</quote> rule and every year for
|
|
|
+ a <quote>yearly</quote> rule.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>interval</emphasis> - contains a positive integer
|
|
|
+ representing how often the recurrence rule repeats. The default value
|
|
|
+ is <quote>1</quote>, meaning every day for a <quote>daily</quote> rule,
|
|
|
+ every week for a <quote>weekly</quote> rule, every
|
|
|
+ month for a <quote>monthly</quote> rule and every year for a
|
|
|
+ <quote>yearly</quote> rule.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>byday</emphasis> - specifies a comma-separated list of days
|
|
|
+ of the week. <quote>MO</quote> indicates Monday; <quote>TU</quote>
|
|
|
+ indicates Tuesday; <quote>WE</quote> indicates Wednesday;
|
|
|
+ <quote>TH</quote> indicates Thursday; <quote>FR</quote> indicates
|
|
|
+ Friday; <quote>SA</quote> indicates Saturday; <quote>SU</quote>
|
|
|
+ indicates Sunday. These values are not case-sensitive.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Each <quote>byday</quote> value can also be preceded by a positive
|
|
|
+ (+n) or negative (-n) integer. If present, this indicates the nth
|
|
|
+ occurrence of the specific day within the <quote>monthly</quote> or
|
|
|
+ <quote>yearly</quote> recurrence. For example, within a
|
|
|
+ <quote>monthly</quote> rule, +1MO (or simply 1MO) represents the first
|
|
|
+ Monday within the month, whereas -1MO represents the last Monday of
|
|
|
+ the month. If an integer modifier is not present, it means all days
|
|
|
+ of this type within the specified frequency. For example, within a
|
|
|
+ <quote>monthly</quote> rule, MO represents all Mondays within the month.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>bymonthday</emphasis> - parameter specifies a comma-separated
|
|
|
+ list of days of the month. Valid values are 1 to 31 or -31 to -1. For
|
|
|
+ example, -10 represents the tenth to the last day of the month.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>byyearday</emphasis> - specifies a comma-separated list of
|
|
|
+ days of the year. Valid values are 1 to 366 or -366 to -1. For example,
|
|
|
+ -1 represents the last day of the year (December 31st) and -306
|
|
|
+ represents the 306th to the last day of the year (March 1st).
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>byweekno</emphasis> - specifies a comma-separated list of
|
|
|
+ ordinals specifying weeks of the year. Valid values are 1 to 53 or
|
|
|
+ -53 to -1.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>bymonth</emphasis> - parameter specifies a comma-separated
|
|
|
+ list of months of the year. Valid values are 1 to 12.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+</para>
|
|
|
+<para>
|
|
|
+</para>
|
|
|
+ <para></para>
|
|
|
+ <para>
|
|
|
+ A recurrence is specified by including the <quote>freq</quote>
|
|
|
+ parameter, which indicates the type of recurrence rule. Parameters
|
|
|
+ other than <quote>dtstart</quote>
|
|
|
+ and <quote>duration</quote> SHOULD NOT be specified unless
|
|
|
+ <quote>freq</quote> is present.
|
|
|
+ </para>
|
|
|
+ <para></para>
|
|
|
+ <para>
|
|
|
+ If byxxx parameter values are found which are beyond the available
|
|
|
+ scope (ie, bymonthday=<quote>30</quote> in February), they are simply
|
|
|
+ ignored.
|
|
|
+ </para>
|
|
|
+ <sbr></sbr>
|
|
|
+ <para></para>
|
|
|
+ <para>
|
|
|
+ Byxxx parameters modify the recurrence in some manner. Byxxx rule
|
|
|
+ parts for a period of time which is the same or greater than the
|
|
|
+ frequency generally reduce or limit the number of occurrences of the
|
|
|
+ recurrence generated. For example, freq=<quote>daily</quote>
|
|
|
+ bymonth=<quote>1</quote> reduces the number of
|
|
|
+ recurrence instances from all days (if the <quote>bymonth</quote>
|
|
|
+ parameter is not present) to all days in January. Byxxx parameters for
|
|
|
+ a period of time less than the frequency generally increase or expand
|
|
|
+ the number of occurrences of the recurrence. For example,
|
|
|
+ freq=<quote>yearly</quote> bymonth=<quote>1,2</quote>
|
|
|
+ increases the number of days within the yearly recurrence set from 1
|
|
|
+ (if <quote>bymonth</quote> parameter is not present) to 2.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ If multiple Byxxx parameters are specified, then after evaluating the
|
|
|
+ specified <quote>freq</quote> and <quote>interval</quote> parameters,
|
|
|
+ the Byxxx parameters are
|
|
|
+ applied to the current set of evaluated occurrences in the following
|
|
|
+ order: <quote>bymonth</quote>, <quote>byweekno</quote>,
|
|
|
+ <quote>byyearday</quote>, <quote>bymonthday</quote>,
|
|
|
+ <quote>byday</quote>; then <quote>until</quote> is evaluated.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Here is an example of evaluating multiple Byxxx parameters.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ dtstart=<quote>19970105T083000</quote> duration=<quote>10M</quote>
|
|
|
+ freq=<quote>yearly</quote> interval=<quote>2</quote>
|
|
|
+ bymonth=<quote>1</quote> byday=<quote>SU</quote>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ First, the interval=<quote>2</quote> would be applied to
|
|
|
+ freq=<quote>yearly</quote> to arrive at <quote>every other year</quote>
|
|
|
+ . Then, bymonth=<quote>1</quote> would be applied to arrive at
|
|
|
+ <quote>every January, every other year</quote>. Then,
|
|
|
+ byday=<quote>SU</quote> would be applied to arrive at <quote>every
|
|
|
+ Sunday in January,
|
|
|
+ every other year, from 8:30 to 8:40 </quote>. The appropriate minutes
|
|
|
+ and hours have been retrieved from the <quote>dtstart</quote> and
|
|
|
+ <quote>duration</quote> parameters.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>priority column</emphasis>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ If many rules are eligible, choose the one with highest priority.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>routeid column</emphasis>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ If different than 0, then execute the route with the specified ID.
|
|
|
+ That is, a route which can be used to perform custom
|
|
|
+ operations on message. At this route, no modification is performed
|
|
|
+ at signaling level.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>gwlist column</emphasis>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ A comma separated list of gateway identifiers corresponding to a row in
|
|
|
+ table <quote>dr_gateways</quote>. The first gateway is tried first and if
|
|
|
+ failure the second one, and so one. If no gateway is left a negative
|
|
|
+ response is sent back to the user.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>Routing Rules Examples</emphasis>
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ <table align="center" frame= "all" pgwide="1">
|
|
|
+ <title>Sample dr_rules records</title>
|
|
|
+ <tgroup cols="8" align='left' colsep='1' rowsep='1'>
|
|
|
+ <thead>
|
|
|
+ <row>
|
|
|
+ <entry>ruleid</entry>
|
|
|
+ <entry>group</entry>
|
|
|
+ <entry>prefix</entry>
|
|
|
+ <entry>timerec</entry>
|
|
|
+ <entry>priority</entry>
|
|
|
+ <entry>routeid</entry>
|
|
|
+ <entry>gwlist</entry>
|
|
|
+ <entry>description</entry>
|
|
|
+ </row>
|
|
|
+ </thead>
|
|
|
+ <tbody>
|
|
|
+ <row>
|
|
|
+ <entry>1</entry>
|
|
|
+ <entry>6</entry>
|
|
|
+ <entry>0049</entry>
|
|
|
+ <entry>20040101T083000|10H|weekly|||MO,TU,WE,TH,FR</entry>
|
|
|
+ <entry>5</entry>
|
|
|
+ <entry>23</entry>
|
|
|
+ <entry>1,2</entry>
|
|
|
+ <entry>Rule 1</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>2</entry>
|
|
|
+ <entry>8</entry>
|
|
|
+ <entry>0049</entry>
|
|
|
+ <entry>20040101T083000</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>1,2</entry>
|
|
|
+ <entry>Rule 2</entry>
|
|
|
+ </row>
|
|
|
+ <row>
|
|
|
+ <entry>3</entry>
|
|
|
+ <entry>7,8,9</entry>
|
|
|
+ <entry>0049</entry>
|
|
|
+ <entry>20040101T083000</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>0</entry>
|
|
|
+ <entry>3</entry>
|
|
|
+ <entry>Rule 3</entry>
|
|
|
+ </row>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+ </table>
|
|
|
+
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ (The time recurrence for first rule is:
|
|
|
+ <quote>20040101T083000|10H|weekly|||MO,TU,WE,TH,FR</quote>)
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </listitem>
|
|
|
+</orderedlist>
|
|
|
+ </para>
|
|
|
+</section>
|
|
|
+
|
|
|
+</section>
|
|
|
+<section>
|
|
|
+ <title>Routing Rule Processing</title>
|
|
|
+ <para>
|
|
|
+ The module can be used to find out which is the best gateway to use for new
|
|
|
+ calls terminated to PSTN. The algorithm to select the rule is as follows:
|
|
|
+ <itemizedlist mark='bullet'>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ the module discovers the routing group of the originating user. This
|
|
|
+ step is skipped if a routing group is passed from the script as parameter.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ once the group is known, in the subset of the rules for this group the
|
|
|
+ module looks for the one that matches the destination based on "prefix"
|
|
|
+ column. The set of rules with the longest prefix is chosen. If no digit
|
|
|
+ from the prefix matches, the default rules are used (rules with no prefix)
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ within the set of rules is applied the time criteria, and the rule which
|
|
|
+ has the highest priority and matches the time criteria is selected to drive
|
|
|
+ the routing.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ Once found the rule, it may contain a route ID to execute. If a certain
|
|
|
+ flag is set, then the processing is stopped after executing the route
|
|
|
+ block.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ The rule must contain a gateway chain. The module will execute serial
|
|
|
+ forking for each address in chain. The next address in chain is used only
|
|
|
+ if the previously has failed.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ With the right gateway address found, the prefix (PRI) of the gateway is
|
|
|
+ added to the request URI and then the request is forwarded.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ If no rule is found to match the selection criteria an default action must
|
|
|
+ be taken (e.g., error response sent back). If the gateway in the chain has
|
|
|
+ no prefix the request is forwarded without adding any prefix to the request
|
|
|
+ URI.
|
|
|
+ </para>
|
|
|
+
|
|
|
+</section>
|
|
|
+
|
|
|
+</section>
|
|
|
+
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Dependencies</title>
|
|
|
+ <section>
|
|
|
+ <title>&kamailio; Modules</title>
|
|
|
+ <para>
|
|
|
+ The following modules must be loaded before this module:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>a database module</emphasis>.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>External Libraries or Applications</title>
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <para>
|
|
|
+ <emphasis>none</emphasis>.
|
|
|
+ </para>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+
|
|
|
+ </section>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Exported Parameters</title>
|
|
|
+ <section>
|
|
|
+ <title><varname>db_url</varname>(str)</title>
|
|
|
+ <para>
|
|
|
+ The database url.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis> Default value is <quote>NULL</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>db_url</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "db_url",
|
|
|
+ "mysql://opensips:opensipsrw@localhost/opensips")
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+ <section>
|
|
|
+ <title><varname>drd_table</varname>(str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the db table storing gateway addresses.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis> Default value is <quote>dr_gateways</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>drd_table</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "drd_table", "dr_gateways")
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+ <section>
|
|
|
+ <title><varname>drr_table</varname>(str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the db table storing routing rules.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis> Default value is <quote>dr_rules</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>drr_table</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "drr_table", "rules")
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>drg_table</varname>(str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the db table storing groups.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis> Default value is <quote>dr_groups</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>drg_table</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "drg_table", "groups")
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>drl_table</varname>(str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the db table storing definitions of destination lists (to
|
|
|
+ be used directly by the routing rules).
|
|
|
+ You will have a identifier to a group of gateways instead of having all the
|
|
|
+ members of the group as a individual elements.
|
|
|
+ Very useful to reuse a list of gateways in different places.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis> Default value is <quote>dr_gw_lists</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>drl_table</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "drl_table", "my_gw_lists")
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>sort_order</varname> (int)</title>
|
|
|
+ <para>
|
|
|
+ Defines how the destination list should be processed (ordering of
|
|
|
+ the elements). Possible modes are
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <emphasis>0</emphasis> - destination groups are ignored and all the
|
|
|
+ destinations are tried in the given order;
|
|
|
+ Ex: list 1,2;3,4,5;6 will lead to usage as 1,2,3,4,5,6
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <emphasis>1</emphasis> - the destinations from each group are
|
|
|
+ randomly arranged (only the two elements are randomly selected);
|
|
|
+ groups do maintain their order (as given); the resulting list is
|
|
|
+ used (with all the defined destinations).
|
|
|
+ Ex: 1,2;3,4,5;6 -> randomizer ->
|
|
|
+ (A) 2,1;4,3,5;6 -> usage 2,1,4,3,5,6
|
|
|
+ (B) 1,2;3,5,4;6 -> usage 1,2,3,5,4,6
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <emphasis>2</emphasis> - from each destination group, only a
|
|
|
+ single destination is randomly selected; groups do maintain their
|
|
|
+ order (as given);
|
|
|
+ Ex: 1,2;3,4,5;6 -> randomizer ->
|
|
|
+ (A) 2;4;6 -> usage 2,4,6
|
|
|
+ (B) 1;5;6 -> usage 1,5,6
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>0</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>sort_order</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "sort_order", 2)
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+<section>
|
|
|
+ <title><varname>ruri_avp</varname> (str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the avp for storing Request URIs to be later used
|
|
|
+ (alternative destiantions for the current one).
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>NULL</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>ruri_avp</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "ruri_avp", '$avp(dr_ruri)')
|
|
|
+modparam("drouting", "ruri_avp", '$avp(i:33)')
|
|
|
+...
|
|
|
+ </programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>attrs_avp</varname> (str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the avp for storing the attribute of the current selected
|
|
|
+ destination - once a new destination is selected (via the
|
|
|
+ use_next_gw() function), the AVP will be updated with the attrs of the
|
|
|
+ new used destination.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>NULL</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>attrs_avp</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "attrs_avp", '$avp(dr_attrs)')
|
|
|
+modparam("drouting", "atrrs_avp", '$avp(i:67)')
|
|
|
+...
|
|
|
+ </programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>define_blacklist</varname> (str)</title>
|
|
|
+ <para>
|
|
|
+ Defines a backlist based on a list of GW types - the list will contain
|
|
|
+ the IPs (no port, all protocols) of the GWs with the specified types.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ Multiple instances of this param are allowed.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>NULL</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>define_blacklist</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "define_blacklist", 'bl_name= 3,5,25,23')
|
|
|
+modparam("drouting", "define_blacklist", 'list= 4,2')
|
|
|
+...
|
|
|
+ </programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>use_domain</varname> (int)</title>
|
|
|
+ <para>
|
|
|
+ Flag to configure whether to use domain match when querying
|
|
|
+ database for user's routing group.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>1</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>use_domain</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "use_domain", 0)
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>drg_user_col</varname> (str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the column in group db table where the username is stored.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>username</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>drg_user_col</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "drg_user_col", "user")
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+ <section>
|
|
|
+ <title><varname>drg_domain_col</varname> (str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the column in group db table where the domain is stored.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>domain</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>drg_domain_col</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "drg_domain_col", "host")
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+ <section>
|
|
|
+ <title><varname>drg_grpid_col</varname> (str)</title>
|
|
|
+ <para>
|
|
|
+ The name of the column in group db table where the
|
|
|
+ group id is stored.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>groupid</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>drg_grpid_col</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "drg_grpid_col", "grpid")
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>fetch_rows</varname> (int)</title>
|
|
|
+ <para>
|
|
|
+ </para>
|
|
|
+ The number of rows that should be fetched from the result of a
|
|
|
+ query in rules db table.
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>2000</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>fetch_rows</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "fetch_rows", 1500)
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title><varname>force_dns</varname> (int)</title>
|
|
|
+ <para>
|
|
|
+ Force DNS resolving of GW/destination names (if not IPs) during
|
|
|
+ startup. If not enabled, the GW name will be blindly used during
|
|
|
+ routing.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ <emphasis>Default value is <quote>1 (enabled)</quote>.
|
|
|
+ </emphasis>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title>Set <varname>force_dns</varname> parameter</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+modparam("drouting", "force_dns", 0)
|
|
|
+...
|
|
|
+ </programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+</section>
|
|
|
+
|
|
|
+<section>
|
|
|
+ <title>Exported Functions</title>
|
|
|
+ <section>
|
|
|
+ <title>
|
|
|
+ <function moreinfo="none">do_routing("[groupID]")</function>
|
|
|
+ </title>
|
|
|
+ <para>
|
|
|
+ Function to trigger routing of the message according to the
|
|
|
+ rules in the database table and the configured parameters.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The module can take one optional parameter: the routing group the
|
|
|
+ caller belongs to - this may be a static numerical value or an AVP
|
|
|
+ specification. If none specified, the function will automatically
|
|
|
+ try to query the dr_group table to get this information.
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title><function>do_routing</function> usage</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+do_routing();
|
|
|
+...
|
|
|
+do_routing("0");
|
|
|
+...
|
|
|
+do_routing("$avp(i:10)");
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>
|
|
|
+ <function moreinfo="none">use_next_gw()/next_routing()</function>
|
|
|
+ </title>
|
|
|
+ <para>
|
|
|
+ The function takes the next available destination (set by do_routing,
|
|
|
+ as alternative destinations) and push it into RURI. Note that the
|
|
|
+ function just sets the RURI (nothing more).
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ If a new RURI is set, the used destination is removed from the
|
|
|
+ pending set of alternative destinations.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The function returns true only if a new RURI was set. False
|
|
|
+ is returned is no other alternative destinations are found or in case
|
|
|
+ of internal processing error.
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title><function>use_next_gw</function> usage</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+if (use_next_gw()) {
|
|
|
+ t_relay();
|
|
|
+ exit;
|
|
|
+}
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>
|
|
|
+ <function moreinfo="none">goes_to_gw([type])</function>
|
|
|
+ </title>
|
|
|
+ <para>
|
|
|
+ Function returns true if the destination of the current request
|
|
|
+ (destination URI or Request URI) points (as IP) to one of the gateways.
|
|
|
+ There no DNS lookups done if the domain part of the URI is not an IP.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ This function does not change anything in the message.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The function can take one optional parameter:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <emphasis>type</emphasis> (optional) - GW/destination
|
|
|
+ type to be checked
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title><function>goes_to_gw</function> usage</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+if (goes_to_gw("1")) {
|
|
|
+ sl_send_reply("403","Forbidden");
|
|
|
+ exit;
|
|
|
+}
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>
|
|
|
+ <function moreinfo="none">is_from_gw([type])</function>
|
|
|
+ </title>
|
|
|
+ <para>
|
|
|
+ The function checks if the sender of the message is a gateway
|
|
|
+ from a certain group.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ This function can be used from REQUEST_ROUTE, FAILURE_ROUTE and
|
|
|
+ ONREPLY_ROUTE
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The function can take one optional parameter:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <emphasis>type</emphasis> (optional) - GW/destination type
|
|
|
+ to be checked
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <emphasis>flags</emphasis> - if message is a request and
|
|
|
+ the GW has a STRIP defined, then apply it if GW is source.
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title><function>is_from_gw</function> usage</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+if (is_from_gw("1") {
|
|
|
+}
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>
|
|
|
+ <function moreinfo="none">is_from_gw( type, [flag])</function>
|
|
|
+ </title>
|
|
|
+ <para>
|
|
|
+ The function checks if the sender of the message is a gateway
|
|
|
+ from a certain group.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ The function can take two parameters:
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <emphasis>type</emphasis> (mandatory) - GW/destination
|
|
|
+ type to be checked
|
|
|
+ </listitem>
|
|
|
+ <listitem>
|
|
|
+ <emphasis>flags</emphasis> (optional) - if message is a
|
|
|
+ request and the GW has a STRIP defined, then apply it
|
|
|
+ if GW is source.
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+ </para>
|
|
|
+ <example>
|
|
|
+ <title><function>is_from_gw</function> usage</title>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+...
|
|
|
+if (is_from_gw("3","1") {
|
|
|
+}
|
|
|
+...
|
|
|
+</programlisting>
|
|
|
+ </example>
|
|
|
+ </section>
|
|
|
+</section>
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<section>
|
|
|
+ <title>Exported MI Functions</title>
|
|
|
+ <section>
|
|
|
+ <title>
|
|
|
+ <function moreinfo="none">dr_reload</function>
|
|
|
+ </title>
|
|
|
+ <para>
|
|
|
+ Command to reload routing rules from database.
|
|
|
+ </para>
|
|
|
+ <para>
|
|
|
+ It takes no parameter.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ MI FIFO Command Format:
|
|
|
+ </para>
|
|
|
+ <programlisting format="linespecific">
|
|
|
+ :dr_reload:fifo_reply
|
|
|
+ _empty_line_
|
|
|
+ </programlisting>
|
|
|
+ </section>
|
|
|
+</section>
|
|
|
+
|
|
|
+<section>
|
|
|
+ <title>Installation</title>
|
|
|
+ <para>
|
|
|
+ The module requires 3 table in OpenSIPS database: dr_groups,
|
|
|
+ dr_gateways, dr_rules. The SQL syntax to create them can be
|
|
|
+ found in drouting-create.sql script in the database directories
|
|
|
+ in the opensips/scripts folder. You can also find the complete
|
|
|
+ database documentation on the project webpage, &kamailiodbdocslink;.
|
|
|
+ </para>
|
|
|
+</section>
|
|
|
+
|
|
|
+</chapter>
|
|
|
+
|