2012/1/31 admin@sip-router.org:
+5.4. lcr.defunct_gw
- Defuncts gateway loaded into memory for a period of time (seconds)
- without a need to store gateway's defunct value into database and
- reload the tables.
- Name: lcr.defunct_gw
- Parameters: lcr_id gw_id period
- Example 1.49. lcr.defunct_gw RPC example
- $ sercmd lcr.defunct_gw 1 4 120
Gateways are physical nodes, while LCR instances/profiles are up to the application logic. So in case I have 10 different LCR instances/profiles (i.e. for different kinds of traffic), 5 gateways in total, and gateway 1 exists in all the 10 LCR instances, then in order to dissable such a gateway I must run:
$ sercmd lcr.defunct_gw 1 1 120 $ sercmd lcr.defunct_gw 2 1 120 $ sercmd lcr.defunct_gw 3 1 120 $ sercmd lcr.defunct_gw 4 1 120 $ sercmd lcr.defunct_gw 5 1 120 $ sercmd lcr.defunct_gw 6 1 120 $ sercmd lcr.defunct_gw 7 1 120 $ sercmd lcr.defunct_gw 8 1 120 $ sercmd lcr.defunct_gw 9 1 120 $ sercmd lcr.defunct_gw 10 1 120
So imagine a external tool that tries to monitorize LCR gateways via sending SIP requests by reading LCR DB tables, and performs XMLRPC commands to defunt a gateway when it's down. Such a tool should deal with a same gateway shared by multiple LCR instances, so hopefully it monitors it just once, but then it should perform the XMLRPC command N times for the same gateway. Not good.
I'm sorry but I insist: the design of the new LCR is not as good as it should be. The relationship between rules, LCR instances and gateways is messy (IMHO).
Regards.