<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body 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>
    <br>
    <div class="moz-cite-prefix">On 18.12.17 13:33, George
      Diamantopoulos wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPcKEYN5KxJdZ_NoAV-hZ11_eF4GvfvQRuw95XAfbGQp5tC=gw@mail.gmail.com">
      <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"
                    moz-do-not-send="true">192.168.0.1:5060</a>    |    
                  8 |        0 | socket=udp:<a
                    href="http://10.10.10.1:5060" moz-do-not-send="true">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"
                  moz-do-not-send="true">111.111.11.1:5060</a>   |     8
                |        0 | socket=udp:<a href="http://44.44.44.1:5060"
                  moz-do-not-send="true">44.44.44.1:5060</a>  |<br>
                |  3 |     1 | sip:<a href="http://222.222.22.2:5060"
                  moz-do-not-send="true">222.222.22.2:5060</a>   |     8
                |        0 | socket=udp:<a href="http://55.55.55.1:5060"
                  moz-do-not-send="true">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"
              moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
                      moz-do-not-send="true">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" moz-do-not-send="true">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="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 14-16, 2018 - <a class="moz-txt-link-abbreviated" href="http://www.kamailioworld.com">www.kamailioworld.com</a></pre>
  </body>
</html>