|
@@ -219,7 +219,7 @@ Chapter 1. Admin Guide
|
|
|
|
|
|
The module provides routing, balancing and blocklisting capabilities.
|
|
|
It reads routing entries from a database source or from a config file
|
|
|
- at Kamailio startup. It can uses one routing tree (for one carrier), or
|
|
|
+ at Kamailio startup. It can use one routing tree (for one carrier), or
|
|
|
if needed for every user a different routing tree (unique for each
|
|
|
carrier) for number prefix based routing. It supports several route
|
|
|
tree domains, e.g. for fallback routes or different routing rules for
|
|
@@ -243,7 +243,7 @@ Chapter 1. Admin Guide
|
|
|
Routing tables can be reloaded and edited (in config file mode) with
|
|
|
the RPC interface, the config file is updated according the changes.
|
|
|
This is not implemented for the db interface, because its easier to do
|
|
|
- the changes directly on the db. But the reload and dump functions works
|
|
|
+ the changes directly on the db. But the reload and dump functions work
|
|
|
of course here too.
|
|
|
|
|
|
Some module functionality is not fully available in the config file
|
|
@@ -262,7 +262,7 @@ Chapter 1. Admin Guide
|
|
|
data structures. So from a performance point of view it is better to
|
|
|
pass only IDs in AVPs to the routing functions.
|
|
|
|
|
|
- Basically this module could be used as an replacement for the lcr and
|
|
|
+ Basically this module could be used as a replacement for the lcr and
|
|
|
the dispatcher module, if you have certain flexibility, integration
|
|
|
and/or performance requirements that can't be satisfied with these
|
|
|
modules. But for smaller installations it probably make more sense to
|
|
@@ -825,15 +825,14 @@ failure_route[1] {
|
|
|
Example 1.16. Configuration example - module configuration
|
|
|
|
|
|
The following config file specifies within the default carrier two
|
|
|
- domains, each with an prefix that contains two hosts. It is not
|
|
|
- possible to specify another carrier if you use the config file as data
|
|
|
- source.
|
|
|
+ domains, each with a prefix that contains two hosts. It is not possible
|
|
|
+ to specify another carrier if you use the config file as data source.
|
|
|
|
|
|
All traffic will be equally distributed between the hosts, both are
|
|
|
active. The hash algorithm will working over the [1,2] set, messages
|
|
|
hashed to one will go to the first host, the other to the second one.
|
|
|
Don't use a hash index value of zero. If you omit the hash completely,
|
|
|
- the module gives them a autogenerated value, starting from one.
|
|
|
+ the module gives them an autogenerated value, starting from one.
|
|
|
|
|
|
Use the “NULL” prefix to specify an empty prefix in the config file.
|
|
|
Please note that the prefix is matched against the request URI (or to
|
|
@@ -930,7 +929,7 @@ domain register {
|
|
|
and a default route for other prefixes over carrier 2 and carrier 1.
|
|
|
The gateways for the default carrier will be used for functions that
|
|
|
don't support the user specific carrier lookup. The routing rules for
|
|
|
- carrier 1 and carrier 2 for the “49” prefix contains a additional rule
|
|
|
+ carrier 1 and carrier 2 for the “49” prefix contains an additional rule
|
|
|
with the domain 2, that can be used for example as fallback if the
|
|
|
gateways in domain 1 are not reachable. Two more fallback rules (domain
|
|
|
3 and 4) for carrier 1 are also supplied to support the functionality
|