-
Notifications
You must be signed in to change notification settings - Fork 910
/
drouting_admin.xml
1352 lines (1294 loc) · 36 KB
/
drouting_admin.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?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;
]>
<!-- 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 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 RPC 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>
</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 parameters
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. The prefix
value can contain only digits (0..9), '+', '*' or '#'.
</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. In the common case of
a duration less than one day, the value starts with 'PT' followed by
number of hours, minutes and seconds, e.g., a duration of 8 hours
and 30 minutes is written 'PT8H30M'. See RFC 2445 DURATION
specifications for full format.
</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>PT10M</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>. You can use a predefined list from the
table <quote>dr_gw_lists</quote> preceded by the character
<quote>#</quote>. The first gateway is tried first and if routing to it
fails, then the second one, and so one. If no gateway is left a negative
response is sent back to caller.
</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>Parameters</title>
<section id="drouting.p.db_url">
<title><varname>db_url</varname>(str)</title>
<para>
The database url.
</para>
<para>
<emphasis>Default value is <quote>&defaultrodb;</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>db_url</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "db_url",
"&defaultdb;")
...
</programlisting>
</example>
</section>
<section id="drouting.p.drd_table">
<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 id="drouting.p.drr_table">
<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 id="drouting.p.drg_table">
<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 id="drouting.p.drl_table">
<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 id="drouting.p.sort_order"><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 first 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);
<para>
Ex: 1,2;3,4,5;6 -> randomizer ->
</para>
<para>
(A) 2;4;6 -> usage 2,4,6
</para>
<para>
(B) 1;5;6 -> usage 1,5,6
</para>
<para>
It is ok to have repeating gateways in different groups. The module will
take care internally in case of failure not to choose a gateway that
was tried already.
</para>
<para>
Ex: 1,2,3; 1,2,3; 1,2,3 -> no gateway will be chosen twice. So in case there
are 2 failures, all the three gateways (1,2,3) will be tried in a random order.
</para>
</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 id="drouting.p.ruri_avp">
<title><varname>ruri_avp</varname> (str)</title>
<para>
The name of the avp for storing Request URIs to be later used
(alternative destinations 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)')