<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello,</p>
    <p>an workaround would be to add a custom parameter to the
      destination value, like <a class="moz-txt-link-freetext" href="sip:1.2.3.4:5060;sid=1">sip:1.2.3.4:5060;sid=1</a>. Unknown parameters
      should be ignored by the receiving party. Or if you have only two
      records with same address, add to one ";transport=udp".</p>
    <p>Of course, coding in C to make it easier in config would be the
      elegant solution.</p>
    <p>Cheers,<br>
      Daniel<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 20.12.17 15:32, George
      Diamantopoulos wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPcKEYMXBXpeZ1D-_e6gX3miMhLvVXhDdNb=K4K_Mn11-HrZ0A@mail.gmail.com">
      <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" moz-do-not-send="true">111.111.11.1:5060</a>
                      |     8 |        0 | socket=udp:<a
                      href="http://44.44.44.1:5060" target="_blank"
                      moz-do-not-send="true">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"
                        moz-do-not-send="true">111.111.11.1:5060</a></span>
                      |     8 |        0 | socket=udp:<a
                      href="http://55.55.55.1:5060" target="_blank"
                      moz-do-not-send="true">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"
              moz-do-not-send="true">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" moz-do-not-send="true">192.168.0.1:5060</a>
                                   |     8 |        0 | socket=udp:<a
                                  href="http://10.10.10.1:5060"
                                  target="_blank" 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"
                                target="_blank" moz-do-not-send="true">111.111.11.1:5060</a>
                                |     8 |        0 | socket=udp:<a
                                href="http://44.44.44.1:5060"
                                target="_blank" moz-do-not-send="true">44.44.44.1:5060</a> 
                              |<br>
                              |  3 |     1 | sip:<a
                                href="http://222.222.22.2:5060"
                                target="_blank" moz-do-not-send="true">222.222.22.2:5060</a>
                                |     8 |        0 | socket=udp:<a
                                href="http://55.55.55.1:5060"
                                target="_blank" moz-do-not-send="true">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" 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"
                            target="_blank" 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"
                                target="_blank" 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"
                                    target="_blank"
                                    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"
                            target="_blank" 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="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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="m_198769181217832873moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" target="_blank" moz-do-not-send="true">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - <a class="m_198769181217832873moz-txt-link-abbreviated" href="http://www.asipto.com" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">www.kamailioworld.com</a></pre>
                </font></span></div>
          </blockquote>
        </div>
        <br>
      </div>
    </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>