<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt>Hello all,<br>
      <br>
      Thank you all the participants to the conf call. <br>
      <br>
      For the people who were not able to join us, please find the audio
      recording
      <a class="moz-txt-link-freetext" href="http://opensips.org/html/media/Introducing_OpenSIPS_2-4_2018-11-21.mp3">http://opensips.org/html/media/Introducing_OpenSIPS_2-4_2018-11-21.mp3</a><br>
      <br>
      And keep in mind that whatever comment, objection, idea or generic
      feedback you may have on the topic we are working on for OpenSIPS
      2.4 is more than welcome ;)<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/01/2017 07:16 PM, Bogdan-Andrei
      Iancu wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:972d9f71-89d4-89f1-9183-f7fc0f1c506a@opensips.org">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      One more year, one more evolution cycle, one more OpenSIPS major
      release. So let me introduce you the upcoming OpenSIPS 2.4 .
      <p>For the OpenSIPS 2.4 release we decided to focus on the <strong><em>clustering
            abilities</em></strong>. Today’s VoIP world is getting more
        and more dynamic, services are moving into Clouds and more and
        more flexibility is needed for the application to fully exploit
        such environments. But let’s pin point the main reasons for
        going for a clustered approach :</p>
      <ul>
        <li>scaling up with the processing/traffic load</li>
        <li>geographical distribution</li>
        <li>redundancy and High-Availability</li>
      </ul>
      <p>For the OpenSIPS 2.4 we laid down a roadmap that addresses the
        clustering both from the clustering engine itself (the
        underlayer) and from the functionalities that will perform on
        top of the clustering layer, to share data and state.</p>
      <p>With OpenSIPS 2.4, it will never be easier to built a
        consistent and powerful clustered solution:</p>
      <ul>
        <li><strong>clustering engine</strong> – enhances the
          capabilities of controlling the cluster topology, like
          re-routing for bypassing broken links, dynamic joining of new
          nodes, support for multiple capabilities per node, data
          syncing between nodes and many more;</li>
        <li><strong>distributed user location</strong> – this is a very
          complex topic as it exceeds the simple concept of data
          sharing. By the nature of the data (the user registrations),
          you may have different constraints on how data is roaming in a
          cluster – registrations may be tied to a node due NAT or TCP
          constraints. Even more, a sharding aspect must be addressed
          when looking at distributing the pinging effort across the
          cluster. So, multiple solutions are viable here, depending on
          what is to be achieved (scaling, redundancy) and what are the
          network constraints – see a <a
href="https://www.opensips.org/Development/Design-Distributed-User-Location"
            target="_blank" rel="noopener" moz-do-not-send="true">detailed
            presentation</a> of the available solutions;</li>
        <li><strong>distributed presence server</strong> – quite similar
          (but less complex) as the distributed user location, a
          distributed presence server provides a consistent, but
          distributed way of sharing presence information – SIP entities
          may publish data via different nodes in the SIP cluster, while
          the subscribers may fetch presence data via multiple various
          nodes. Two approaches are under work : (a) a cluster built
          around a noSQL DB based as primary data storage and (b) a
          cluster exclusively relying on OpenSIPS for data sharing;</li>
        <li><strong>anycast support</strong> – to be able to build a
          fully-flavored anycast support (addressing both redundancy and
          balancing) requires OpenSIPS to replicate/share transaction
          state across the nodes in the cluster (nodes sharing the same
          anycast IP). Depending on the nature of the replication (full
          transaction versus transaction meta-data) a full anycast and
          light anycast support will be available – here is a <a
href="https://docs.google.com/presentation/d/1q6FuBcS_mippQl8ABa2DcrhxRDRHGthvHXe1SlMF6e4/edit?usp=sharing"
            target="_blank" rel="noopener" moz-do-not-send="true">detailed
            description on the anycast</a> support;</li>
        <li><strong>clustered media relays</strong> – as OpenSIPS has
          the ability to work together with several flavors of media
          relays (such as RTPproxy, RTPEngine, MediaProxy), the
          clustering support will help OpenSIPS do distributed
          load-balancing over the relays – even if a relay is used by
          multiple nodes in the cluster, all the nodes will share
          information on the load on the relay, to avoid overloading or
          idle time;</li>
        <li><strong>distributed call center</strong> – an agent is able
          to register with multiple queues on different nodes on a
          cluster. Still, all the queues do share the status /
          availability of the agent and its statistics for call
          distribution;</li>
        <li><strong>custom clustering</strong> – the OpenSIPS clustering
          underlayer provides at script level the ability to broadcast
          (in the cloud) or send to a given node a custom message/action
          (with replying possibility) – this is a very flexible and
          powerful way to build your custom distributed functionality
          directly at script level.</li>
      </ul>
      <p>And because we started on the integration path with OpenSIPS
        2.3, and because we did it well, we decided to push forward on
        this path with the 2.4 version as well:</p>
      <ul>
        <li>more <strong>Homer integration </strong>to be able to
          report TCP statistics, DB events and media relay events via
          HEP;</li>
        <li><strong>SIPREC integration</strong> for standard call
          recording. The <a
            href="http://www.opensips.org/Documentation/Tutorials-SIPREC-2-4"
            target="_blank" rel="noopener" moz-do-not-send="true">new
            SIPREC module</a> provides a standard and transparent (for
          the call parties) way to do call recording against an external
          recorder like <a href="http://oreka.sourceforge.net/"
            target="_blank" rel="noopener" moz-do-not-send="true">Oreka</a>
          provided by <a href="http://www.orecx.com" target="_blank"
            rel="noopener" moz-do-not-send="true">Orecx</a>;</li>
        <li>more <strong>FreeSWITCH integration</strong> in order to
          capture the call-events (DTMFs, call status) from FreeSWITCH
          into OpenSIPS script or for being able to control a FreeSWITCH
          call from OpenSIPS script via ESL</li>
        <li><strong>Asterisk flavored</strong> Load-Balancing for a more
          realistic and accurate traffic balancing over Asterisk
          clusters (as the load information is fetched in realtime from
          Asterisk);</li>
      </ul>
      <hr>
      <p>The timeline for OpenSIPS 2.4 is:</p>
      <ul>
        <li>Beta Release – 12-16 March 2018</li>
        <li>Stable Release – 23-27 April 2018</li>
        <li>General Availability – 1st of May 2018, during <a
            href="http://www.opensips.org/events/Summit-2018Amsterdam/"
            target="_blank" rel="noopener" moz-do-not-send="true">OpenSIPS
            Summit 2018</a></li>
      </ul>
      <p>To talk more about the features of this new release, a public <a
          href="https://www.uberconference.com/opensips" target="_blank"
          rel="noopener noreferrer" moz-do-not-send="true">audio
          conference</a> will be available on <a
href="https://www.timeanddate.com/worldclock/fixedtime.html?msg=Introducing+OpenSIPS+2.4&iso=20171121T18&p1=49&ah=1"
          target="_blank" rel="noopener" moz-do-not-send="true">21st of
          November 2017, 4 pm GMT</a> , thanks to the kind sponsorship
        of <a href="https://www.uberconference.com" target="_blank"
          rel="noopener noreferrer" moz-do-not-send="true">UberConference</a>.
        Anyone is welcome to join to find out more details or to ask
        questions about <a href="http://opensips.org/" target="_blank"
          rel="noopener noreferrer" moz-do-not-send="true">OpenSIPS</a>
        2.4 .</p>
      <p>This is a public and open conference, so no registration is
        needed, but if you want to announce your intention to
        participate, please let us know here:</p>
      <p>      <a class="moz-txt-link-freetext"
          href="http://blog.opensips.org/2017/11/01/introducing-opensips-2-4/"
          moz-do-not-send="true">http://blog.opensips.org/2017/11/01/introducing-opensips-2-4/</a></p>
      <p><br>
      </p>
      <p>Best regards,<br>
      </p>
      <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" moz-do-not-send="true">http://www.opensips-solutions.com</a>
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
News mailing list
<a class="moz-txt-link-abbreviated" href="mailto:News@lists.opensips.org">News@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/news">http://lists.opensips.org/cgi-bin/mailman/listinfo/news</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>