<div dir="ltr"><div><div><div><div><div><div>Hello Daniel,<br><br></div>Thanks for the reply. Unfortunately I can't really use the database records to achieve what I want. The example in my previous message didn't show this, but I would like to be able to differentiate between the following:<br><br><span style="font-family:monospace,monospace">+----+-------+----------------<wbr>---------+-------+----------+-<wbr>----------------------------+<br>| id | setid | destination | flags | priority | attrs |<br>+----+-------+----------------<wbr>---------+-------+----------+-<wbr>----------------------------+<br></span><div><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"></span></span></div><span style="font-family:monospace,monospace">| 1 | 1 | sip:<a href="http://111.111.11.1:5060" target="_blank">111.111.11.1:5060</a> | 8 | 0 | socket=udp:<a href="http://44.44.44.1:5060" target="_blank">44.44.44.1:5060</a> |<br>| 2 | 10 | sip:</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><a href="http://111.111.11.1:5060" target="_blank">111.111.11.1:5060</a></span> | 8 | 0 | socket=udp:<a href="http://55.55.55.1:5060" target="_blank">55.55.55.1:5060</a> |<br>+----+-------+----------------<wbr>---------+-------+----------+-<wbr>----------------------------+<br><br></span></div><span style="font-family:arial,helvetica,sans-serif">In this case, how can I tell which destination went down? The URI is the same, but the sockets differ for each id.<br><br></span></div><span style="font-family:arial,helvetica,sans-serif">If only $ru is available in these event routes, I can't query the database because $ru matches both records. If I can't access the socket used with a PV, is there any way to have access to <b>either</b> the id <b>or</b> the setid for the destination for which the event was generated?<br><br></span></div><span style="font-family:arial,helvetica,sans-serif">Thanks!<br><br></span></div><span style="font-family:arial,helvetica,sans-serif">BR,<br></span></div><span style="font-family:arial,helvetica,sans-serif">George<br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 December 2017 at 10:57, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hello,</p>
<p>those event routes are executed with a so called faked request (a
request generated internally, unrelated to the OPTIONS request
sent to the wire), apart of request uri, the rest of values are
not related to the dispatcher records.</p>
<p>To get access to other attributes of dispatcher records in a
straight way in the config, it would require C coding, Anyhow,
even now using scripting, you can try with sql queries to database
or rpc commands execution via jsonrpcs module and then parse the
result using jansson module.</p>
<p>Cheers,<br>
Daniel<br>
</p><div><div class="h5">
<br>
<div class="m_198769181217832873moz-cite-prefix">On 18.12.17 13:33, George
Diamantopoulos wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<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">+----+-------+----------------<wbr>---------+-------+----------+-<wbr>----------------------------+<br>
| id | setid | destination | flags |
priority | attrs |<br>
+----+-------+----------------<wbr>---------+-------+----------+-<wbr>----------------------------+<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" target="_blank">192.168.0.1:5060</a> |
8 | 0 | socket=udp:<a href="http://10.10.10.1:5060" target="_blank">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" target="_blank">111.111.11.1:5060</a> | 8
| 0 | socket=udp:<a href="http://44.44.44.1:5060" target="_blank">44.44.44.1:5060</a> |<br>
| 3 | 1 | sip:<a href="http://222.222.22.2:5060" target="_blank">222.222.22.2:5060</a> | 8
| 0 | socket=udp:<a href="http://55.55.55.1:5060" target="_blank">55.55.55.1:5060</a> |<br>
+----+-------+----------------<wbr>---------+-------+----------+-<wbr>----------------------------+</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-<wbr>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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
<br>
<fieldset class="m_198769181217832873mimeAttachmentHeader"></fieldset>
<br>
</div></div><pre>______________________________<wbr>_________________
Kamailio (SER) - Users Mailing List
<a class="m_198769181217832873moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>
<a class="m_198769181217832873moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<pre class="m_198769181217832873moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="m_198769181217832873moz-txt-link-abbreviated" href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a class="m_198769181217832873moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - <a class="m_198769181217832873moz-txt-link-abbreviated" href="http://www.asipto.com" target="_blank">www.asipto.com</a>
Kamailio World Conference - May 14-16, 2018 - <a class="m_198769181217832873moz-txt-link-abbreviated" href="http://www.kamailioworld.com" target="_blank">www.kamailioworld.com</a></pre>
</font></span></div>
</blockquote></div><br></div>