[OpenSIPS-Users] Understanding the dispatcher module.
Pauba, Kevin L
KLPauba at west.com
Wed Oct 15 23:56:14 CEST 2008
I've been having fun with the dispatcher module but today something
unexpected happened. It makes me think I've misunderstood the way the
dispatcher module works.
I had thought that when I executed a ds_mark_dst("p") in a failure
route, the module would begin sending OPTIONS message to ping the
device. If it were to fail to get a favorable responses from the pings
(the number dependant on the threshold setting), it would mark the
device as "inactive".
Today I had a failed device that seemed to be permanently in the
"probing" state. I attempted to set it to the "active" state (using the
MI) but it just stayed in probing. I was able to get it to inactive
state but further attempts to get it active failed. I finally use the
MI to reload the dispatcher.list file which made it active.
I looked a bit at the code and now see my understanding is flawed. It
appears that the threshold indicates how many ds_mark_dst("p")
executions are required to put the device into an inactive state. If
the response to the OPTIONS pings include the status codes of "200 OK",
"501 Not supported" or "403" will reset the failure count (that is used
to compare against the threshold) but the device will continue to stay
in the probing state.
I also see from the code that using the MI to mark a device as active
eventually calls the ds_mark_dst(msg, 1) function which executes this:
ret = ds_set_state(group, &avp_value.s, DS_INACTIVE_DST|DS_PROBING_DST,
0);
Shouldn't instead be:
ret = ds_set_set(group, &avp_value.s, DS_ACTIVE_DST, 0);
I don't see any way, other than reloading the dispatcher.list, to get a
device back into an active state after it transitions into the probing
state. Is there some combination of MI commands and/or ping responses
that will put a device back into the active state?
Here's my configuration information (I have the "fr_timer" parameter for
the tm module set to "2"):
modparam("dispatcher", "list_file", "/wic/sipproxy/cfg/dispatcher.list")
# # location of dispatcher configuration file
modparam("dispatcher", "force_dst", 1) # force overwriting of
destination in RURI.
modparam("dispatcher", "flags", 3) # 4: use username of RURI
for hashing, +2: enable failover support.
modparam("dispatcher", "use_default", 0) # 1=last entry of each set
is the failover destination.
modparam("dispatcher", "dst_avp", "$avp(i:100)") # AVP i:101 will
hold list of destinations.
modparam("dispatcher", "grp_avp", "$avp(i:101)") # AVP i:101 will
hold set number
modparam("dispatcher", "cnt_avp", "$avp(i:102)") # AVP i:102 will
hold number of destinations in list
modparam("dispatcher", "ds_ping_method", "OPTIONS") # Message used to
ping destinations
modparam("dispatcher", "ds_ping_from", "sip:dispatcher at openser") # From:
line to use when pinging destinations
modparam("dispatcher", "ds_ping_interval", 10) # Interval between
pings (sec)
modparam("dispatcher", "ds_probing_threshhold", 3) # Number of failed
probes to make destination inactive
Thanks, I appreciate any feedback.
More information about the Users
mailing list