<div dir="ltr"><div><div><div><div>Hello all,<br><br></div>I use the dispatcher module extensively for load balancing and fail-over. My kamailio instance is multihomed, and I use the "socket" attribute to determine which socket SIP messages should use for each dispatcher destination, as such:<br><br><span style="font-family:monospace,monospace">+----+-------+-------------------------+-------+----------+-----------------------------+<br>| id | setid | destination             | flags | priority | attrs                       |<br>+----+-------+-------------------------+-------+----------+-----------------------------+<br></span></div><div><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">|  1 |     0 | sip:<a href="http://192.168.0.1:5060">192.168.0.1:5060</a>    |     8 |        0 | socket=udp:<a href="http://10.10.10.1:5060">10.10.10.1:5060</a>  |</span></span></div><div><span style="font-family:monospace,monospace">|  2 |     1 | sip:<a href="http://111.111.11.1:5060">111.111.11.1:5060</a>   |     8 |        0 | socket=udp:<a href="http://44.44.44.1:5060">44.44.44.1:5060</a>  |<br>|  3 |     1 | sip:<a href="http://222.222.22.2:5060">222.222.22.2:5060</a>   |     8 |        0 | socket=udp:<a href="http://55.55.55.1:5060">55.55.55.1:5060</a>  |<br>+----+-------+-------------------------+-------+----------+-----------------------------+</span><br><br></div>The dispatcher module uses OPTIONS to probe each destination for availability. When a destination goes down or up, the respective event-route is executed.<br><br></div>What I need to do is to be able to "capture" the sending socket used for this probing when a destination becomes unavailable or available in the event-routes. The $fs variable is set, but unfortunately its value does not make sense. Here's an example route and the results that are printed:<br><br><span style="font-family:monospace,monospace">event_route[dispatcher:dst-down] {<br>    xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs) $T_req($Ru)\n");<br>}<br><br></span></div><span style="font-family:arial,helvetica,sans-serif">Now say destination with id = '2' goes down. This is what I get in the logs for the event_route above:</span><span style="font-family:monospace,monospace"><br></span><div><span style="font-family:monospace,monospace"><br>ERROR: <script>: Destination down: OPTIONS sip:</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">111.111.11.1</span>:5060 (sip:<a href="http://192.168.0.1:5060">192.168.0.1:5060</a>) Contact: <sip:</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">111.111.11.1</span>:5060> udp:<a href="http://10.10.10.1:5060">10.10.10.1:5060</a> <null> <null> <null></span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">The xlog PV/log mapping for the above line is the following:</span><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">$rm: OPTIONS</span></div><div><span style="font-family:monospace,monospace">$ru: </span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">sip:</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">111.111.11.1</span>:5060</span></span></div><div><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">$du: </span></span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">sip:<a href="http://192.168.0.1:5060">192.168.0.1:5060</a></span></span></span></div><div><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">$ds: </span></span></span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">Contact: <sip:</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">111.111.11.1</span>:5060></span></span></span></span></div><div><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">$Ru: </span></span></span></span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">udp:<a href="http://10.10.10.1:5060">10.10.10.1:5060</a></span></span></span></span></span></div><div><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">The rest are $null. $ru and $ds are consistent with the actual destination being probed, $du and $fs are not (the are set to values corresponding to id = '1', for some reason).<br></span></span></span></span></span></div><div><br></div><div><span style="font-family:arial,helvetica,sans-serif">This log line is, of course, inaccurate. Not only does it not make sense, but also this is not consistent with messages captured on network interfaces using sngrep: Kamailio does indeed behave as it should, the OPTIONS is sent out to </span><span style="font-family:arial,helvetica,sans-serif"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">111.111.11.1</span></span> from socket <br></span></div><div><span style="font-family:arial,helvetica,sans-serif">udp:<a href="http://44.44.44.1:5060">44.44.44.1:5060</a>. But this is not reflected in the log entry above when the event_route is executed.<br></span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">Now the weird part is that this OPTIONS "transaction" (which is locally generated by kamailio) has the $du PV set to the value of another destination (namely the that of id = '1'). As a result, the $fs PV is consistent with that choice for $du. I can verify with sngrep that this is not the case in reality, as the request was sent to destination id = '2' from the correct socket as indicated above.</span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">What I would like to ask is whether these "OPTIONS" used by dispatcher for probing go through the request_route processing at some point. This is the only way that would explain the $du PV being set to a false value. If yes, is there any way to prevent this from happening? I need to be able to access the $fs PV when a destination goes up or down, and I can't have any other configuration file routes interfering with that. Thanks!</span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">Best regards,</span></div><div><span style="font-family:arial,helvetica,sans-serif">George</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><br></span></span></div></div>