<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt>Hi Maxim,<br>
      <br>
      Thank you for the valuable input - it is true what you are saying
      IF the media relay has the ability to publish (or report) its
      internal load. What you are describing here is what we did in
      terms of SIP call balancing, with FreeSWITCH - local call counting
      versus pulling call counters from FS.<br>
      <br>
      In regards to the second topic, that is true also, let me give it
      some thoughts. The only issue I see here is with "let each vendor
      to implement proper hooks" :). But as concept it is something
      definitely interesting.<br>
      <br>
      Best regards,<br>
    </tt>
    <pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  <a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a>
</pre>
    <div class="moz-cite-prefix">On 11/11/2017 07:01 AM, Maxim Sobolev
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH7qZfs7cE12UDn4x2kxY7ayP80gdkXJSCT9uQ4N07BhokbdpQ@mail.gmail.com">
      <div dir="ltr">Bogdan, with regards to the media relays clustering
        what's the advantage of sharing that load info between each
        signalling node versus having each node tracking this
        independently? In my view the latter could be more reliable and
        much less complicated construct. The only disadvantage is that
        you'd get more command load on relays, however at least with the
        RTPproxy pulling load stats is very lightweight operation so
        even with tens of signalling nodes pulling single media relay
        every 1-10 seconds it won't cause any noticeable performance
        degradation on the relay. On the flip side, each signalling node
        would get accurate view from its vantage PoV, so in the case of
        geographically distributed system when signalling node can only
        see subset of all media nodes it would still be able to make
        proper decisions. This is the approach we use in the rtp_cluster
        and it works pretty well with cluster size of up to 5 signalling
        and 10 RTP handling nodes, 40-50K media sessions in total. It
        can also give you accurate RTT information, so your signalling
        node can not only factor in the load but also proximity or each
        and every media relay.
        <div><br>
        </div>
        <div>As far as the load tracking is concerned, I think the
          approach to implement "b2b-driven routing" using API that is
          specific to each particular b2b is somewhat wasteful and is
          not very future-proof. What we would like to see instead, is
          for opensips to publish some kind of API (preferably
          SIP-based, using OPTIONS or SUBSCRIBE/NOTIFY mechanism) to
          pull this information out and let each b2b vendor to implement
          proper hooks. Then it can go as far as making this info some
          king of RFC.</div>
        <div><br>
        </div>
        <div>Anyhow, just my $0.02c. Not volunteering to do opensips
          side (ENOTIME), but if opensips project comes up with the
          reasonable b2bua-agnostic load query API to use we might look
          at implementing it in the sippy [py/go]-B2BUAs.</div>
        <div><br>
        </div>
        <div>-Max</div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Nov 8, 2017 at 9:31 AM,
            Bogdan-Andrei Iancu <span dir="ltr"><<a
                href="mailto:bogdan@opensips.org" target="_blank"
                moz-do-not-send="true">bogdan@opensips.org</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"> <tt>Hi Nuno,<br>
                  <br>
                  On the Asterisk part, the plan is to do exactly what
                  we already have for FreeSWITCH (see
                  <a class="m_3371668786977425150moz-txt-link-freetext"
href="https://blog.opensips.org/2017/03/01/freeswitch-driven-routing-in-opensips-2-3/"
                    target="_blank" moz-do-not-send="true">https://blog.opensips.org/<wbr>2017/03/01/freeswitch-driven-<wbr>routing-in-opensips-2-3/</a>)<br>
                  <br>
                  In terms of clustering media relays, is about the
                  ability to share the state (enabled/disabled) between
                  all the cluster nodes using the media relays.
                  Optionally, we are looking in adding the ability to
                  balance the traffic between the relays, in a
                  cluster-level aware (all the nodes in the cluster will
                  share the information on the load of the media relays
                  )<br>
                  <br>
                  Regards,<br>
                </tt><span class="">
                  <pre class="m_3371668786977425150moz-signature" cols="72">Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  <a class="m_3371668786977425150moz-txt-link-freetext" href="http://www.opensips-solutions.com" target="_blank" moz-do-not-send="true">http://www.opensips-solutions.<wbr>com</a>
</pre>
                </span>
                <div>
                  <div class="h5">
                    <div class="m_3371668786977425150moz-cite-prefix"><br>
                    </div>
                  </div>
                </div>
              </div>
            </blockquote>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>