<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    <div class="moz-cite-prefix">On 02/11/14 09:25, Federico Cabiddu
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAFOaF_gROa1u7MzSidODD15SxyOgqt2oyRWQYhKCen299VwUZw@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi,
        <div>according to Daniel's suggestion here are my proposed
          changes to implement per gateway and default sending socket in
          the dispatcher module.</div>
        <div>Some notes about them:</div>
        <div>- per gateway socket configuration is done using the
          "socket" attribute</div>
        <div>- module default sending socket is configured via the
          "ds_default_socket" parameter</div>
        <div>- sock_avp AVP is used to hold the sockets list for the
          selected gateways. It actually holds a pointer to the
          socket_info struct for the gateway sending socket (I borrowed
          the idea from another project). I'm currently wondering if it
          makes sense having its name configurable and empty by default
          (I followed the same logic as for the already existing AVPs)
          or if, due to its mainly internal usage, it wouldn't be better
          to give it a name by default and hide it to the module's user.
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    the name has to be empty, forcing the admin to set it to be
    explicitly aware of its value. Long time ago (iirc, it was even SER
    or beginning of openser years), there were some default values in
    the code. Surprising, from time to time various people used same name
    for avp in config for different purpose, messing up the things.<br>
    <br>
    As a related remark, for xavps that use two layers (e.g.,
    $xavp(x=>y) ), only the first name (x) needs to be forced to the
    admin selection, as the second (x) is inside the first xavp, there
    is no real exposure to a conflict. In other words, the admin is made
    aware that $xavp(x=>...) is used for a particular module and must
    not mess it.<br>
    <br>
    Thanks for the patch, I will look over it in the very near future.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <blockquote
cite="mid:CAFOaF_gROa1u7MzSidODD15SxyOgqt2oyRWQYhKCen299VwUZw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Looking forward to hearing your feedback.</div>
        <div><br>
        </div>
        <div>Regards,</div>
        <div><br>
        </div>
        <div>Federico</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, Oct 31, 2014 at 1:00 PM,
          Daniel-Constantin Mierla <span dir="ltr"><<a
              moz-do-not-send="true" 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 bgcolor="#FFFFFF" text="#000000"> Hello,<br>
              <br>
              in the first phase add the socket as an attribute for each
              gateway.<br>
              <br>
              At some point we should look at making some of the
              attributes as dedicated fields (columns), but I would
              prefer to make it at once for all attributes that should
              be split out.<br>
              <br>
              Cheers,<br>
              Daniel
              <div>
                <div class="h5"><br>
                  <br>
                  <div>On 31/10/14 11:37, Federico Cabiddu wrote:<br>
                  </div>
                </div>
              </div>
              <blockquote type="cite">
                <div>
                  <div class="h5">
                    <div dir="ltr">Hi all,
                      <div>after fighting in the last days with
                        dispatcher and the socket used to send pings and
                        dispatch requests, I'm thinking in adding to the
                        module the support for configuring the sending
                        socket. Specifically what I'm thinking is:</div>
                      <div><br>
                      </div>
                      <div>1) add the sending socket as a gateways'
                        parameter </div>
                      <div>2) add an avp to store the gateways' send
                        socket, to be used for load balancing failover</div>
                      <div>3) add a module parameter "ds_send_socket" to
                        define a global socket </div>
                      <div><br>
                      </div>
                      <div>The logic to select the sending socket would
                        be:</div>
                      <div><br>
                      </div>
                      <div>1) if the gateway has send socket configured,
                        use it</div>
                      <div>2) else, if configured, use the socket
                        specified in ds_send_socket</div>
                      <div>3 else use the socket corresponding to the
                        first listen directive (current behaviour)</div>
                      <div><br>
                      </div>
                      <div>What do you think about? Do you find that
                        this would be generally useful?</div>
                      <div>About adding the send socket per gateway: how
                        do you think it should be configured? In a
                        dedicated column (db or file) or in the attrs
                        parameter (just adding another attributes)?</div>
                      <div><br>
                      </div>
                      <div>Looking forward to your feedback.</div>
                      <div><br>
                      </div>
                      <div>Cheers,</div>
                      <div><br>
                      </div>
                      <div>Federico</div>
                      <div><br>
                      </div>
                    </div>
                    <br>
                    <fieldset></fieldset>
                    <br>
                  </div>
                </div>
                <pre>_______________________________________________
sr-dev mailing list
<a moz-do-not-send="true" href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a moz-do-not-send="true" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</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 cols="72">-- 
Daniel-Constantin Mierla
<a moz-do-not-send="true" href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a></pre>
                </font></span></div>
            <br>
            _______________________________________________<br>
            sr-dev mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev"
              target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Nov 24-27, Berlin - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a></pre>
  </body>
</html>