6.1. benchmark.enable_global
6.2. benchmark.enable_timer
- 6.3. benachmark.granularity
+ 6.3. benchmark.granularity
6.4. benchmark.loglevel
7. Example of usage
6.1. benchmark.enable_global
6.2. benchmark.enable_timer
- 6.3. benachmark.granularity
+ 6.3. benchmark.granularity
6.4. benchmark.loglevel
7. Example of usage
default. This variable may have three different values:
* -1 - Globally disable benchmarking
* 0 - Enable per-timer enabling. Single timers are inactive by
- default and can be activated through the MI interface as soon as
+ default and can be activated through the RPC interface as soon as
that feature is implemented.
* 1 - Globally enable benchmarking
6.1. benchmark.enable_global
6.2. benchmark.enable_timer
- 6.3. benachmark.granularity
+ 6.3. benchmark.granularity
6.4. benchmark.loglevel
6.1. benchmark.enable_global
kamcmd benchmark.enable_timer test 1
...
-6.3. benachmark.granularity
+6.3. benchmark.granularity
Modifies the benchmarking granularity. See "granularity" variable.
4.4. cr_next_domain(carrier, domain, prefix_matching, host,
reply_code, dstavp)
- 5. MI Commands
+ 5. RPC Commands
- 5.1. cr_reload_routes
- 5.2. cr_dump_routes
- 5.3. cr_replace_host
- 5.4. cr_deactivate_host
- 5.5. cr_activate_host
- 5.6. cr_add_host
- 5.7. cr_delete_host
+ 5.1. cr.reload_routes
+ 5.2. cr.dump_routes
- 6. Configuration examples
- 7. Installation and Running
+ 6. MI Commands
- 7.1. Database setup
- 7.2. Database examples
- 7.3. User specific routing
+ 6.1. cr_reload_routes
+ 6.2. cr_dump_routes
+ 6.3. cr_replace_host
+ 6.4. cr_deactivate_host
+ 6.5. cr_activate_host
+ 6.6. cr_add_host
+ 6.7. cr_delete_host
+
+ 7. Configuration examples
+ 8. Installation and Running
+
+ 8.1. Database setup
+ 8.2. Database examples
+ 8.3. User specific routing
2. Module parameter for database access.
4.4. cr_next_domain(carrier, domain, prefix_matching, host,
reply_code, dstavp)
- 5. MI Commands
+ 5. RPC Commands
+
+ 5.1. cr.reload_routes
+ 5.2. cr.dump_routes
- 5.1. cr_reload_routes
- 5.2. cr_dump_routes
- 5.3. cr_replace_host
- 5.4. cr_deactivate_host
- 5.5. cr_activate_host
- 5.6. cr_add_host
- 5.7. cr_delete_host
+ 6. MI Commands
- 6. Configuration examples
- 7. Installation and Running
+ 6.1. cr_reload_routes
+ 6.2. cr_dump_routes
+ 6.3. cr_replace_host
+ 6.4. cr_deactivate_host
+ 6.5. cr_activate_host
+ 6.6. cr_add_host
+ 6.7. cr_delete_host
- 7.1. Database setup
- 7.2. Database examples
- 7.3. User specific routing
+ 7. Configuration examples
+ 8. Installation and Running
+
+ 8.1. Database setup
+ 8.2. Database examples
+ 8.3. User specific routing
1. Overview
database driven routing creates.
Routing tables can be reloaded and edited (in config file mode) with
- the MI interface, the config file is updated according the changes.
+ 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
of course here too.
as input.
* dstavp - Name of the AVP where to store the next routing domain.
-5. MI Commands
+5. RPC Commands
- 5.1. cr_reload_routes
- 5.2. cr_dump_routes
- 5.3. cr_replace_host
- 5.4. cr_deactivate_host
- 5.5. cr_activate_host
- 5.6. cr_add_host
- 5.7. cr_delete_host
+ 5.1. cr.reload_routes
+ 5.2. cr.dump_routes
- All commands understand the "-?" parameter to print a short help
- message. The options have to be quoted as one string to be passed to MI
- interface. Each option except host and new host can be wildcarded by *
- (but only * and not things like "-d prox*").
-
-5.1. cr_reload_routes
+5.1. cr.reload_routes
This command reloads the routing data from the data source.
+ Name: cr.reload_routes
+
+ Parameters:
+ * none
+
Important: When new domains have been added, a restart of the server
must be done, because the mapping of the ids used in the config script
cannot be updated at runtime at the moment. So a reload could result in
differ from the one used internally from the server. Modifying of
already existing domains is no problem.
-5.2. cr_dump_routes
+5.2. cr.dump_routes
This command prints the route rules on the command line.
-5.3. cr_replace_host
+ Name: cr.dump_routes
+
+ Parameters:
+ * none
+
+6. MI Commands
+
+ 6.1. cr_reload_routes
+ 6.2. cr_dump_routes
+ 6.3. cr_replace_host
+ 6.4. cr_deactivate_host
+ 6.5. cr_activate_host
+ 6.6. cr_add_host
+ 6.7. cr_delete_host
+
+ All commands understand the "-?" parameter to print a short help
+ message. The options have to be quoted as one string to be passed to MI
+ interface. Each option except host and new host can be wildcarded by *
+ (but only * and not things like "-d prox*").
+
+6.1. cr_reload_routes
+
+6.2. cr_dump_routes
+
+6.3. cr_replace_host
This command can replace the rewrite_host of a route rule, it is only
usable in file mode. Following options are possible:
kamctl fifo cr_replace_host "-d proxy -p 49 -h proxy1 -t proxy2"
...
-5.4. cr_deactivate_host
+6.4. cr_deactivate_host
This command deactivates the specified host, i.e. it sets its status to
0. It is only usable in file mode. Following options are possible:
kamctl fifo cr_deactivate_host "-d proxy -p 49 -h proxy1"
...
-5.5. cr_activate_host
+6.5. cr_activate_host
This command activates the specified host, i.e. it sets its status to
1. It is only usable in file mode. Following options are possible:
kamctl fifo cr_activate_host "-d proxy -p 49 -h proxy1"
...
-5.6. cr_add_host
+6.6. cr_add_host
This command adds a route rule, it is only usable in file mode.
Following options are possible:
kamctl fifo cr_add_host "-d proxy -p 49 -h proxy1 -w 0.25"
...
-5.7. cr_delete_host
+6.7. cr_delete_host
This command delete the specified hosts or rules, i.e. remove them from
the route tree. It is only usable in file mode. Following options are
kamctl fifo cr_delete_host "-d proxy -p 49 -h proxy1 -w 0.25"
...
-6. Configuration examples
+7. Configuration examples
Example 1.19. Configuration example - Routing to default tree
...
}
...
-7. Installation and Running
+8. Installation and Running
- 7.1. Database setup
- 7.2. Database examples
- 7.3. User specific routing
+ 8.1. Database setup
+ 8.2. Database examples
+ 8.3. User specific routing
-7.1. Database setup
+8.1. Database setup
Before running Kamailio with carrierroute, you have to setup the
database table where the module will store the routing data. For that,
For a minimal configuration either use the config file given above, or
insert some data into the tables of the module.
-7.2. Database examples
+8.2. Database examples
Example 1.22. Example database content - carrierroute table
...
This table contains the mapping of the domain id to actual names.
-7.3. User specific routing
+8.3. User specific routing
For a functional routing the “cr_preferred_carrier” column must be
added to the subscriber table (or to the table and column that you
RPC Command Format:
...
-kamcmd dlg_list
+kamcmd dlg.list
...
9.2. dlg.list_ctx
* Input String
Example:
- # kamcmd dp_translate dpid "input"
- kamcmd dp_translate 1 "abcdxyz"
+ kamcmd dialplan.translate 1 "abcdxyz"
8. Installation
further failovers (the first selected destination and default
destination are the first to be put in the list)
- If the bit 2 in 'flags' is set, the rest of the addresses from the
- destination set is stored in AVP list. You can use 'ds_next_dst()' to
- use next address to achieve serial forking to all possible
- destinations.
-
This function can be used from REQUEST_ROUTE, FAILURE_ROUTE.
Example 1.35. ds_select_dst usage
If set to 1, will enable DMQ replication of actions performed upon
entries in all tables having "dmqreplicate" parameter set. Any update
- action performed via pseudo-variables, MI and RPC commands will be
- repeated on all other nodes. Therefore, it is important to ensure the
- table definition (size, autoexpire etc.) is identical across all
- instances.
+ action performed via pseudo-variables and RPC commands will be repeated
+ on all other nodes. Therefore, it is important to ensure the table
+ definition (size, autoexpire etc.) is identical across all instances.
Important: If this parameter is enabled, the DMQ module must be loaded
first - otherwise, startup will fail.
4.6. system.listMethods
4.7. get_statistics
4.8. stats.reset_statistics
- 4.9. clear_statistics
+ 4.9. stats.clear_statistics
4.10. pkg.stats
4.11. stats.get_statistics
4.12. stats.reset_statistics
4.6. system.listMethods
4.7. get_statistics
4.8. stats.reset_statistics
- 4.9. clear_statistics
+ 4.9. stats.clear_statistics
4.10. pkg.stats
4.11. stats.get_statistics
4.12. stats.reset_statistics
4.6. system.listMethods
4.7. get_statistics
4.8. stats.reset_statistics
- 4.9. clear_statistics
+ 4.9. stats.clear_statistics
4.10. pkg.stats
4.11. stats.get_statistics
4.12. stats.reset_statistics
Print list of available RPC commands.
- Name: which
+ Name: system.listMethods
Parameters: none.
Reset internal statistics.
- Name: statsreset_statistics
+ Name: stats.reset_statistics
Parameters: statsid - which statistics to be reset, give as name.
RPC Command Format:
...
-kamcmd reset_statistics _statsid_
+kamcmd stats.reset_statistics _statsid_
...
-4.9. clear_statistics
+4.9. stats.clear_statistics
Return statistics and reset their value in one command.
- Name: stats.get_statistics
+ Name: stats.clear_statistics
Parameters: statsid - same as for get_statistics.
RPC Command Format:
...
-kamcmd clear_statistics _statsid_
+kamcmd stats.clear_statistics _statsid_
...
4.10. pkg.stats
RPC Command Example:
...
-# kamcmd _sdomain_ _prefix_ _domain_
-kamcmd kamailio.org 123
+kamcmd pdt.list kamailio.org 123
...
Examples:
RPC Command Format:
...
-kamcmd refreshWatchers sip:test@kamailio.org presence 1
+kamcmd presence.refreshWatchers sip:test@kamailio.org presence 1
...
6. Exported Variables
This function is an external command that can be used to announce a
change in authorization rules for a presentity. It updates the stored
status and sends a Notify to the watchers whose status has changes.
- (used by presence_xml module when notified through an MI command of a
+ (used by presence_xml module when notified through an RPC command of a
change in an xcap document).
15. get_sphere
same database tables directly, like the embedded XCAP server
implemented in xcap_server module, the parameter should be set to a
positive value. Apart from updating in xcap table, if the integrated
- server is not running on the same Kamailio instance, it must send an MI
- command refershWatchers [pres_uri] [event] when a user modifies a rules
- document, to instruct the presence_xml module to update states from the
- database and, if needed, send NOTIFY updates.
+ server is not running on the same Kamailio instance, it must send an
+ RPC command presence.refreshWatchers [pres_uri] [event] when a user
+ modifies a rules document, to instruct the presence_xml module to
+ update states from the database and, if needed, send NOTIFY updates.
Otherwise, it uses xcap_client module to fetch documents from the XCAP
servers with HTTP requests.
This module implements rate limiting for SIP requests. In contrast to
the PIKE module this limits the flow based on a per SIP request type
- basis and not per source IP. The MI interface can be used to change
+ basis and not per source IP. The RPC interface can be used to change
tunables while running Kamailio.
The module implements the pipe/queue policy from BSD's ipfw manual,
compiled when the module is loaded, the resulting PCRE objects are
stored in an array. A function to match a string or pseudo-variable
against any of these groups is provided. The text file can be modified
- and reloaded at any time via a MI command. The module also offers a
+ and reloaded at any time via a RPC command. The module also offers a
function to perform a PCRE matching operation against a regular
expression provided as function parameter.
3. Parameters
4. Functions
- 5. MI Commands
+ 5. RPC Commands
Chapter 1. Admin Guide
3. Parameters
4. Functions
- 5. MI Commands
+ 5. RPC Commands
1. Overview
The following libraries must be installed before running Kamailio with
this module loaded:
- * none.
+ * None
3. Parameters
None
-5. MI Commands
+5. RPC Commands
None
requests.
* the Presence server has access imediatelly to the latest version of
XCAP documents. No more need to trigger refresh of XCAP documents
- via MI command
+ via RPC command.
* can be used stand-alone, with a different Presence server. It is
not specific for Kamailio or SER. Documents can be fetched via GET
* no exotic dependencies, it is written in C. It depends on libxml2,
projects / sip-router / commitdiff