[OpenSIPS-Users] Introducing OpenSIPS 2.4

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Nov 8 12:31:18 EST 2017


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 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> 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
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20171108/af3c96cb/attachment-0001.html>


More information about the Users mailing list