b07550a0699a1c1dd6e0ef5375e846cb9ebdc8a3
[sip-router] / src / modules / drouting / README
1 Dynamic Routing Module
2
3    Voice Sistem SRL
4
5 Edited by
6
7 Ovidiu Sas
8
9 Edited by
10
11 Anca-Maria Vamanu
12
13    Copyright © 2005-2008 Voice Sistem SRL
14      __________________________________________________________________
15
16    Table of Contents
17
18    1. Admin Guide
19
20         1. Overview
21
22               1.1. Introduction
23               1.2. Features
24               1.3. Performance
25               1.4. Routing Rule Definition
26
27                     1.4.1. Gateway Addresses
28                     1.4.2. Destination/GW lists
29                     1.4.3. Routing Rules
30
31               1.5. Routing Rule Processing
32
33         2. Dependencies
34
35               2.1. Kamailio Modules
36               2.2. External Libraries or Applications
37
38         3. Parameters
39
40               3.1. db_url(str)
41               3.2. drd_table(str)
42               3.3. drr_table(str)
43               3.4. drg_table(str)
44               3.5. drl_table(str)
45               3.6. sort_order (int)
46               3.7. ruri_avp (str)
47               3.8. attrs_avp (str)
48               3.9. use_domain (int)
49               3.10. drg_user_col (str)
50               3.11. drg_domain_col (str)
51               3.12. drg_grpid_col (str)
52               3.13. fetch_rows (int)
53               3.14. force_dns (int)
54               3.15. enable_keepalive (int)
55
56         4. Functions
57
58               4.1. do_routing("[groupID]")
59               4.2. use_next_gw()/next_routing()
60               4.3. goes_to_gw([type])
61               4.4. is_from_gw([type])
62               4.5. is_from_gw( type, [flag])
63
64         5. RPC Commands
65
66               5.1. drouting.reload
67
68         6. Installation
69
70    2. Developer Guide
71
72    List of Tables
73
74    1.1. Definition of table dr_gateways
75    1.2. Sample dr_gateways records
76    1.3. Definition of dr_rules table
77    1.4. Time recurrence attributes
78    1.5. Sample dr_rules records
79
80    List of Examples
81
82    1.1. Set db_url parameter
83    1.2. Set drd_table parameter
84    1.3. Set drr_table parameter
85    1.4. Set drg_table parameter
86    1.5. Set drl_table parameter
87    1.6. Set sort_order parameter
88    1.7. Set ruri_avp parameter
89    1.8. Set attrs_avp parameter
90    1.9. Set use_domain parameter
91    1.10. Set drg_user_col parameter
92    1.11. Set drg_domain_col parameter
93    1.12. Set drg_grpid_col parameter
94    1.13. Set fetch_rows parameter
95    1.14. Set force_dns parameter
96    1.15. Set enable_keepalive parameter
97    1.16. do_routing usage
98    1.17. use_next_gw usage
99    1.18. goes_to_gw usage
100    1.19. is_from_gw usage
101    1.20. is_from_gw usage
102
103 Chapter 1. Admin Guide
104
105    Table of Contents
106
107    1. Overview
108
109         1.1. Introduction
110         1.2. Features
111         1.3. Performance
112         1.4. Routing Rule Definition
113
114               1.4.1. Gateway Addresses
115               1.4.2. Destination/GW lists
116               1.4.3. Routing Rules
117
118         1.5. Routing Rule Processing
119
120    2. Dependencies
121
122         2.1. Kamailio Modules
123         2.2. External Libraries or Applications
124
125    3. Parameters
126
127         3.1. db_url(str)
128         3.2. drd_table(str)
129         3.3. drr_table(str)
130         3.4. drg_table(str)
131         3.5. drl_table(str)
132         3.6. sort_order (int)
133         3.7. ruri_avp (str)
134         3.8. attrs_avp (str)
135         3.9. use_domain (int)
136         3.10. drg_user_col (str)
137         3.11. drg_domain_col (str)
138         3.12. drg_grpid_col (str)
139         3.13. fetch_rows (int)
140         3.14. force_dns (int)
141         3.15. enable_keepalive (int)
142
143    4. Functions
144
145         4.1. do_routing("[groupID]")
146         4.2. use_next_gw()/next_routing()
147         4.3. goes_to_gw([type])
148         4.4. is_from_gw([type])
149         4.5. is_from_gw( type, [flag])
150
151    5. RPC Commands
152
153         5.1. drouting.reload
154
155    6. Installation
156
157 1. Overview
158
159    1.1. Introduction
160    1.2. Features
161    1.3. Performance
162    1.4. Routing Rule Definition
163
164         1.4.1. Gateway Addresses
165         1.4.2. Destination/GW lists
166         1.4.3. Routing Rules
167
168    1.5. Routing Rule Processing
169
170 1.1. Introduction
171
172    Dynamic Routing is a module for selecting (based on multiple criteria)
173    the the best gateway/destination to be used for delivering a certain
174    call. Least Cost Routing (LCR) is a special case of dynamic routing -
175    when the rules are ordered based on costs. Dynamic Routing comes with
176    many features regarding routing rule selection:
177      * prefix based
178      * caller/group based
179      * time based
180      * priority based
181
182    , processing :
183      * stripping and prefixing
184      * default rules
185      * inbound and outbound processing
186      * script route triggering
187
188    and failure handling:
189      * serial forking
190      * weight based GW selection
191      * random GW selection
192
193 1.2. Features
194
195    The dynamic routing implementation for Kamailio is designed with the
196    following properties:
197      * routing info (destinations, rules, groups) are stored in a database
198        and loaded into memory at start up time; reload at runtime via RPC
199        command
200      * load balancing or random selection of the destinations (from a
201        given set)
202      * able to handle large volume of routing info (300K of rules) with
203        minimal speed/time and memory consumption penalties
204      * script integration - Pseudo variables support in functions;
205        scripting route triggering when rules are matched
206      * bidirectional behavior - inbound and outbound processing (strip and
207        prefixing when sending and receiving from a destination/GW)
208
209 1.3. Performance
210
211    There were several tests performed regarding the performance of the
212    module when dealing with a large number of routing rules.
213
214    The tests were performed with a set of 383000 rules and to values were
215    measured:
216      * time to load from DB
217      * used shared memory
218
219    The time to load was varying between 4 seconds and 8 seconds, depending
220    of the caching of the DB client - the first load was the slowest (as
221    the DB query hits the disk drive); the following are faster as data is
222    already cached in the DB client. So technically speaking, the time to
223    load (without the time to query which is DB type dependent) is ~4
224    seconds
225
226    After loading the data into shared memory ~ 96M of memory were used
227    exclusively for the DR data.
228
229 1.4. Routing Rule Definition
230
231    Dynamic routing rules are stored in a database, in four tables:
232      * one for storing the gateway definitions
233      * one for storing the routing rule definitions
234      * one for storing the users mappings over groups
235      * one for storing a list of gateways, so you don't have to enter all
236        the elements every time you need it
237
238 1.4.1. Gateway Addresses
239
240    Default name for the table storing gateway addresses is “dr_gateways”.
241    Gateway addresses are stored in a separate table because of need to
242    access them independent of Dynamic Routing processing (e.g., adding/
243    removing gateway PRI prefix before/after performing other operation --
244    receiving/relaying to gateway).
245
246    Table 1.1. Definition of table dr_gateways
247    Column name     Type     Default value         Description
248    gwid        integer      auto increment unique identifier for GW
249    type        unsigned int 0              type/class of GW
250    address     varchar(128)                address of the gateway
251    strip       unsigned int 0              no of digits to strip
252    pri_prefix  varchar(255)                PRI prefix of the gateway
253    description varchar(128)                description of the gateway
254
255    Once a rule is matched, the STRIP number of digits are removed from the
256    username part of the RURI and then the PRI prefix has to be added to
257    the request URI before forwarding the call to the gateway.
258
259    Table 1.2. Sample dr_gateways records
260    gwid type     address      strip pri_prefix description
261    1    10   10.10.10.10:5080 0     2222       Gateway 1
262    2    10   10.10.10.10      2     3333       Gateway 2
263    3    20   10.10.10.11      0                Gateway 3
264
265 1.4.2. Destination/GW lists
266
267    For each rule, you can set a list of destinations to be used. The list
268    is comma or pipe separated enumeration of the destinations. The module
269    will use (one by one) each destination from the list (in the given
270    order).
271
272    Also the module allows the usage of groups in the destination lists. A
273    group of destinations is delimited by semi-colon char. inside the whole
274    destination list ( like: 2,4;5,78,23;4;7;2 ). The destinations from
275    within a group may be act differently (like load-balancing, random
276    selection, etc), depending of the “sort_order” module parameter - more
277    about this is available under the module paramters section.
278
279 1.4.3. Routing Rules
280
281    Default name for the table storing rule definitions is “dr_rules”.
282
283    Table 1.3. Definition of dr_rules table
284    Column name     Type     Default            Description
285    ruleid      integer      auto    UID of the rule
286    groupid     varchar(255)         list of routing group IDs
287    prefix      varchar(64)          destination prefix for this route
288    timerec     varchar(255)         time recurrence for this rule
289    priority    integer      0       priority of the rule
290    routeid     integer      0       route block to be execute
291    gwlist      varchar(255)         the list with GWs to be used
292    description varchar(128)         description of this rule
293
294     a. groupid column
295        Each user must be member of only one routing group. It must be
296        specified in user's profile.
297     b. prefix column
298        Destination URI must start with prefix value to match the rule. The
299        prefix value can contain only digits (0..9), '+', '*' or '#'.
300     c. time rec column
301        A date-time expression that defines the time recurrence to match
302        for current rule. Time recurrences are based closely on the
303        specification of recurring intervals of time in the Internet
304        Calendaring and Scheduling Core Object Specification (calendar
305        COS), RFC 2445. The set of attributes used in routing rule
306        specification is subset of time recurrence attributes used by Call
307        Processing Language (CPL). These attributes are (extracted from CPL
308        draft 09):
309        Table 1.4. Time recurrence attributes
310
311      Attribute                            Description
312      dastard    Start of interval (RFC 2445 DATE-TIME)
313      duration   Length of interval (RFC 2445 DURATION)
314      freq       Frequency of recurrence (secondly,minutely,hourly, daily,weekly,
315                 monthly, or yearly).
316      until      bound of recurrence (RFC 2445 DATE-TIME)
317      interval   How often the recurrence repeats
318      byday      List of days of the week
319      bymonthday List of days of the month
320      byyearday  List of days of the year
321      byweekno   List of weeks of the year
322      bymonth    List of months of the year
323        The value stored in database has the format of:
324        <dtstart>|<duration>|<freq>|<until>|<interval>|<byday>|<bymonthday>
325        |<byyearday>|<byweekno>|<bymonth>
326        When an attribute is not specified, the corresponding place must be
327        left empty, whenever another attribute that follows in the list has
328        to be specified.
329        Detailed description of time recurrence attributes:
330           + dtstart - specifies the beginning of the first period.
331           + duration - specifies the duration of the period. For a
332             recurring interval, the “duration” parameter MUST be small
333             enough such that subsequent intervals do not overlap. For
334             non-recurring intervals, durations of any positive length are
335             permitted, zero-length duration means “forever”.
336             Negative-length durations are not allowed. In the common case
337             of a duration less than one day, the value starts with 'PT'
338             followed by number of hours, minutes and seconds, e.g., a
339             duration of 8 hours and 30 minutes is written 'PT8H30M'. See
340             RFC 2445 DURATION specifications for full format.
341           + freq - takes one of the following values: “daily”, to specify
342             repeating periods based on an interval of a day or more;
343             “weekly”, to specify repeating periods based on an interval of
344             a week or more; “monthly”, to specify repeating periods based
345             on an interval of a month or more; and “yearly”, to specify
346             repeating periods based on an interval of a year or more.
347             These values are not case-sensitive.
348           + until - defines an iCalendar COS DATE or DATE-TIME value which
349             bounds the recurrence rule in an inclusive manner. If the
350             value specified by “until” is synchronized with the specified
351             recurrence, this date or date-time becomes the last instance
352             of the recurrence. If not present, the recurrence is
353             considered to repeat forever.
354           + interval - contains a positive integer representing how often
355             the recurrence rule repeats. The default value is “1”, meaning
356             every day for a “daily” rule, every week for a “weekly” rule,
357             every month for a “monthly” rule and every year for a “yearly”
358             rule.
359           + interval - contains a positive integer representing how often
360             the recurrence rule repeats. The default value is “1”, meaning
361             every day for a “daily” rule, every week for a “weekly” rule,
362             every month for a “monthly” rule and every year for a “yearly”
363             rule.
364           + byday - specifies a comma-separated list of days of the week.
365             “MO” indicates Monday; “TU” indicates Tuesday; “WE” indicates
366             Wednesday; “TH” indicates Thursday; “FR” indicates Friday;
367             “SA” indicates Saturday; “SU” indicates Sunday. These values
368             are not case-sensitive.
369             Each “byday” value can also be preceded by a positive (+n) or
370             negative (-n) integer. If present, this indicates the nth
371             occurrence of the specific day within the “monthly” or
372             “yearly” recurrence. For example, within a “monthly” rule,
373             +1MO (or simply 1MO) represents the first Monday within the
374             month, whereas -1MO represents the last Monday of the month.
375             If an integer modifier is not present, it means all days of
376             this type within the specified frequency. For example, within
377             a “monthly” rule, MO represents all Mondays within the month.
378           + bymonthday - parameter specifies a comma-separated list of
379             days of the month. Valid values are 1 to 31 or -31 to -1. For
380             example, -10 represents the tenth to the last day of the
381             month.
382           + byyearday - specifies a comma-separated list of days of the
383             year. Valid values are 1 to 366 or -366 to -1. For example, -1
384             represents the last day of the year (December 31st) and -306
385             represents the 306th to the last day of the year (March 1st).
386           + byweekno - specifies a comma-separated list of ordinals
387             specifying weeks of the year. Valid values are 1 to 53 or -53
388             to -1.
389           + bymonth - parameter specifies a comma-separated list of months
390             of the year. Valid values are 1 to 12.
391        A recurrence is specified by including the “freq” parameter, which
392        indicates the type of recurrence rule. Parameters other than
393        “dtstart” and “duration” SHOULD NOT be specified unless “freq” is
394        present.
395        If byxxx parameter values are found which are beyond the available
396        scope (ie, bymonthday=“30” in February), they are simply ignored.
397        Byxxx parameters modify the recurrence in some manner. Byxxx rule
398        parts for a period of time which is the same or greater than the
399        frequency generally reduce or limit the number of occurrences of
400        the recurrence generated. For example, freq=“daily” bymonth=“1”
401        reduces the number of recurrence instances from all days (if the
402        “bymonth” parameter is not present) to all days in January. Byxxx
403        parameters for a period of time less than the frequency generally
404        increase or expand the number of occurrences of the recurrence. For
405        example, freq=“yearly” bymonth=“1,2” increases the number of days
406        within the yearly recurrence set from 1 (if “bymonth” parameter is
407        not present) to 2.
408        If multiple Byxxx parameters are specified, then after evaluating
409        the specified “freq” and “interval” parameters, the Byxxx
410        parameters are applied to the current set of evaluated occurrences
411        in the following order: “bymonth”, “byweekno”, “byyearday”,
412        “bymonthday”, “byday”; then “until” is evaluated.
413        Here is an example of evaluating multiple Byxxx parameters.
414        dtstart=“19970105T083000” duration=“PT10M” freq=“yearly”
415        interval=“2” bymonth=“1” byday=“SU”
416        First, the interval=“2” would be applied to freq=“yearly” to arrive
417        at “every other year” . Then, bymonth=“1” would be applied to
418        arrive at “every January, every other year”. Then, byday=“SU” would
419        be applied to arrive at “every Sunday in January, every other year,
420        from 8:30 to 8:40 ”. The appropriate minutes and hours have been
421        retrieved from the “dtstart” and “duration” parameters.
422     d. priority column
423        If many rules are eligible, choose the one with highest priority.
424     e. routeid column
425        If different than 0, then execute the route with the specified ID.
426        That is, a route which can be used to perform custom operations on
427        message. At this route, no modification is performed at signaling
428        level.
429     f. gwlist column
430        A comma separated list of gateway identifiers corresponding to a
431        row in table “dr_gateways”. You can use a predefined list from the
432        table “dr_gw_lists” preceded by the character “#”. The first
433        gateway is tried first and if routing to it fails, then the second
434        one, and so one. If no gateway is left a negative response is sent
435        back to caller.
436     g. Routing Rules Examples
437        Table 1.5. Sample dr_rules records
438
439    ruleid group prefix timerec priority routeid gwlist description
440    1 6 0049 20040101T083000|10H|weekly|||MO,TU,WE,TH,FR 5 23 1,2 Rule 1
441    2 8 0049 20040101T083000 0 0 1,2 Rule 2
442    3 7,8,9 0049 20040101T083000 0 0 3 Rule 3
443        (The time recurrence for first rule is:
444        “20040101T083000|10H|weekly|||MO,TU,WE,TH,FR”)
445
446 1.5. Routing Rule Processing
447
448    The module can be used to find out which is the best gateway to use for
449    new calls terminated to PSTN. The algorithm to select the rule is as
450    follows:
451      * the module discovers the routing group of the originating user.
452        This step is skipped if a routing group is passed from the script
453        as parameter.
454      * once the group is known, in the subset of the rules for this group
455        the module looks for the one that matches the destination based on
456        "prefix" column. The set of rules with the longest prefix is
457        chosen. If no digit from the prefix matches, the default rules are
458        used (rules with no prefix)
459      * within the set of rules is applied the time criteria, and the rule
460        which has the highest priority and matches the time criteria is
461        selected to drive the routing.
462      * Once found the rule, it may contain a route ID to execute. If a
463        certain flag is set, then the processing is stopped after executing
464        the route block.
465      * The rule must contain a gateway chain. The module will execute
466        serial forking for each address in chain. The next address in chain
467        is used only if the previously has failed.
468      * With the right gateway address found, the prefix (PRI) of the
469        gateway is added to the request URI and then the request is
470        forwarded.
471
472    If no rule is found to match the selection criteria an default action
473    must be taken (e.g., error response sent back). If the gateway in the
474    chain has no prefix the request is forwarded without adding any prefix
475    to the request URI.
476
477 2. Dependencies
478
479    2.1. Kamailio Modules
480    2.2. External Libraries or Applications
481
482 2.1. Kamailio Modules
483
484    The following modules must be loaded before this module:
485      * a database module.
486
487 2.2. External Libraries or Applications
488
489      * none.
490
491 3. Parameters
492
493    3.1. db_url(str)
494    3.2. drd_table(str)
495    3.3. drr_table(str)
496    3.4. drg_table(str)
497    3.5. drl_table(str)
498    3.6. sort_order (int)
499    3.7. ruri_avp (str)
500    3.8. attrs_avp (str)
501    3.9. use_domain (int)
502    3.10. drg_user_col (str)
503    3.11. drg_domain_col (str)
504    3.12. drg_grpid_col (str)
505    3.13. fetch_rows (int)
506    3.14. force_dns (int)
507    3.15. enable_keepalive (int)
508
509 3.1. db_url(str)
510
511    The database url.
512
513    Default value is “NULL”.
514
515    Example 1.1. Set db_url parameter
516 ...
517 modparam("drouting", "db_url",
518         "mysql://kamailio:kamailiorw@localhost/kamailio")
519 ...
520
521 3.2. drd_table(str)
522
523    The name of the db table storing gateway addresses.
524
525    Default value is “dr_gateways”.
526
527    Example 1.2. Set drd_table parameter
528 ...
529 modparam("drouting", "drd_table", "dr_gateways")
530 ...
531
532 3.3. drr_table(str)
533
534    The name of the db table storing routing rules.
535
536    Default value is “dr_rules”.
537
538    Example 1.3. Set drr_table parameter
539 ...
540 modparam("drouting", "drr_table", "rules")
541 ...
542
543 3.4. drg_table(str)
544
545    The name of the db table storing groups.
546
547    Default value is “dr_groups”.
548
549    Example 1.4. Set drg_table parameter
550 ...
551 modparam("drouting", "drg_table", "groups")
552 ...
553
554 3.5. drl_table(str)
555
556    The name of the db table storing definitions of destination lists (to
557    be used directly by the routing rules). You will have a identifier to a
558    group of gateways instead of having all the members of the group as a
559    individual elements. Very useful to reuse a list of gateways in
560    different places.
561
562    Default value is “dr_gw_lists”.
563
564    Example 1.5. Set drl_table parameter
565 ...
566 modparam("drouting", "drl_table", "my_gw_lists")
567 ...
568
569 3.6. sort_order (int)
570
571    Defines how the destination list should be processed (ordering of the
572    elements). Possible modes are
573      * 0 - destination groups are ignored and all the destinations are
574        tried in the given order; Ex: list 1,2;3,4,5;6 will lead to usage
575        as 1,2,3,4,5,6
576      * 1 - the destinations from each group are randomly arranged (only
577        the two first elements are randomly selected); groups do maintain
578        their order (as given); the resulting list is used (with all the
579        defined destinations). Ex: 1,2;3,4,5;6 -> randomizer -> (A)
580        2,1;4,3,5;6 -> usage 2,1,4,3,5,6 (B) 1,2;3,5,4;6 -> usage
581        1,2,3,5,4,6
582      * 2 - from each destination group, only a single destination is
583        randomly selected; groups do maintain their order (as given);
584        Ex: 1,2;3,4,5;6 -> randomizer ->
585        (A) 2;4;6 -> usage 2,4,6
586        (B) 1;5;6 -> usage 1,5,6
587        It is ok to have repeating gateways in different groups. The module
588        will take care internally in case of failure not to choose a
589        gateway that was tried already.
590        Ex: 1,2,3; 1,2,3; 1,2,3 -> no gateway will be chosen twice. So in
591        case there are 2 failures, all the three gateways (1,2,3) will be
592        tried in a random order.
593
594    Default value is “0”.
595
596    Example 1.6. Set sort_order parameter
597 ...
598 modparam("drouting", "sort_order", 2)
599 ...
600
601 3.7. ruri_avp (str)
602
603    The name of the avp for storing Request URIs to be later used
604    (alternative destinations for the current one).
605
606    Default value is “NULL”.
607
608    Example 1.7. Set ruri_avp parameter
609 ...
610 modparam("drouting", "ruri_avp", '$avp(dr_ruri)')
611 modparam("drouting", "ruri_avp", '$avp(i:33)')
612 ...
613
614 3.8. attrs_avp (str)
615
616    The name of the avp for storing the attribute of the current selected
617    destination - once a new destination is selected (via the use_next_gw()
618    function), the AVP will be updated with the attrs of the new used
619    destination.
620
621    Default value is “NULL”.
622
623    Example 1.8. Set attrs_avp parameter
624 ...
625 modparam("drouting", "attrs_avp", '$avp(dr_attrs)')
626 modparam("drouting", "atrrs_avp", '$avp(i:67)')
627 ...
628
629 3.9. use_domain (int)
630
631    Flag to configure whether to use domain match when querying database
632    for user's routing group.
633
634    Default value is “1”.
635
636    Example 1.9. Set use_domain parameter
637 ...
638 modparam("drouting", "use_domain", 0)
639 ...
640
641 3.10. drg_user_col (str)
642
643    The name of the column in group db table where the username is stored.
644
645    Default value is “username”.
646
647    Example 1.10. Set drg_user_col parameter
648 ...
649 modparam("drouting", "drg_user_col", "user")
650 ...
651
652 3.11. drg_domain_col (str)
653
654    The name of the column in group db table where the domain is stored.
655
656    Default value is “domain”.
657
658    Example 1.11. Set drg_domain_col parameter
659 ...
660 modparam("drouting", "drg_domain_col", "host")
661 ...
662
663 3.12. drg_grpid_col (str)
664
665    The name of the column in group db table where the group id is stored.
666
667    Default value is “groupid”.
668
669    Example 1.12. Set drg_grpid_col parameter
670 ...
671 modparam("drouting", "drg_grpid_col", "grpid")
672 ...
673
674 3.13. fetch_rows (int)
675
676    The number of rows that should be fetched from the result of a query in
677    rules db table.
678
679    Default value is “2000”.
680
681    Example 1.13. Set fetch_rows parameter
682 ...
683 modparam("drouting", "fetch_rows", 1500)
684 ...
685
686 3.14. force_dns (int)
687
688    Force DNS resolving of GW/destination names (if not IPs) during
689    startup. If not enabled, the GW name will be blindly used during
690    routing.
691
692    Default value is “1 (enabled)”.
693
694    Example 1.14. Set force_dns parameter
695 ...
696 modparam("drouting", "force_dns", 0)
697 ...
698
699 3.15. enable_keepalive (int)
700
701    Enable monitoring of GW/destinations using keepalive module.
702    Destinations found unavailable will not be used on do_routing() call.
703
704    Default value is “0 (disabled)”.
705
706    Example 1.15. Set enable_keepalive parameter
707 ...
708 modparam("drouting", "enable_keepalive", 1)
709 ...
710
711 4. Functions
712
713    4.1. do_routing("[groupID]")
714    4.2. use_next_gw()/next_routing()
715    4.3. goes_to_gw([type])
716    4.4. is_from_gw([type])
717    4.5. is_from_gw( type, [flag])
718
719 4.1.  do_routing("[groupID]")
720
721    Function to trigger routing of the message according to the rules in
722    the database table and the configured parameters.
723
724    This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
725
726    The module can take one optional parameter: the routing group the
727    caller belongs to - this may be a static numerical value or an AVP
728    specification. If none specified, the function will automatically try
729    to query the dr_group table to get this information.
730
731    Example 1.16. do_routing usage
732 ...
733 do_routing();
734 ...
735 do_routing("0");
736 ...
737 do_routing("$avp(i:10)");
738
739 4.2.  use_next_gw()/next_routing()
740
741    The function takes the next available destination (set by do_routing,
742    as alternative destinations) and push it into RURI. Note that the
743    function just sets the RURI (nothing more).
744
745    If a new RURI is set, the used destination is removed from the pending
746    set of alternative destinations.
747
748    This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
749
750    The function returns true only if a new RURI was set. False is returned
751    is no other alternative destinations are found or in case of internal
752    processing error.
753
754    Example 1.17. use_next_gw usage
755 ...
756 if (use_next_gw()) {
757         t_relay();
758         exit;
759 }
760 ...
761
762 4.3.  goes_to_gw([type])
763
764    Function returns true if the destination of the current request
765    (destination URI or Request URI) points (as IP) to one of the gateways.
766    There no DNS lookups done if the domain part of the URI is not an IP.
767
768    This function does not change anything in the message.
769
770    This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
771
772    The function can take one optional parameter:
773      * type (optional) - GW/destination type to be checked
774
775    Example 1.18. goes_to_gw usage
776 ...
777 if (goes_to_gw("1")) {
778         sl_send_reply("403","Forbidden");
779         exit;
780 }
781 ...
782
783 4.4.  is_from_gw([type])
784
785    The function checks if the sender of the message is a gateway from a
786    certain group.
787
788    This function can be used from REQUEST_ROUTE, FAILURE_ROUTE and
789    ONREPLY_ROUTE
790
791    The function can take one optional parameter:
792      * type (optional) - GW/destination type to be checked
793      * flags - if message is a request and the GW has a STRIP defined,
794        then apply it if GW is source.
795
796    Example 1.19. is_from_gw usage
797 ...
798 if (is_from_gw("1") {
799 }
800 ...
801
802 4.5.  is_from_gw( type, [flag])
803
804    The function checks if the sender of the message is a gateway from a
805    certain group.
806
807    This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
808
809    The function can take two parameters:
810      * type (mandatory) - GW/destination type to be checked
811      * flags (optional) - if message is a request and the GW has a STRIP
812        defined, then apply it if GW is source.
813
814    Example 1.20. is_from_gw usage
815 ...
816 if (is_from_gw("3","1") {
817 }
818 ...
819
820 5. RPC Commands
821
822    5.1. drouting.reload
823
824 5.1.  drouting.reload
825
826    Command to reload routing rules from database.
827
828    It takes no parameter.
829
830    RPC Command Format:
831         kamcmd drouting.reload
832
833 6. Installation
834
835    The module requires 3 table in Kamailio database: dr_groups,
836    dr_gateways, dr_rules. The SQL syntax to create them can be found in
837    drouting-create.sql script in kamctl db directories. You can also find
838    the complete database documentation on the project webpage,
839    https://www.kamailio.org/docs/db-tables/kamailio-db-devel.html.
840
841 Chapter 2. Developer Guide
842
843    The module provides no function to be used by other Kamailio modules.