Hi Nuno,

On the Asterisk part, the plan is to do exactly what we already have for FreeSWITCH (see https://blog.opensips.org/2017/03/01/freeswitch-driven-routing-in-opensips-2-3/)

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 )

Regards,

Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

On 11/08/2017 12:17 PM, Nuno Ferreira wrote:
Hi Bogdan,

Do you have further details to share about the "*clustered media relays*" and "*Asterisk flavored* Load-Balancing" features?

Thanks,

Nuno Ferreira

On Wed, Nov 1, 2017 at 5:16 PM, Bogdan-Andrei Iancu <[email protected] <mailto:[email protected]>> wrote:

    One more year, one more evolution cycle, one more OpenSIPS major
    release. So let me introduce you the upcoming OpenSIPS 2.4 .

    For the OpenSIPS 2.4 release we decided to focus on the
    */clustering abilities/*. 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 :

      * scaling up with the processing/traffic load
      * geographical distribution
      * redundancy and High-Availability

    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.

    With OpenSIPS 2.4, it will never be easier to built a consistent
    and powerful clustered solution:

      * *clustering engine* – 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;
      * *distributed user location* – 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 detailed presentation
        <https://www.opensips.org/Development/Design-Distributed-User-Location>
        of the available solutions;
      * *distributed presence server* – 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;
      * *anycast support* – 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 detailed description on
        the anycast
        
<https://docs.google.com/presentation/d/1q6FuBcS_mippQl8ABa2DcrhxRDRHGthvHXe1SlMF6e4/edit?usp=sharing>
        support;
      * *clustered media relays* – 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;
      * *distributed call center* – 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;
      * *custom clustering* – 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.

    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:

      * more *Homer integration *to be able to report TCP statistics,
        DB events and media relay events via HEP;
      * *SIPREC integration* for standard call recording. The new
        SIPREC module
        <http://www.opensips.org/Documentation/Tutorials-SIPREC-2-4>
        provides a standard and transparent (for the call parties) way
        to do call recording against an external recorder like Oreka
        <http://oreka.sourceforge.net/> provided by Orecx
        <http://www.orecx.com>;
      * more *FreeSWITCH integration* 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
      * *Asterisk flavored* Load-Balancing for a more realistic and
        accurate traffic balancing over Asterisk clusters (as the load
        information is fetched in realtime from Asterisk);

    ------------------------------------------------------------------------

    The timeline for OpenSIPS 2.4 is:

      * Beta Release – 12-16 March 2018
      * Stable Release – 23-27 April 2018
      * General Availability – 1st of May 2018, during OpenSIPS Summit
        2018 <http://www.opensips.org/events/Summit-2018Amsterdam/>

    To talk more about the features of this new release, a public
    audio conference <https://www.uberconference.com/opensips> will be
    available on 21st of November 2017, 4 pm GMT
    
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=Introducing+OpenSIPS+2.4&iso=20171121T18&p1=49&ah=1>
 , thanks to
    the kind sponsorship of UberConference
    <https://www.uberconference.com>. Anyone is welcome to join to
    find out more details or to ask questions about OpenSIPS
    <http://opensips.org/> 2.4 .

    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:

    http://blog.opensips.org/2017/11/01/introducing-opensips-2-4/
    <http://blog.opensips.org/2017/11/01/introducing-opensips-2-4/>


    Best regards,

-- Bogdan-Andrei Iancu
       OpenSIPS Founder and Developer
       http://www.opensips-solutions.com <http://www.opensips-solutions.com>


    _______________________________________________
    Users mailing list
    [email protected] <mailto:[email protected]>
    http://lists.opensips.org/cgi-bin/mailman/listinfo/users
    <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>




*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*


_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to