<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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">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">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">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">Oreka</a> provided by <a
          href="http://www.orecx.com" target="_blank" rel="noopener">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">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">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">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">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">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/">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">http://www.opensips-solutions.com</a>
</pre>
  </body>
</html>