/
drouting_admin.xml
2285 lines (2180 loc) · 70.6 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
<!-- Drouting Module User's Guide -->
<chapter>
<title>&adminguide;</title>
<section id="overview" xreflabel="Overview">
<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>
<listitem><para>GW probing for crashes</para></listitem>
</itemizedlist>
</para>
</section>
<section>
<title>Features</title>
<para>
The dynamic routing implementation for &osips; is designed with the
following properties:
</para>
<itemizedlist>
<listitem>
<para>
The routing info (destinations, carriers, rules, groups) is stored in a
database and loaded into memory at start up time; reload at runtime via
a Management Interface command.
</para>
</listitem>
<listitem>
<para>
weight-based or random selection of the destinations (from a rule or
from a carrier), failure detection of gateways (with switching to next
available gateway).
</para>
</listitem>
<listitem>
<para>
able to handle large volume of routing info (10M of rules) with minimal
speed/time and memory consumption penalties
</para>
</listitem>
<listitem>
<para>
script integration - Pseudo-variable 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 blacklists 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>
<listitem>
<para>
loading routing information from multiple databases - the gateways, rules, groups and
carriers can be grouped by partitions, and each partition may be loaded
from different databases/tables. This makes the routing process partition
based. In order to be able to use a table from a partition, its name must
be found in the "version" table belonging to the database defined in the
partition's db_url.
</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 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>Dynamic Routing Concepts</title>
<para>
DR engine uses several concepts in order to define how the routing
should be done (describing all the dependencies between destinations
and routing rules).
</para>
<section>
<title>Destination/Gateways</title>
<para>
These are the end SIP entities where actually the traffic needs to be sent
after routing. They are stored in a table called <quote>dr_gateways</quote>.
Gateway addresses are stored in a separate table because of the 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>
In DR, a gateway is defined by:
</para>
<itemizedlist>
<listitem><para>id (string)</para></listitem>
<listitem><para>SIP address (SIP URI)</para></listitem>
<listitem><para>type (integer which allows GWs to be grouped by purpose,
e.g. inbound, outbound, etc.)</para></listitem>
<listitem>strip value (number of digits) from dialled
number<para></para></listitem>
<listitem><para>prefix (string) to be added to dialled
number</para></listitem>
<listitem><para>attributes (not used by DR engine, but only pushed
to script level when routing to this GW)</para></listitem>
<listitem><para>probing mode (how the GW should be probed at SIP level
- see the probing chapter)</para></listitem>
</itemizedlist>
<para>
The Gateways are to be used from the routing rule or from the carrier
definition. They are all the time referred by their ID.
</para>
</section>
<section>
<title>Carriers</title>
<para>
The carrier concept is used if you need to group gateways in order to
have a better control on how the GWs will be used by DR rules; like
in what order the GWs will be used.
</para>
<para>
Basically, a carrier is a set of gateways which have its own sorting
algorithm and its own attribute string. They are by default defined
in the <quote>dr_carriers</quote> table.
</para>
<para>
In DR, a carrier is defined by:
</para>
<itemizedlist>
<listitem><para>id (string)</para></listitem>
<listitem><para>list of gateways with/without weights (string)
(Ex:<quote>gw1=10,gw4=10</quote> or <quote>gw1,gw2</quote>
</para></listitem>
<listitem><para>flags : 0x1 - use weight for sorting the list and
not definition order; 0x2 - use only the first gateway from the carrier
(depending on the sorting); 0x4 - disable the usage of this
carrier</para></listitem>
<listitem><para>attributes (not used by DR engine, but only pushed
to script level when routing to this carrier)</para></listitem>
</itemizedlist>
<para>
The Carriers are to be used only from the routing rule definition.
They are all the time referred by their ID.
</para>
</section>
<section>
<title>Routing Rules</title>
<para>
These are the actual rules which control the routing. Using
different criterias (prefix, time, priority, etc), they will decide
to which gateways the call will be sent.
</para>
<para>
Default name for the table storing rule definitions is
<quote>dr_rules</quote>.
</para>
<para>
In DR, a routing rule is defined by:
</para>
<itemizedlist>
<listitem><para>group (list of numbers) - rules can be grouped (a rule may
belong to multiple groups in the same time ) and you can
use only a certain group at a point; like having a <quote>premium</quote> or
<quote>standard</quote> or <quote>interstate</quote> or
<quote>intrastate</quote> groups of rules to be used in different
cases</para></listitem>
<listitem><para>prefix (string with digits only) - prefix to be used for
matching this rule (longest prefix matching)</para></listitem>
<listitem><para>time validity (time recurrence string) - when this rule is
valid from time point of view (see RFC 2445)</para></listitem>
<listitem><para>priority (number) - priority of the rule - higher value,
higher priority (see rule section alg)</para></listitem>
<listitem><para>script route ID (string) - if defined, then execute the
route with the specified ID when this rule is matched. That's it, a route
which can be used to perform custom operations on message. NOTE that no
modification is performed at signaling level and you must NOT do
any signaling operations in that script route</para></listitem>
<listitem><para>list of GWs/carriers (string) - a comma separated list
of gateways or carriers (defined by IDs) to be used for this rule; the
carrier IDs are prefixed with <quote>#</quote> sign. For each ID (GW or
carrier) you may specify a weight. For how this list will be interpreted
(as order) see the rule selection section. Example of list:
<quote>gw1,gw4,#cr3</quote> or <quote>gw1=10,gw4=10,#cr3=80</quote>
</para></listitem>
<listitem><para>attributes (not used by DR engine, but only pushed
to script level when this rule matched and been used)</para></listitem>
</itemizedlist>
<para>
More on time recurrence:
</para>
<itemizedlist>
<listitem><para>
A date-time expression that defines the time recurrence to be matched for
current rule. Time recurrences are based closely on the recurring time
intervals from the Internet Calendaring and Scheduling
Core Object Specification (calendar COS), RFC 2445. The set of attributes
used in routing rule specification is a subset of time recurrence attributes.
</para></listitem>
<listitem><para>
The value stored in database has the format of:
<![CDATA[
<dtstart>|<duration>|<freq>|<until>|<interval>|<byday>|<bymonthday>|<byyearday>|<byweekno>|<bymonth>
]]>
</para></listitem>
<listitem><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></listitem>
</itemizedlist>
</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 chain of gateways and carriers. The module will
execute serial forking for each address in the chain (ordering is either done
by simply using the definition order or it may weight-based - weight selection must be
enabled). 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>
<title>Probing and Disabling destinations</title>
<para>
The module has the capability to monitor the status of the destinations by
doing SIP probing (sending SIP requests like OPTIONS).
</para>
<para>
For each destination, you can configure what kind of probing should be
done (probe_mode column):
</para>
<itemizedlist>
<listitem>
<para><emphasis>(0)</emphasis> - no probing at all;</para>
</listitem>
<listitem>
<para><emphasis>(1)</emphasis> - probing only when the destination is
in disabled mode (disabling via MI command will completely stop the
probing also). The destination will be automatically re-enabled
when the probing will succeed next time;</para>
</listitem>
<listitem>
<para><emphasis>(2)</emphasis> - probing all the time. If disabled,
the destination will be automatically re-enabled when the probing
will succeed next time;
</para>
</listitem>
</itemizedlist>
<para>
A destination can become disabled in two ways:
<itemizedlist>
<listitem>
<emphasis>script detection</emphasis> - by calling from script the
dr_disable() function after trying the destination. In this case, if
probing mode for the destination is (1) or (2), the destination will
be automatically re-enabled when the probing will succeed.
</listitem>
<listitem>
<emphasis>MI command</emphasis> - by calling the dr_gw_status MI
command for disabling (on demand) the destination. If so, the probing
and re-enabling of this destination will be completly disabled until
you re-enable it again via MI command - this is designed to allow
controlled and complete disabling of some destination during
maintenance.
</listitem>
</itemizedlist>
</para>
</section>
</section>
<section id="dependencies" xreflabel="Dependencies">
<title>Dependencies</title>
<section>
<title>&osips; Modules</title>
<para>
The following modules must be loaded before this module:
<itemizedlist>
<listitem>
<para>
<emphasis>a database module</emphasis>.
</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para>
<emphasis>tm module</emphasis>.
</para>
</listitem>
<listitem>
<para>
<emphasis>clusterer</emphasis> - only if "status_replication_cluster"
option is enabled.
</para>
</listitem>
</itemizedlist>
</para>
</section>
<section>
<title>External Libraries or Applications</title>
<itemizedlist>
<listitem>
<para>
<emphasis>none</emphasis>.
</para>
</listitem>
</itemizedlist>
</section>
</section>
<section id="exported_parameters" xreflabel="Exported Parameters">
<title>Exported Parameters</title>
<section id="param_db_url" xreflabel="db_url">
<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 id="param_drd_table" xreflabel="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="param_drr_table" xreflabel="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="param_drg_table" xreflabel="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="param_drc_table" xreflabel="drc_table">
<title><varname>drc_table</varname>(str)</title>
<para>
The name of the db table storing definitions of the carriers that will
be used directly by the routing rules.
</para>
<para>
<emphasis> Default value is <quote>dr_carriers</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>drc_table</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "drc_table", "my_dr_carriers")
...
</programlisting>
</example>
</section>
<section id="param_ruri_avp" xreflabel="ruri_avp">
<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>$avp(___dr_ruri__)</quote> if <varname>use_partitions</varname> parameter is 0
or <quote>$avp(___dr_ruri__partition_name)</quote> where partition_name is the name of the partition
containing the AVP (as fetched from the database) if <varname>use_partitions</varname> parameter is 1.
</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(33)')
...
</programlisting>
</example>
</section>
<section id="param_gw_id_avp" xreflabel="gw_id_avp">
<title><varname>gw_id_avp</varname> (str)</title>
<para>
The name of the avp for storing the id of the current selected
gateway/destination - once a new destination is selected (via the
use_next_gw() function), the AVP will be updated with the ID of the
new selected gateway/destination.
</para>
<para>
<emphasis>Default value is <quote>$avp(___dr_gw_id__)</quote> if <varname>use_partitions</varname> parameter is 0
or <quote>$avp(___dr_gw_id__partition_name)</quote> where partition_name is the name of the partition
containing the AVP (as fetched from the database) if <varname>use_partitions</varname> parameter is 1.
</emphasis>
</para>
<example>
<title>Set <varname>gw_id_avp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "gw_id_avp", '$avp(gw_id)')
modparam("drouting", "gw_id_avp", '$avp(334)')
...
</programlisting>
</example>
</section>
<section id="param_gw_priprefix_avp" xreflabel="gw_priprefix_avp">
<title><varname>gw_priprefix_avp</varname> (str)</title>
<para>
The name of the avp for storing the PRI prefix of the current selected
destination/gateway - once a new destination is selected (via the
use_next_gw() function), the AVP will be updated with the PRI prefix of the
new used destination.
</para>
<para>
<emphasis>Default value is <quote>NULL</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>gw_priprefix_avp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "gw_priprefix_avp", '$avp(gw_priprefix)')
...
</programlisting>
</example>
</section>
<section id="param_rule_id_avp" xreflabel="rule_id_avp">
<title><varname>rule_id_avp</varname> (str)</title>
<para>
The name of the avp for storing the id of the current matched
routing rule (see dr_rules table).
</para>
<para>
<emphasis>Default value is <quote>NULL</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>rule_id_avp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "rule_id_avp", '$avp(rule_id)')
modparam("drouting", "rule_id_avp", '$avp(335)')
...
</programlisting>
</example>
</section>
<section id="param_rule_prefix_avp" xreflabel="rule_prefix_avp">
<title><varname>rule_prefix_avp</varname> (str)</title>
<para>
The actual prefix that matched the routing rule (the part from RURI
username that matched the routing rule).
</para>
<para>
<emphasis>Default value is <quote>NULL</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>rule_prefix_avp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "rule_prefix_avp", '$avp(dr_prefix)')
...
</programlisting>
</example>
</section>
<section id="param_carrier_id_avp" xreflabel="carrier_id_avp">
<title><varname>carrier_id_avp</varname> (str)</title>
<para>
AVP to be populate with the ID string for the carrier the
current GW belongs to.
</para>
<para>
<emphasis>Default value is <quote>NULL</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>carrier_id_avp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "carrier_id_avp", '$avp(carrier_id)')
...
</programlisting>
</example>
</section>
<section id="param_gw_sock_avp" xreflabel="gw_sock_avp">
<title><varname>gw_sock_avp</varname> (str)</title>
<para>
The name of the avp for storing sockets for alternative destinations
defined by ruri_avp.
</para>
<para>
<emphasis>Default value is <quote>$avp(___dr_sock__)</quote> if <varname>use_partitions</varname> parameter is 0
or <quote>$avp(___dr_sock__partition_name)</quote> where partition_name is the name of the partition
containing the AVP (as fetched from the database) if <varname>use_partitions</varname> parameter is 1.
</emphasis>
</para>
<example>
<title>Set <varname>gw_sock_avp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "gw_sock_avp", '$avp(dr_sock)')
modparam("drouting", "gw_sock_avp", '$avp(77)')
...
</programlisting>
</example>
</section>
<section id="param_rule_attrs_avp" xreflabel="rule_attrs_avp">
<title><varname>rule_attrs_avp</varname> (str)</title>
<para>
The name of the avp for storing rule attrs in case they are requested at least
once in the script.
</para>
<para>
<emphasis>Default value is <quote>$avp(___dr_ru_att__)</quote> if <varname>use_partitions</varname> parameter is 0
or <quote>$avp(___dr_ru_att__partition_name)</quote> where partition_name is the name of the partition
containing the AVP (as fetched from the database) if <varname>use_partitions</varname> parameter is 1.
</emphasis>
</para>
<example>
<title>Set <varname>rule_attrs_avp</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "rule_attrs_avp", '$avp(dr_rule_attr)')
modparam("drouting", "rule_attrs_avp", '$avp(11)')
...
</programlisting>
</example>
</section>
<section id="param_define_blacklist" xreflabel="define_blacklist">
<title><varname>define_blacklist</varname> (str)</title>
<para>
Defines a blacklist 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 id="param_default_group" xreflabel="default_group">
<title><varname>default_group</varname> (int)</title>
<para>
Group to be used if the caller (FROM user) is not found in the GROUP
table.
</para>
<para>
<emphasis>Default value is <quote>NONE</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>default_group</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "default_group", 4)
...
</programlisting>
</example>
</section>
<section id="param_force_dns" xreflabel="force_dns">
<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 id="param_persistent_state" xreflabel="persistent_state">
<title><varname>persistent_state</varname> (int)</title>
<para>
Specifies whether the <emphasis>state</emphasis> column
should be loaded at startup and flushed during runtime or not.
</para>
<para>
<emphasis>Default value is <quote>1</quote> (enabled).
</emphasis>
</para>
<example>
<title>Set the <varname>persistent_state</varname> parameter</title>
<programlisting format="linespecific">
...
# disable all DB operations with the state of a gateway
modparam("drouting", "persistent_state", 0)
...
</programlisting>
</example>
</section>
<section id="param_no_concurrent_reload" xreflabel="no_concurrent_reload">
<title><varname>no_concurrent_reload</varname> (int)</title>
<para>
If enabled, the module will not allow do run multiple dr_reload
MI commands in parallel (with overlapping) Any new reload will
be rejected (and discarded) while an existing reload is in
progress.
</para>
<para>
If you have a large routing set (millions of rules/prefixes), you
should consider disabling concurrent reload as they will exhaust
the shared memory (by reloading into memory, in the same time,
multiple instances of routing data).
</para>
<para>
<emphasis>Default value is <quote>0 (disabled)</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>no_concurrent_reload</varname> parameter</title>
<programlisting format="linespecific">
...
# do not allow parallel reload operations
modparam("drouting", "no_concurrent_reload", 1)
...
</programlisting>
</example>
</section>
<section id="param_probing_interval" xreflabel="probing_interval">
<title><varname>probing_interval</varname> (integer)</title>
<para>
How often (in seconds) the probing of a destination should be done. If
set to 0, the probing will be disabled as functionality (for all
destinations)
</para>
<para>
<emphasis>
Default value is <quote>30</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>probing_interval</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "probing_interval", 60)
...
</programlisting>
</example>
</section>
<section id="param_probing_method" xreflabel="probing_method">
<title><varname>probing_method</varname> (string)</title>
<para>
The SIP method to be used for the probing requests.
</para>
<para>
<emphasis>
Default value is <quote>"OPTIONS"</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>probing_method</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "probing_method", "INFO")
...
</programlisting>
</example>
</section>
<section id="param_probing_from" xreflabel="probing_from">
<title><varname>probing_from</varname> (string)</title>
<para>
The FROM SIP URI to be advertised in the SIP probing requests.
</para>
<para>
<emphasis>
Default value is <quote>"sip:prober@localhost"</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>probing_from</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "probing_from", "sip:pinger@192.168.2.10")
...
</programlisting>
</example>
</section>
<section id="param_probing_reply_codes" xreflabel="probing_reply_codes">
<title><varname>probing_reply_codes</varname> (string)</title>
<para>
A comma separted list of SIP reply codes. The codes defined here
will be considered as valid reply codes for probing messages,
apart for 200.
</para>
<para>
<emphasis>
Default value is <quote>NULL</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>probing_reply_codes</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "probing_reply_codes", "501, 403")
...
</programlisting>
</example>
</section>
<section id="param_probing_socket" xreflabel="probing_socket">
<title><varname>probing_socket</varname> (string)</title>
<para>
A socket description [proto:]host[:port] of the local socket
(which is used by OpenSIPS for SIP traffic) to be used
(if multiple) for sending the probing messages from.
</para>
<para>
For probing gateway the highest priority has socket from gateway
configuration in dr_gateways table. Then socket from global
<varname>probing_socket</varname> parameter and the lowest
priority is default behaviour with auto selected socket wich
OpenSIPS listens on.
</para>
<para>
<emphasis>
Default value is <quote>NULL</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>probing_socket</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("drouting", "probing_socket", "udp:192.168.1.100:5060")
...
</programlisting>
</example>
</section>
<section id="param_status_replication_cluster" xreflabel="status_replication_cluster">
<title><varname>status_replication_cluster</varname> (integer)</title>
<para>
A cluster ID for sharing the gateways/destinations
and carriers status changes with other OpenSIPS instances that are part
of a cluster. Whenever such a status changes (following an MI command,
a probing result, a script command), the module will replicate this status
change to all the nodes in this given cluster. A value of 0 means that sending replication data is disabled.
</para>
<para>
For more info on how to define and populate a cluster (with OpenSIPS nodes)
see the "clusterer" module.
</para>
<para>
<emphasis>
Default value is <quote>0</quote>.
</emphasis>
</para>
<example>
<title>Set <varname>status_replication_cluster</varname> parameter</title>
<programlisting format="linespecific">
...
# replicate gw/carrier status with all OpenSIPS in cluster ID 9
modparam("drouting", "status_replication_cluster", 9)
...
</programlisting>
</example>
</section>
<section id="param_use_domain" xreflabel="use_domain">
<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 id="param_drg_user_col" xreflabel="drg_user_col">
<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>