31 Jan
2012
31 Jan
'12
11:22 a.m.
2012/1/31 <admin(a)sip-router.org>rg>:
+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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>