/
README
1941 lines (1576 loc) · 67.5 KB
/
README
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
Dynamic Routing Module
__________________________________________________________
Table of Contents
1. Admin Guide
1.1. Overview
1.1.1. Introduction
1.1.2. Features
1.1.3. Performance
1.1.4. Dynamic Routing Concepts
1.1.5. Routing Rule Processing
1.1.6. Probing and Disabling destinations
1.2. Dependencies
1.2.1. OpenSIPS Modules
1.2.2. External Libraries or Applications
1.3. Exported Parameters
1.3.1. db_url(str)
1.3.2. drd_table(str)
1.3.3. drr_table(str)
1.3.4. drg_table(str)
1.3.5. drc_table(str)
1.3.6. ruri_avp (str)
1.3.7. gw_id_avp (str)
1.3.8. gw_priprefix_avp (str)
1.3.9. rule_id_avp (str)
1.3.10. rule_prefix_avp (str)
1.3.11. carrier_id_avp (str)
1.3.12. gw_sock_avp (str)
1.3.13. define_blacklist (str)
1.3.14. default_group (int)
1.3.15. force_dns (int)
1.3.16. persistent_state (int)
1.3.17. no_concurrent_reload (int)
1.3.18. probing_interval (integer)
1.3.19. probing_method (string)
1.3.20. probing_from (string)
1.3.21. probing_reply_codes (string)
1.3.22. probing_socket (string)
1.3.23. gw_socket_filter_mode (string)
1.3.24. cluster_id (integer)
1.3.25. cluster_sharing_tag (string)
1.3.26. cluster_probing_mode (string)
1.3.27. use_domain (int)
1.3.28. drg_user_col (str)
1.3.29. drg_domain_col (str)
1.3.30. drg_grpid_col (str)
1.3.31. use_partitions (int)
1.3.32. db_partitions_url (str)
1.3.33. db_partitions_table (str)
1.3.34. partition_id_pvar (pvar)
1.3.35. enable_restart_persistency (int)
1.3.36. extra_prefix_chars (str)
1.3.37. extra_id_chars (str)
1.3.38. rule_tables_query (str)
1.4. Exported Functions
1.4.1. do_routing([groupID], [flags],
[gw_whitelist], [rule_attrs_pvar],
[gw_attrs_pvar], [carrier_attrs_pvar],
[partition])
1.4.2. route_to_carrier( carriers, [gw_attrs_pvar],
[carrier_attrs_pvar], [partition])
1.4.3. route_to_gw(gw_id, [gw_attrs_var],
[carrier_attrs_var], [partition])
1.4.4. use_next_gw( [rule_attrs_pvar],
[gw_attrs_pvar], [carrier_attrs_pvar],
[partition])
1.4.5. goes_to_gw( [type], [flags], [gw_attrs_pvar],
[carrier_attrs_pvar], [partition])
1.4.6. is_from_gw([type], [flag], [gw_attrs_pvar],
[carrier_attrs_pvar], [partition])
1.4.7. dr_is_gw( sip_uri, [type], [flag],
[gw_attrs_pvar], [carrier_attrs_pvar],
[partition])
1.4.8. dr_disable([partition])
1.4.9. dr_match([groupID], [flags], number,
[rule_attrs_pvar], [partition])
1.5. Exported MI Functions
1.5.1. dr_reload
1.5.2. dr_gw_status
1.5.3. dr_carrier_status
1.5.4. dr_reload_status
1.5.5. dr_number_routing
1.5.6. dr_enable_probing
1.6. Exported Events
1.6.1. E_DROUTING_STATUS
1.7. Provided Status/Report Identifiers
1.8. Installation
2. Developer Guide
3. Contributors
3.1. By Commit Statistics
3.2. By Commit Activity
4. Documentation
4.1. Contributors
List of Tables
3.1. Top contributors by DevScore^(1), authored commits^(2) and
lines added/removed^(3)
3.2. Most recently active contributors^(1) to this module
List of Examples
1.1. Set db_url parameter
1.2. Set drd_table parameter
1.3. Set drr_table parameter
1.4. Set drg_table parameter
1.5. Set drc_table parameter
1.6. Set ruri_avp parameter
1.7. Set gw_id_avp parameter
1.8. Set gw_priprefix_avp parameter
1.9. Set rule_id_avp parameter
1.10. Set rule_prefix_avp parameter
1.11. Set carrier_id_avp parameter
1.12. Set gw_sock_avp parameter
1.13. Set define_blacklist parameter
1.14. Set default_group parameter
1.15. Set force_dns parameter
1.16. Set the persistent_state parameter
1.17. Set no_concurrent_reload parameter
1.18. Set probing_interval parameter
1.19. Set probing_method parameter
1.20. Set probing_from parameter
1.21. Set probing_reply_codes parameter
1.22. Set probing_socket parameter
1.23. Set gw_socket_filter_mode parameter
1.24. Set cluster_id parameter
1.25. Set cluster_sharing_tag parameter
1.26. Set cluster_probing_mode parameter
1.27. Set use_domain parameter
1.28. Set drg_user_col parameter
1.29. Set drg_domain_col parameter
1.30. Set drg_grpid_col parameter
1.31. Set use_partitions parameter
1.32. Set db_partitions_url parameter
1.33. Set db_partitions_table parameter
1.34. Set partition_id_pvar parameter
1.35. Set enable_restart_persistency parameter
1.36. Set extra_prefix_chars parameter
1.37. Set extra_id_chars parameter
1.38. Set the rule_tables_query parameter
1.39. do_routing usage
1.40. route_to_carrier usage
1.41. route_to_gw usage
1.42. use_next_gw usage
1.43. goes_to_gw usage
1.44. is_from_gw usage
1.45. dr_is_gw usage
1.46. dr_disable() usage
1.47. dr_match usage
1.48. dr_gw_status usage when use_partitions is set to 0
1.49. dr_gw_status usage when use_partitionsis set to 1
1.50. dr_carrier_status usage when use_partitions is 0
1.51. dr_carrier_status usage when use_partitions is 1
1.52. dr_reload_status usage when use_partitions is 0
1.53. dr_reload_status usage when use_partitions is 1
1.54. dr_enable_probing usage
Chapter 1. Admin Guide
1.1. Overview
1.1.1. Introduction
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:
* prefix based
* caller/group based
* time based
* priority based
, processing :
* stripping and prefixing
* default rules
* inbound and outbound processing
* script route triggering
and failure handling:
* serial forking
* weight based GW selection
* random GW selection
* GW probing for crashes
1.1.2. Features
The dynamic routing implementation for OpenSIPS is designed
with the following properties:
* 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.
* 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).
* able to handle large volume of routing info (10M of rules)
with minimal speed/time and memory consumption penalties
* script integration - Pseudo-variable support in functions;
scripting route triggering when rules are matched
* bidirectional behavior - inbound and outbound processing
(strip and prefixing when sending and receiving from a
destination/GW)
* 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).
* 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.
1.1.3. Performance
There were several tests performed regarding the performance of
the module when dealing with a large number of routing rules.
The tests were performed with a set of 383000 rules and
measured:
* time to load from DB
* used shared memory
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
After loading the data into shared memory ~ 96M of memory were
used exclusively for the DR data.
1.1.4. Dynamic Routing Concepts
DR engine uses several concepts in order to define how the
routing should be done (describing all the dependencies between
destinations and routing rules).
1.1.4.1. Destination/Gateways
These are the end SIP entities where actually the traffic needs
to be sent after routing. They are stored in a table called
“dr_gateways”. 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).
In DR, a gateway is defined by:
* id (string)
* SIP address (SIP URI)
* type (integer which allows GWs to be grouped by purpose,
e.g. inbound, outbound, etc.)
* strip value (number of digits) from dialled number
* prefix (string) to be added to dialled number
* attributes (not used by DR engine, but only pushed to
script level when routing to this GW)
* probing mode (how the GW should be probed at SIP level -
see the probing chapter)
The Gateways are to be used from the routing rule or from the
carrier definition. They are all the time referred by their ID.
1.1.4.2. Carriers
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.
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 “dr_carriers” table.
In DR, a carrier is defined by:
* id (string)
* list of gateways with/without weights (string)
(Ex:“gw1=10,gw4=10” or “gw1,gw2”
* flags : 0x1 - use only the first gateway from the carrier
(depending on the sorting); 0x2 - disable the usage of this
carrier
* sort algorithm : how the list of the gateways should be
sorted before being used, NULL - use the DB given order, W
- do weight based re-ordering, Q - do quality based sorting
(requires the qrouting module)
* attributes (not used by DR engine, but only pushed to
script level when routing to this carrier)
The Carriers are to be used only from the routing rule
definition. They are all the time referred by their ID.
1.1.4.3. Routing Rules
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.
Default name for the table storing rule definitions is
“dr_rules”.
In DR, a routing rule is defined by:
* 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
“premium” or “standard” or “interstate” or “intrastate”
groups of rules to be used in different cases
* prefix (string with digits only) - prefix to be used for
matching this rule (longest prefix matching)
* time validity (time recurrence string) - when this rule is
valid from time point of view (see RFC 2445)
* priority (number) - priority of the rule - higher value,
higher priority (see rule section alg)
* 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
* 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 “#” 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: “gw1,gw4,#cr3” or
“gw1=10,gw4=10,#cr3=80”
* attributes (not used by DR engine, but only pushed to
script level when this rule matched and been used)
More on time recurrence:
* 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 a
routing rule specification is a subset of time recurrence
attributes.
* The value stored in database has the basic format of:
<timezone>|<dtstart>|<dtend>|<duration>|<freq>|<until>|<int
erval>|<byday>|<bymonthday>|<byyearday>|<byweekno>|<bymonth
> , identical to the input of the check_time_rec() function
of the cfgutils module, including the optional use of
logical operators linking multiple such strings into a
larger expression.
* 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.
1.1.5. Routing Rule Processing
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:
* 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.
* 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)
* 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.
* 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.
* 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.
* With the right gateway address found, the prefix (PRI) of
the gateway is added to the request URI and then the
request is forwarded.
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.
1.1.6. Probing and Disabling destinations
The module has the capability to monitor the status of the
destinations by doing SIP probing (sending SIP requests like
OPTIONS).
For each destination, you can configure what kind of probing
should be done (probe_mode column):
* (0) - no probing at all;
* (1) - 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;
* (2) - probing all the time. If disabled, the destination
will be automatically re-enabled when the probing will
succeed next time;
A destination can become disabled in two ways:
* script detection - 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.
* MI command - 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.
1.2. Dependencies
1.2.1. OpenSIPS Modules
The following modules must be loaded before this module:
* a database module.
* tm module.
* clusterer - only if "cluster_id" option is enabled.
1.2.2. External Libraries or Applications
* none.
1.3. Exported Parameters
1.3.1. db_url(str)
The database url.
Default value is “NULL”.
Example 1.1. Set db_url parameter
...
modparam("drouting", "db_url",
"mysql://opensips:opensipsrw@localhost/opensips")
...
1.3.2. drd_table(str)
The name of the db table storing gateway addresses.
Default value is “dr_gateways”.
Example 1.2. Set drd_table parameter
...
modparam("drouting", "drd_table", "dr_gateways")
...
1.3.3. drr_table(str)
The name of the db table storing routing rules.
Default value is “dr_rules”.
Example 1.3. Set drr_table parameter
...
modparam("drouting", "drr_table", "rules")
...
1.3.4. drg_table(str)
The name of the db table storing groups.
Default value is “dr_groups”.
Example 1.4. Set drg_table parameter
...
modparam("drouting", "drg_table", "groups")
...
1.3.5. drc_table(str)
The name of the db table storing definitions of the carriers
that will be used directly by the routing rules.
Default value is “dr_carriers”.
Example 1.5. Set drc_table parameter
...
modparam("drouting", "drc_table", "my_dr_carriers")
...
1.3.6. ruri_avp (str)
The name of the avp for storing Request URIs to be later used
(alternative destiantions for the current one).
Default value is “$avp(___dr_ruri__)” if use_partitions
parameter is 0 or “$avp(___dr_ruri__partition_name)” where
partition_name is the name of the partition containing the AVP
(as fetched from the database) if use_partitions parameter is
1.
Example 1.6. Set ruri_avp parameter
...
modparam("drouting", "ruri_avp", '$avp(dr_ruri)')
modparam("drouting", "ruri_avp", '$avp(33)')
...
1.3.7. gw_id_avp (str)
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.
Default value is “$avp(___dr_gw_id__)” if use_partitions
parameter is 0 or “$avp(___dr_gw_id__partition_name)” where
partition_name is the name of the partition containing the AVP
(as fetched from the database) if use_partitions parameter is
1.
Example 1.7. Set gw_id_avp parameter
...
modparam("drouting", "gw_id_avp", '$avp(gw_id)')
modparam("drouting", "gw_id_avp", '$avp(334)')
...
1.3.8. gw_priprefix_avp (str)
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.
Default value is “NULL”.
Example 1.8. Set gw_priprefix_avp parameter
...
modparam("drouting", "gw_priprefix_avp", '$avp(gw_priprefix)')
...
1.3.9. rule_id_avp (str)
The name of the avp for storing the id of the current matched
routing rule (see dr_rules table).
Default value is “NULL”.
Example 1.9. Set rule_id_avp parameter
...
modparam("drouting", "rule_id_avp", '$avp(rule_id)')
modparam("drouting", "rule_id_avp", '$avp(335)')
...
1.3.10. rule_prefix_avp (str)
The actual prefix that matched the routing rule (the part from
RURI username that matched the routing rule).
Default value is “NULL”.
Example 1.10. Set rule_prefix_avp parameter
...
modparam("drouting", "rule_prefix_avp", '$avp(dr_prefix)')
...
1.3.11. carrier_id_avp (str)
AVP to be populate with the ID string for the carrier the
current GW belongs to.
Default value is “NULL”.
Example 1.11. Set carrier_id_avp parameter
...
modparam("drouting", "carrier_id_avp", '$avp(carrier_id)')
...
1.3.12. gw_sock_avp (str)
The name of the avp for storing sockets for alternative
destinations defined by ruri_avp.
Default value is “$avp(___dr_sock__)” if use_partitions
parameter is 0 or “$avp(___dr_sock__partition_name)” where
partition_name is the name of the partition containing the AVP
(as fetched from the database) if use_partitions parameter is
1.
Example 1.12. Set gw_sock_avp parameter
...
modparam("drouting", "gw_sock_avp", '$avp(dr_sock)')
modparam("drouting", "gw_sock_avp", '$avp(77)')
...
1.3.13. define_blacklist (str)
Defines a blacklist based on a list of GW types - the blacklist
will be populated with the IPs (no port, all protocols) of the
GWs having the specified types.
If partitions are used, prefix the blacklist definition string
with the name of the partition followed by ":" separator.
Multiple instances of this param are allowed.
Default value is “NULL”.
Example 1.13. Set define_blacklist parameter
...
modparam("drouting", "define_blacklist", 'bl_name= 3,5,25,23')
modparam("drouting", "define_blacklist", 'list= 4,2')
modparam("drouting", "define_blacklist", 'pstn:list2 = 5,6')
modparam("drouting", "define_blacklist", 'pstn:list3 = 7,8')
...
1.3.14. default_group (int)
Group to be used if the caller (FROM user) is not found in the
GROUP table.
Default value is “NONE”.
Example 1.14. Set default_group parameter
...
modparam("drouting", "default_group", 4)
...
1.3.15. force_dns (int)
Force DNS resolving of GW/destination names (if not IPs) during
startup. If not enabled, the GW name will be blindly used
during routing.
Default value is “1 (enabled)”.
Example 1.15. Set force_dns parameter
...
modparam("drouting", "force_dns", 0)
...
1.3.16. persistent_state (int)
Specifies whether the state column should be loaded at startup
and flushed during runtime or not.
Default value is “1” (enabled).
Example 1.16. Set the persistent_state parameter
...
# disable all DB operations with the state of a gateway
modparam("drouting", "persistent_state", 0)
...
1.3.17. no_concurrent_reload (int)
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.
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).
Default value is “0 (disabled)”.
Example 1.17. Set no_concurrent_reload parameter
...
# do not allow parallel reload operations
modparam("drouting", "no_concurrent_reload", 1)
...
1.3.18. probing_interval (integer)
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)
Default value is “30”.
Example 1.18. Set probing_interval parameter
...
modparam("drouting", "probing_interval", 60)
...
1.3.19. probing_method (string)
The SIP method to be used for the probing requests.
Default value is “"OPTIONS"”.
Example 1.19. Set probing_method parameter
...
modparam("drouting", "probing_method", "INFO")
...
1.3.20. probing_from (string)
The FROM SIP URI to be advertised in the SIP probing requests.
Default value is “"sip:prober@localhost"”.
Example 1.20. Set probing_from parameter
...
modparam("drouting", "probing_from", "sip:pinger@192.168.2.10")
...
1.3.21. probing_reply_codes (string)
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.
Default value is “NULL”.
Example 1.21. Set probing_reply_codes parameter
...
modparam("drouting", "probing_reply_codes", "501, 403")
...
1.3.22. probing_socket (string)
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.
For probing gateway the highest priority has socket from
gateway configuration in dr_gateways table. Then socket from
global probing_socket parameter and the lowest priority is
default behaviour with auto selected socket wich OpenSIPS
listens on.
Default value is “NULL”.
Example 1.22. Set probing_socket parameter
...
modparam("drouting", "probing_socket", "udp:192.168.1.100:5060")
...
1.3.23. gw_socket_filter_mode (string)
This parameter controls the gateway filtering during DB
loading, or which gateways are loaded or not into memory
depending on the configured socket they have.
The supported filtering modes are:
* "all" - all the gateways defined in DB are loaded into
memory, disregarding what socket value they have. NOTE: for
the gw sockets not matching any OpenSIPS listeners/sockets,
the GW will be loaded with NULL/no socket.
* "ignore" - all the gateways defined in DB are loaded into
memory, but ignoring the socket value they have (the socket
will be set to NULL/NONE with no attempt to check it
against the OpenSIPS listeners/sockets).
* "matched-only" - in this mode the module will load from DB
only the gateways that have a configured a socket matching
any of the the OpenSIPS listeners/sockets. If the gateways
socket does not match, it will be discards, not loaded into
memory at all.
Default value is “"all"”.
Example 1.23. Set gw_socket_filter_mode parameter
...
# multiple OpenSIPS instances sharing a DR setting, so each should
# load only the GWs they have sockets for.
modparam("drouting", "gw_socket_filter_mode", "matched-only")
...
# an OpenSIPs instance not doing routing, but needing to be
# aware of all the gws, so load them all ignoring the sockets
modparam("drouting", "gw_socket_filter_mode", "ignore")
...
1.3.24. cluster_id (integer)
The ID of the cluster the module is part of. The clustering
support is used in drouting module for two purposes: for
sharing the status of the gateways/carriers and for controlling
the pinging to gateways.
If clustering enbled, the module will automatically share
changes over the status of the gateways/destinations/carriers
with the 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.
The clustering with sharing tag support may be used to control
which node in the cluster will perform the pinging/probing to
gateways. See the cluster_sharing_tag option.
For more info on how to define and populate a cluster (with
OpenSIPS nodes) see the "clusterer" module.
Default value is “0 (none)”.
Example 1.24. Set cluster_id parameter
...
# replicate gw/carrier status with all OpenSIPS in cluster ID 9
modparam("drouting", "cluster_id", 9)
...
1.3.25. cluster_sharing_tag (string)
The name of the sharing tag (as defined per clusterer modules)
to control which node is responsible for perform the
self-triggered actions in the module. Such actions may be the
gateway probing (see also the cluster_probing_mode parameter)
or sharing the gateway/carrier status changes. If defined, only
the node with active status of this tag will perform the
actions (pinging and sharing status).
The cluster_id must be defined for this option to work.
This is an optional parameter. If not set, all the nodes in the
cluster will share the status changes.
Default value is “empty (none)”.
Example 1.25. Set cluster_sharing_tag parameter
...
# only the node with the active "vip" sharing tag will perform pinging
# and broadcast the status changes
modparam("drouting", "cluster_id", 9)
modparam("drouting", "cluster_sharing_tag", "vip")
...
1.3.26. cluster_probing_mode (string)
This paramter controls how the probing/pinging should be done
when using the clustering support. It is about which node in
the cluster pings which gateway/destination.
The cluster_id must be defined for this option to work.
The supported probing modes are:
* "all" - all the nodes in the cluster will independetly ping
all the defined gateways, an "all" pings "all" mode.
* "by-shtag" - all the gateways are pinged by only one node
in the cluster, the node having the cluster_sharing_tag
active. By activating the sharing tag on a different node,
the pinging duty will be transfered to another node in the
cluster.
* "distributed" - the pinging effort is distributed across
all the nodes in the cluster, so each node will ping a
sub-set of the overall set of gateway. Still all the
gateways will get pinged (and only once per pinging cycle).
The re-partitioning of the pinging effort over the
available nodes in the cluster is automatically done when
new nodes are joining or nodes are dropping out. Still
there is no guaratee on which node will be responsible for
pinging which gateway.
Default value is “"all"”.
Example 1.26. Set cluster_probing_mode parameter
...
# only the node with the active "vip" sharing tag will perform pinging
modparam("drouting", "cluster_id", 9)
modparam("drouting", "cluster_sharing_tag", "vip")
modparam("drouting", "cluster_probing_mode", "by-shtag")
...
# the pinging effort is distributed across all the nodes
modparam("drouting", "cluster_id", 9)
modparam("drouting", "cluster_probing_mode", "distributed")
...
1.3.27. use_domain (int)
Flag to configure whether to use domain match when querying
database for user's routing group.
Default value is “1”.
Example 1.27. Set use_domain parameter
...
modparam("drouting", "use_domain", 0)
...
1.3.28. drg_user_col (str)
The name of the column in group db table where the username is
stored.
Default value is “username”.
Example 1.28. Set drg_user_col parameter
...
modparam("drouting", "drg_user_col", "user")
...
1.3.29. drg_domain_col (str)
The name of the column in group db table where the domain is
stored.
Default value is “domain”.
Example 1.29. Set drg_domain_col parameter
...
modparam("drouting", "drg_domain_col", "host")
...
1.3.30. drg_grpid_col (str)
The name of the column in group db table where the group id is
stored.
Default value is “groupid”.
Example 1.30. Set drg_grpid_col parameter
...
modparam("drouting", "drg_grpid_col", "grpid")
...
1.3.31. use_partitions (int)
Flag to configure whether to use partitions for routing. If
this flag is set then the db_partitions_url and
db_partitions_table variables become mandatory.
Default value is “0”.
Example 1.31. Set use_partitions parameter
...
modparam("drouting", "use_partitions", 1)
...
1.3.32. db_partitions_url (str)
The url to the database containing partition-specific
information. (partition-specific information includes partition
name, url to the database where information about the partition
is preserved, the names of the tables in which it is preserved
and the AVPs that can be accessed using the .cfg script). The
use_partitions parameter must be set to 1.
Default value is “"NULL"”.
Example 1.32. Set db_partitions_url parameter
...
modparam("drouting", "db_partitions_url", "mysql://user:password@localho
st/opensips_partitions")
...
1.3.33. db_partitions_table (str)
The name of the table containing partition definitions. To be
used with use_partitions and db_partitions_url.
Default value is “dr_partitions”.
Example 1.33. Set db_partitions_table parameter
...
modparam("drouting", "db_partitions_table", "partition_defs")
...
1.3.34. partition_id_pvar (pvar)
Variable which will store the name of the name partition when
wildcard(*) operatior is used. Use_partitions must be set in
order to use this parameter.
NOTE: The variable must be WRITABLE!
Default value is “null(not used)”.
Example 1.34. Set partition_id_pvar parameter
...
modparam("drouting", "partition_id_pvar", "$var(matched_partition)")
...
1.3.35. enable_restart_persistency (int)
Parameter set to enable restart persistency for the Dynamic
Routing module. When this parameter is set, the drouting module