About |
About.Version-Overview-3-3-0 HistoryHide minor edits - Show changes to markup May 30, 2022, at 10:04 AM
by
- Changed line 44 from:
To support SIP clients with Page Mode (SIP MESSAGE) as well, OpenSIPS 3.3 is able to act as a Gateway between SIP MESSAGE(or "Page Mode") and MSRP-based("Session Mode") Instant Messaging – in this way, such SIP clients (with MESSAGE only support) will be able to access all the advanced messaging service build on top of MSRP (like chats, Queuing, RCS, etc). to:
To support SIP clients with Page Mode (SIP MESSAGE) as well, OpenSIPS 3.3 is able to act as a Gateway between SIP MESSAGE(or "Page Mode") and MSRP-based("Session Mode") Instant Messaging – in this way, such SIP clients (with MESSAGE only support) will be able to access all the advanced messaging services built on top of MSRP (like chats, Queuing, RCS, etc). May 18, 2022, at 05:44 PM
by
- Changed line 98 from:
Media exchange features are now bound to the RTP Relay module, to provide more accurate signalling in SDP. to:
Media exchange features are now bound to the rtp_relay module, to provide more accurate signalling in SDP. Therefore, when using media exchange capabilities to inject media in a call, the participant will continue using the same IP of the RTP Relay, without using the Media Server IP, thus preserving the RTP topology hiding. May 18, 2022, at 05:42 PM
by
- Added lines 97-99:
RTP relaying in Media ExchangeMedia exchange features are now bound to the RTP Relay module, to provide more accurate signalling in SDP. Changed line 103 from:
There are many many other changes with this release, and you can read about all of them in this detailed listing. to:
There are many many other changes with this release, and you can read about all of them in this detailed listing. May 18, 2022, at 05:35 PM
by
- Deleted lines 30-32:
Added lines 34-36:
May 18, 2022, at 05:35 PM
by
- Added line 15:
Added lines 30-33:
Changed lines 36-37 from:
The new msrp_ua module bundles the SIP and MSRP capabilities required for implementing an chatting / IM session end point in OpenSIPS. Built on top of proto_msrp and b2b_entities', the module is able to initiate or receive SIP sessions with MSRP and send/receive chats via those sessions. The module may be used directly, via script and MI, to handle such SIP with MRSP sessions and get easy access to their content. Also the module provide an internal API so other modules may build more complex functionalities on top of it. to:
The new msrp_ua module bundles the SIP and MSRP capabilities required for implementing an chatting / IM session end point in OpenSIPS. Built on top of proto_msrp and b2b_entities, the module is able to initiate or receive SIP sessions with MSRP and send/receive chats via those sessions. The module may be used directly, via script and MI, to handle such SIP with MRSP sessions and get easy access to their content. Also the module provide an internal API so other modules may build more complex functionalities on top of it. Added lines 49-51:
Changed lines 63-65 from:
to:
Changed lines 76-77 from:
to:
Changed lines 80-82 from:
More Media relayingThe B2B modules in OpenSIPS provide the mechanisms to create complex SIP scenarios in B2B mode. However, they lack support for RTP/media handling, which, if had to be done at the script level, would require some complex logic to store information throughout the B2B context. These modules should rely on the existing RTP Relay interface to handle B2B media in a more easier fashion. to:
First of all, there were several improvements at the core level when comes to TCP handling / throughput - the idea here started from the huge differences (in terms of handling and performance) between TCP connection associated with SIP trunks (single connection tunneling a lot of traffic) versus end-point oriented connections (many connections with low traffic). So here is what OpenSIPS 3.3 comes with:
Also, the new tcp_mgm module (completely optional) was added to provides fine-grained control over the properties of each TCP connection taking place in OpenSIPS, using an SQL backend. See the module documentation and blog post for more info. More on MediaSDP demux'ingThis is a new b2b_sdp_demux module that is able to de-multiplex a multi-stream call to multiple downstream calls, each containing a different subset of the initial streams. See the module documentation for more details. RTP relaying in B2BThe B2B modules in OpenSIPS provide the mechanisms to create complex SIP scenarios in B2B mode. In OpenSIPS 3.3, the rtp_relay module is B2B aware, providing the automatic support for RTP/media handling. So you do not have to be done at the script level, would require some complex logic to store information throughout the B2B context. AllThere are many many other changes with this release, and you can read about all of them in this detailed listing. May 18, 2022, at 05:20 PM
by
- Deleted line 55:
Added lines 58-66:
A new framework and interface is now available in OpenSIPS 3.3, for managing and accessing the status (readiness) and logs of various OpenSIPS components (modules or parts of the core). See the description of the framework and of its ecosystem. Changed lines 69-71 from:
More Media relayingto:
More Media relayingThe B2B modules in OpenSIPS provide the mechanisms to create complex SIP scenarios in B2B mode. However, they lack support for RTP/media handling, which, if had to be done at the script level, would require some complex logic to store information throughout the B2B context. These modules should rely on the existing RTP Relay interface to handle B2B media in a more easier fashion. May 18, 2022, at 05:09 PM
by
- Changed line 41 from:
Contact Centerto:
Contact Center (OmniChannel)Added lines 45-55:
Once everything is concentrated around MSRP, the interconnection with IMS networks is possible via an OpenSIPS RCS gateway. Therefore any smart phone with RCS support (or within an IMS network) will be able to exchange MSRP traffic with external world. RCS supportAt its core, RCS (Rich Communication Services) is a suite of specifications from OMA and GSMA aimed at replacing SMS messages with a richer messaging system equipped with added services such as group chat, message read receipts, file and file thumbnail transfers, download pausing and resuming, geo-location push, to name a few. And how to use OpenSIPS 3.3 in that context can be learned from this great blog post. Diameter extensionsThe OpenSIPS 3.3 version comes with support for generic Diameter requests. So, by using a JSON Array containing the required AVPs as input, script writers may now send generic Diameter requests from script and also fully define them in the "dictionary.opensips" file, covering any possible Diameter application. May 18, 2022, at 04:57 PM
by
- Changed lines 19-20 from:
Clustering engineto:
With 3.3 version the IM capabilities of OpenSIPS were dramatically enhanced by adding Session Mode for IM, or the Message Session Relay Protocol / MSRP (RFC 4975, RFC 4976). The huge advantage of Session Mode is the fact that you can have deal with IM in a more complex way, session based, or chats; and this enables more IM oriented services to be built, or unified with the audio/video/presence capabilities. MSRP stackThe new proto_msrp module is the foundation of the entire MSRP support in OpenSIPS. It implements the MSRP(S) support according to RFC 4975. The implementation provides a generic MSRP(S) stack covering the network operations (reading / writing MRSP(S) messages), the parsing of the MSRP messages and the managing of the MSRP transactions (request-reply and timeout). The module by itself cannot be used as it exposes no scripting or MI capabilities - it exposes only an internal API for other modules to build functionalities on top of it. MSRP relayThe new msrp_relay module implements an MSRP Relay according to RFC 4976. It is built on top of the proto_msrp and it is able to perform relaying/bridging of MSRP(S) traffic between multiple interfaces. The relay is an essential building block, similar to a RTP relay, from the perspective of the interconnections (network bridging in SBC) and of security (topology hiding and authentication). Chat/MSRP User AgentThe new msrp_ua module bundles the SIP and MSRP capabilities required for implementing an chatting / IM session end point in OpenSIPS. Built on top of proto_msrp and b2b_entities', the module is able to initiate or receive SIP sessions with MSRP and send/receive chats via those sessions. The module may be used directly, via script and MI, to handle such SIP with MRSP sessions and get easy access to their content. Also the module provide an internal API so other modules may build more complex functionalities on top of it. Added lines 34-42:
Once OpenSIPS 3.3 has this messaging capability converging to SIP, the idea of Unifying Communications, of supporting IM along voice and video, becomes technically doable. The SIP infrastructure is already in place, you just need to build the messaging related services. MSRP gateway'ingTo support SIP clients with Page Mode (SIP MESSAGE) as well, OpenSIPS 3.3 is able to act as a Gateway between SIP MESSAGE(or "Page Mode") and MSRP-based("Session Mode") Instant Messaging – in this way, such SIP clients (with MESSAGE only support) will be able to access all the advanced messaging service build on top of MSRP (like chats, Queuing, RCS, etc). Contact CenterWith 3.3 version, the Call Center module in OpenSIPS also support queuing and distributing Messaging Sessions via MSRP calls, turning the modules into actually a Contact Center as the agents are now able to handle both RTP/audio calls and (multiple) MSRP/chat calls, via the same flows, in the same time. See here more on agents RTP/MSRP support. For flexibility purposes, the module implements two different dispatching (to agents) policies, efficiency (loading agents) or balancing oriented - see the chat_dispatch_policy module parameter. May 18, 2022, at 04:05 PM
by
- Added lines 8-29:
https://blogopensips.files.wordpress.com/2021/12/opensips-3.3-im.jpg
The instant messaging is evolving and gaining more and more importance. This happens in both worlds of VoIP/ITSP and IMS/MNO/MVNOs - and the overlapping and mixing of these worlds in increasing each year. The OpenSIPS 3.3 is to address more, in depth, the topic of Instant Messaging, in the context of SIP. And this is done through two major perspectives: from the Unified Communication perspective, by aligning IM with the voice and presence capabilities in OpenSIPS, and from the IMS perspective, mainly as support/integration with RCS (Rich Communication Services).
Messaging sessions or MSRPClustering engineUnified communicationIMSStatus Report supportTCP boostMore Media relayingMay 18, 2022, at 03:51 PM
by - December 19, 2019, at 07:40 PM
by
- Deleted lines 7-93:
https://blogopensips.files.wordpress.com/2019/12/opensips-3.3-crafting.jpg Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.3 release will focus on complex call crafting, basically on increasing OpenSIPS's ability to create and handle complex calling scenarios where multiple SIP calls are mixed and able to interact. Or shortly said, the 3.3 release will address the Class 5 specific calling features and how to control such calling features via APIs. As usual, all the OpenSIPS major releases are in depth presented during the OpenSIPS Summit yearly events. So, the 3.3 release is the star of OpenSIPS Summit in Amsterdam, May 2020. Class 5 calling ingredientsWithout actually using a Back2Back model, but simply operating with calls (dialogs, UACs or UASs), many complex class 5 calling (and call mixing) scenarios may be scripted. Calling APIA new OpenSIPS module, placed on top of dialog module, will allow remote control over the calls going through OpenSIPS. The module will expose a simplified set of commands (API like) for setting up new calls, for answering and terminating calls, for transferring or putting on-hold calls - all these without interacting with the end-devices, but triggering and handling the action only from the OpenSIPS (as proxy) level. Call mixingAnother new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose of mixing the RTP media between these multiple flows. The idea is to make possible the injection of streams of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs. Per-call hooksAs we already have for transactions, the dialog module will allow the script writer to set, in a per-dialog fashion, script routes to be triggered by various dialog events. Similar to t_on_failure(route), you can do dlg_on_timeout(route) to have a route called when the dialog lifetime is exceed. In the route, you may decide to extend the lifetime, to terminate the call or do any other logging. We can foresen dlg_on_answer(route), dlg_on_terminate(route)' (and more) triggers, which will give a better interaction and control over the ongoing calls. SDP topology hidingDue to the specificity of class 5 scenarios, there is a real need to completely decouple the SDP's (not only from IP/port perspective) from the caller and callee side, like hiding the originator or overwriting the session name and version. DTMF supportFor both RTProxy and RTPEngine, OpenSIPS will be able to report to the OpenSIPS script the DTMF events sampled from the passing RTP. This will make possible the implementation of simple IVRs and/or authentication via DTMF with nothing more than OpenSIPS and the media relay. Extended BLF supportIn Class 5 services, BLF is an important feature. Besides working out clustering support for BLF, an important task is reworking the BLF implementation to be call-branch aware, to be able to properly report the call events in parallel calling or call hunting scenarios. Dialog module enhancementsWe are looking at a good set of additions for the dialog module, like:
Back-to-back supportThe existing B2B implementation in OpenSIPS has some limitations, so we are looking to overcome via some major rework here. Script driven B2BInstead of using the XML scenario to drive the B2B logic (mixing between the calls), we want to use the OpenSIPS scripting for this purpose. This will eliminate all the limitations of the XML language (logic and action) and it will tremendously increase the level of integration of the B2B engine with the rest of the OpenSIPS functionalities. Shortly, more complex B2B logic will be possible, and also better integrated with the rest of OpenSIPS. B2B clustering supportTo be 100% production ready, an High-Availability support maybe available for the B2B engine. This will be achieved by adding clustering and replication support for the B2B calling. B2B contextAn important improvement of the B2B engine will be the addition of the B2B context, to help in correlating all the entities (UAC, UAS) part of a B2B session, to attach custom data to the entities and to exchange such data between the entities. This will help with Accounting and media relaying support for B2B, but also with building custom data sharing inside a B2B session (or between the sessions). Call CenterFor 3.3, we are looking at:
Device Feature Key Synchronization (DFKS)DFKS support is planned for OpenSIPS 3.3. This will help to keep feature settings in sync between multiple device and application servers, an essential need in a class 5 / PBX environment. STIR/SHAKENDealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 3.3, providing multiple usage models, in terms of how the certificates are to be handled during the verification process. Also a flexible approach (to the standards) will be able to cope with all the potential changes derived from the adoption process (of the standard by the providers). Push Notification (RFC8599)The existing PN support will be improved and aligned to the requirements as per newly adopted RFC 8599. Besides the notification itself, we need to address some particularities in contact registration, derived from privacy concerns or device identification concerns. noSQL adds-onThe DB layer needs a constant attention, so here is the plan for 3.3:
December 19, 2019, at 07:28 PM
by
- Changed lines 24-25 from:
Another new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose of mixing the RTP media between these multiple flows. The idea is to make possible the injection or stream of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs. to:
Another new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose of mixing the RTP media between these multiple flows. The idea is to make possible the injection of streams of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs. Changed lines 27-28 from:
As we already have for transactions, the dialog module will allow the script writer to set, in a per-dialog fashion, script routes to be triggered by various dialog events. Similar to t_on_failure(route), you can do dlg_on_timeout(route) to have a route called when the dialog lifetime is exceed. In the route, you may decide to prolong the lifetime, to terminate the call or do any other login. We can foreseen dlg_on_answer(route), dlg_on_terminate(route)' (and more) triggers, which will give a better interaction and control over the ongoing calls. to:
As we already have for transactions, the dialog module will allow the script writer to set, in a per-dialog fashion, script routes to be triggered by various dialog events. Similar to t_on_failure(route), you can do dlg_on_timeout(route) to have a route called when the dialog lifetime is exceed. In the route, you may decide to extend the lifetime, to terminate the call or do any other logging. We can foresen dlg_on_answer(route), dlg_on_terminate(route)' (and more) triggers, which will give a better interaction and control over the ongoing calls. Changed lines 33-34 from:
For both RTProxy and RTPEngine, OpenSIPS will be able to report to script the DTMF sampled from the passing RTP. This will make possible the implementation of simple IVRs or authentication via DTMF with nothing more than OpenSIPS and the media relay. to:
For both RTProxy and RTPEngine, OpenSIPS will be able to report to the OpenSIPS script the DTMF events sampled from the passing RTP. This will make possible the implementation of simple IVRs and/or authentication via DTMF with nothing more than OpenSIPS and the media relay. Changed lines 36-37 from:
In Class 5 services, BLF is an important feature. Beside working out clustering support for BLF, an important task is reworking the BLF implementation to be call-branch aware, to be able to properly report the call events in parallel calling or call hunting scenarios. to:
In Class 5 services, BLF is an important feature. Besides working out clustering support for BLF, an important task is reworking the BLF implementation to be call-branch aware, to be able to properly report the call events in parallel calling or call hunting scenarios. Changed lines 51-52 from:
Instead of using the XML scenario to drive the B2B logic (mixing between the calls), we want to use the OpenSIPS scripting for the purpose. This will eliminate all the limitation of the XML language (logic and action) and it will tremendously increase the level of integration of the B2B engine with the rest of the OpenSIPS functionalities. Shortly, more complex B2B logic will be possible, and also better integrated with the rest of OpenSIPS. to:
Instead of using the XML scenario to drive the B2B logic (mixing between the calls), we want to use the OpenSIPS scripting for this purpose. This will eliminate all the limitations of the XML language (logic and action) and it will tremendously increase the level of integration of the B2B engine with the rest of the OpenSIPS functionalities. Shortly, more complex B2B logic will be possible, and also better integrated with the rest of OpenSIPS. Changed lines 57-61 from:
An important improvement of the B2B engine will be the addition of the B2B context, to help in correlating all the entities (UAC, UAS) part of a B2B session, to attach custom data to the entities and to exchange such data between the entities. This will help with Accounting and media relaying support for B2B, but also with building custom data sharing inside a B2B session (or between the sessions) B2B engineImprove the media to:
An important improvement of the B2B engine will be the addition of the B2B context, to help in correlating all the entities (UAC, UAS) part of a B2B session, to attach custom data to the entities and to exchange such data between the entities. This will help with Accounting and media relaying support for B2B, but also with building custom data sharing inside a B2B session (or between the sessions). Changed lines 66-67 from:
to:
Changed line 78 from:
Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 3.3, providing multiple usage models, in therms of how the certificates are to be handled during the verification process. Also a flexible approach (to the standards) will be able to cope with all the potential changes derived from the adoption process (of the standard by the providers). to:
Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 3.3, providing multiple usage models, in terms of how the certificates are to be handled during the verification process. Also a flexible approach (to the standards) will be able to cope with all the potential changes derived from the adoption process (of the standard by the providers). December 19, 2019, at 07:22 PM
by
- Changed lines 18-19 from:
Without actually using a Back2BAck model, but simply operating with calls (dialogs, UACs or UASs), many complex class 5 calling (and call mixing) scenarios may be scripted. to:
Without actually using a Back2Back model, but simply operating with calls (dialogs, UACs or UASs), many complex class 5 calling (and call mixing) scenarios may be scripted. Changed lines 21-22 from:
A new OpenSIPS module, placed on top of dialog module, will allow remote control over the calls going through OpenSIPS. The module will expose an simplify set of command (API like) for setting up new calls, for answering and terminating calls, for transferring or putting on-hold calls - all these without interacting with the end-devices, but triggering and handling the action only from the OpenSIPS (as proxy) level. to:
A new OpenSIPS module, placed on top of dialog module, will allow remote control over the calls going through OpenSIPS. The module will expose a simplified set of commands (API like) for setting up new calls, for answering and terminating calls, for transferring or putting on-hold calls - all these without interacting with the end-devices, but triggering and handling the action only from the OpenSIPS (as proxy) level. Changed lines 24-25 from:
Another new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose the mixing the RTP media between these multiple flows. The idea is to make possible the injection or stream of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs. to:
Another new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose of mixing the RTP media between these multiple flows. The idea is to make possible the injection or stream of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs. Added lines 58-60:
B2B engineImprove the media December 19, 2019, at 07:19 PM
by
- Changed lines 9-10 from:
Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.3 release will focus on complex call crafting, basically on increasing OpenSIPS's ability to create and handle complex calling scenarios where multiple SIP calls are mixed and interacting. Or shortly said, the 3.3 release will address the Class 5 specific calling features and how to control such calling features via APIs. to:
Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.3 release will focus on complex call crafting, basically on increasing OpenSIPS's ability to create and handle complex calling scenarios where multiple SIP calls are mixed and able to interact. Or shortly said, the 3.3 release will address the Class 5 specific calling features and how to control such calling features via APIs. Changed lines 78-94 from:
to:
Dealing with Robocalling and CLI spoofing becomes a must when building advanced calling solutions. The support for STIR/SHAKEN will be part of OpenSIPS 3.3, providing multiple usage models, in therms of how the certificates are to be handled during the verification process. Also a flexible approach (to the standards) will be able to cope with all the potential changes derived from the adoption process (of the standard by the providers).
Push Notification (RFC8599)The existing PN support will be improved and aligned to the requirements as per newly adopted RFC 8599. Besides the notification itself, we need to address some particularities in contact registration, derived from privacy concerns or device identification concerns.
noSQL adds-onThe DB layer needs a constant attention, so here is the plan for 3.3:
December 19, 2019, at 07:03 PM
by
- Added lines 7-77:
https://blogopensips.files.wordpress.com/2019/12/opensips-3.3-crafting.jpg Routing calls and handling large volume of traffic is not a challenge anymore for OpenSIPS. The upcoming 3.3 release will focus on complex call crafting, basically on increasing OpenSIPS's ability to create and handle complex calling scenarios where multiple SIP calls are mixed and interacting. Or shortly said, the 3.3 release will address the Class 5 specific calling features and how to control such calling features via APIs. As usual, all the OpenSIPS major releases are in depth presented during the OpenSIPS Summit yearly events. So, the 3.3 release is the star of OpenSIPS Summit in Amsterdam, May 2020.
Class 5 calling ingredientsWithout actually using a Back2BAck model, but simply operating with calls (dialogs, UACs or UASs), many complex class 5 calling (and call mixing) scenarios may be scripted. Calling APIA new OpenSIPS module, placed on top of dialog module, will allow remote control over the calls going through OpenSIPS. The module will expose an simplify set of command (API like) for setting up new calls, for answering and terminating calls, for transferring or putting on-hold calls - all these without interacting with the end-devices, but triggering and handling the action only from the OpenSIPS (as proxy) level. Call mixingAnother new OpenSIPS module, that is able to manipulate calls/dialogs going through OpenSIPS, along with UAC/UAS dialogs (call originated or terminated into OpenSIPS), with the sole propose the mixing the RTP media between these multiple flows. The idea is to make possible the injection or stream of media from / to proxied calls, with the help of auxiliary calls initiated by OpenSIPS. Typical example is to play media within an existing call/dialog with nothing more than simple re-INVITEs - OpenSIPS will initial a new sip call to a media server, in order to get the RTP stream for the playback and it will push it into the proxied call by triggering in-dialog re-INVITEs. Per-call hooksAs we already have for transactions, the dialog module will allow the script writer to set, in a per-dialog fashion, script routes to be triggered by various dialog events. Similar to t_on_failure(route), you can do dlg_on_timeout(route) to have a route called when the dialog lifetime is exceed. In the route, you may decide to prolong the lifetime, to terminate the call or do any other login. We can foreseen dlg_on_answer(route), dlg_on_terminate(route)' (and more) triggers, which will give a better interaction and control over the ongoing calls. SDP topology hidingDue to the specificity of class 5 scenarios, there is a real need to completely decouple the SDP's (not only from IP/port perspective) from the caller and callee side, like hiding the originator or overwriting the session name and version. DTMF supportFor both RTProxy and RTPEngine, OpenSIPS will be able to report to script the DTMF sampled from the passing RTP. This will make possible the implementation of simple IVRs or authentication via DTMF with nothing more than OpenSIPS and the media relay. Extended BLF supportIn Class 5 services, BLF is an important feature. Beside working out clustering support for BLF, an important task is reworking the BLF implementation to be call-branch aware, to be able to properly report the call events in parallel calling or call hunting scenarios. Dialog module enhancementsWe are looking at a good set of additions for the dialog module, like:
Back-to-back supportThe existing B2B implementation in OpenSIPS has some limitations, so we are looking to overcome via some major rework here. Script driven B2BInstead of using the XML scenario to drive the B2B logic (mixing between the calls), we want to use the OpenSIPS scripting for the purpose. This will eliminate all the limitation of the XML language (logic and action) and it will tremendously increase the level of integration of the B2B engine with the rest of the OpenSIPS functionalities. Shortly, more complex B2B logic will be possible, and also better integrated with the rest of OpenSIPS. B2B clustering supportTo be 100% production ready, an High-Availability support maybe available for the B2B engine. This will be achieved by adding clustering and replication support for the B2B calling. B2B contextAn important improvement of the B2B engine will be the addition of the B2B context, to help in correlating all the entities (UAC, UAS) part of a B2B session, to attach custom data to the entities and to exchange such data between the entities. This will help with Accounting and media relaying support for B2B, but also with building custom data sharing inside a B2B session (or between the sessions)
Call CenterFor 3.3, we are looking at:
Device Feature Key Synchronization (DFKS)DFKS support is planned for OpenSIPS 3.3. This will help to keep feature settings in sync between multiple device and application servers, an essential need in a class 5 / PBX environment.
STIR/SHAKENApril 16, 2019, at 10:25 PM
by
- Deleted lines 6-86:
https://blogopensips.files.wordpress.com/2018/12/opensips-3.3-icon.png For the upcoming OpenSIPS 3.3 release (and 3.x family) the main focus is on the devops concept. This translates into introducing and enhancing in OpenSIPS features / capabilities that (1) will increase the easiness when comes the writing / developing OpenSIPS scripts and (2) simplify the operational activities when comes to running and managing OpenSIPS. This OpenSIPS 3.3 release is the star of OpenSIPS Summit in Amsterdam, April-May 2019 - beside presentations and workshops around the new cool things in this version, OpenSIPS 3.3 will also be the subject of several interactive demos on its new capabilities. Script Development aspectsGeneric Preprocessor SupportThis feature adds full built-in pre-processing support for the OpenSIPS script. OpenSIPS 3.3 integrates various existing pre-processors within OpenSIPS. This simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it). Even more, you will be able to use your preferred pre-processor and align OpenSIPS with the rest of your system (M4, Jinja, Embedded Ruby or others). Module Functions Now Benefit From a New Parameter InterfaceAs a response to frequent mailing list complaints of wildly varying behaviors across different module functions (e.g. some accept integers/strings as inputs while others accept both integers/strings or variables holding such values), we've introduced an abstract layer which handles the parameter passing task for all module functions, effectively making all of them more powerful by globally allowing flexible input. An added benefit is that new OpenSIPS modules are now even faster to develop. See the new function calling conventions here. Operational aspectsRouting Script Re-loadOpenSIPS 3.3 exposes the valuable ability of reloading the routes (not the module configuration) during runtime, with zero penalties and with zero loses as traffic. See the documentation of the MI "reload_routes" function. Processes Auto-Scaling SupportThis is the ability of OpenSIPS to scale up and down the number of processes at runtime. Basically OpenSIPS is able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes). New OpenSIPS CLI (Command Line Interface) toolStarting with OpenSIPS 3.3, the old opensipsctl tool becomes deprecated (as functionality and as software) and it is replaced by the new opensips-cli - a powerful Python3 application that allows you to interact in a smart way with OpenSIPS, to invoke advanced tools such as diagnose or tracer, as well as to perform DB provisioning. Read a full description of opensips-cli here. Selectable Memory Allocator SupportThis feature allows the internal memory manager to be selected at startup time. In OpenSIPS 3.3, the memory manager selection becomes a startup option, via command line arguments, allowing you to change it without any need to recompile or redeploy. Read a full description of this feature here. Internal Memory Persistence during RestartAs there are several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions, OpenSIPS 3.3 is able to avoid the date loading and caching penalty during a restart - this segments of the internal memory do "survive" during the restart. This dramatically reduces the time to restart of the entire service. Unified Sharing Tags for ClusteringIn 2.4, each module (with clustering support) is managing its own sharing tags completely isolated from other modules - this make the operating OpenSIPS a bit difficult sometime, as for a single switch from active to backup, you need to individually inform and change the tags in several modules, via several MI commands. In OpenSIPS 3.3 we have now the sharing tags managed by clusterer module itself and shared between multiple modules. So with a single MI command, changing a single sharing tag, you can control all the cluster-aware modules (like dialog timeouts, nathelper pinging, dispatcher pinging, etc) Read a full description of this feature here. Integration aspectsMI Interaction StandardizationAn extensive rework of the Management Interface in an attempt to standardize and speed up development of external applications which need to interact with OpenSIPS. The custom, JSON-based HTTP calls of OpenSIPS 2.X are now replaced with the JSON-RPC version 2 standard. The custom, line-oriented syntax was completely dropped. XMLRPC and mi_html (former mi_http) were kept backwards-compatible. Read a detailed description of the new interactions here SMPP supportOpenSIPS 3.3 provides a new SMPP module that allows you to do bidirectional gatewaying between SIP and SMPP traffic - this is a powerful but flexible way to integrate with most of the SMS providers / gateways. Read a full description of this feature here. RabbitMQ Consumer supportA new RabbitMQ consumer module which manages connections with one or more brokers, subscribes for events and exports them at OpenSIPS script level via the event interface.
But the full list of goodies offered by OpenSIPS 3.3 (and a more technical one too), together with migration instructions, can be found on the OpenSIPS 3.3 release notes page. April 16, 2019, at 09:52 PM
by
- Changed line 5 from:
to:
Changed lines 8-31 from:
https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg?w=300&h=200 The OpenSIPS 3.3 version is built around the clustering concept - 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:
The best ofSIPCapture/Homer integrationFreeSWITCH integrationAs a powerful Class5 Engine, FreeSWITCH is the perfect complementary tool for OpenSIPS the restMigration from 2.2.x to 3.3.0?to:
https://blogopensips.files.wordpress.com/2018/12/opensips-3.3-icon.png For the upcoming OpenSIPS 3.3 release (and 3.x family) the main focus is on the devops concept. This translates into introducing and enhancing in OpenSIPS features / capabilities that (1) will increase the easiness when comes the writing / developing OpenSIPS scripts and (2) simplify the operational activities when comes to running and managing OpenSIPS. This OpenSIPS 3.3 release is the star of OpenSIPS Summit in Amsterdam, April-May 2019 - beside presentations and workshops around the new cool things in this version, OpenSIPS 3.3 will also be the subject of several interactive demos on its new capabilities. Added lines 16-88:
Script Development aspectsGeneric Preprocessor SupportThis feature adds full built-in pre-processing support for the OpenSIPS script. OpenSIPS 3.3 integrates various existing pre-processors within OpenSIPS. This simplify the scripting itself, the script portability across multiple servers and not to mention the entire deployment process of more complex platforms (where OpenSIPS is just a part of it). Even more, you will be able to use your preferred pre-processor and align OpenSIPS with the rest of your system (M4, Jinja, Embedded Ruby or others). Module Functions Now Benefit From a New Parameter InterfaceAs a response to frequent mailing list complaints of wildly varying behaviors across different module functions (e.g. some accept integers/strings as inputs while others accept both integers/strings or variables holding such values), we've introduced an abstract layer which handles the parameter passing task for all module functions, effectively making all of them more powerful by globally allowing flexible input. An added benefit is that new OpenSIPS modules are now even faster to develop. See the new function calling conventions here.
Operational aspectsRouting Script Re-loadOpenSIPS 3.3 exposes the valuable ability of reloading the routes (not the module configuration) during runtime, with zero penalties and with zero loses as traffic. See the documentation of the MI "reload_routes" function. Processes Auto-Scaling SupportThis is the ability of OpenSIPS to scale up and down the number of processes at runtime. Basically OpenSIPS is able to automatically scale up (by forking new processes) according to the volume of traffic, or to scale down (terminating some worker processes) if the internal load is low. This means you do not have to worry if your estimation on the number for worker processes is correct or not (will my OpenSIPS hold to the traffic??) or to worry about planning restarts during the night (to manually resize the number of processes). New OpenSIPS CLI (Command Line Interface) toolStarting with OpenSIPS 3.3, the old opensipsctl tool becomes deprecated (as functionality and as software) and it is replaced by the new opensips-cli - a powerful Python3 application that allows you to interact in a smart way with OpenSIPS, to invoke advanced tools such as diagnose or tracer, as well as to perform DB provisioning. Read a full description of opensips-cli here. Selectable Memory Allocator SupportThis feature allows the internal memory manager to be selected at startup time. In OpenSIPS 3.3, the memory manager selection becomes a startup option, via command line arguments, allowing you to change it without any need to recompile or redeploy. Read a full description of this feature here. Internal Memory Persistence during RestartAs there are several modules caching (in OpenSIPS internal memory, not in external no-sql cachers) large chunks of data, like Dynamic Routing, Dialplan, Dispatcher or Permissions, OpenSIPS 3.3 is able to avoid the date loading and caching penalty during a restart - this segments of the internal memory do "survive" during the restart. This dramatically reduces the time to restart of the entire service. Unified Sharing Tags for ClusteringIn 2.4, each module (with clustering support) is managing its own sharing tags completely isolated from other modules - this make the operating OpenSIPS a bit difficult sometime, as for a single switch from active to backup, you need to individually inform and change the tags in several modules, via several MI commands. In OpenSIPS 3.3 we have now the sharing tags managed by clusterer module itself and shared between multiple modules. So with a single MI command, changing a single sharing tag, you can control all the cluster-aware modules (like dialog timeouts, nathelper pinging, dispatcher pinging, etc) Read a full description of this feature here.
Integration aspectsMI Interaction StandardizationAn extensive rework of the Management Interface in an attempt to standardize and speed up development of external applications which need to interact with OpenSIPS. The custom, JSON-based HTTP calls of OpenSIPS 2.X are now replaced with the JSON-RPC version 2 standard. The custom, line-oriented syntax was completely dropped. XMLRPC and mi_html (former mi_http) were kept backwards-compatible. Read a detailed description of the new interactions here SMPP supportOpenSIPS 3.3 provides a new SMPP module that allows you to do bidirectional gatewaying between SIP and SMPP traffic - this is a powerful but flexible way to integrate with most of the SMS providers / gateways. Read a full description of this feature here. RabbitMQ Consumer supportA new RabbitMQ consumer module which manages connections with one or more brokers, subscribes for events and exports them at OpenSIPS script level via the event interface.
But the full list of goodies offered by OpenSIPS 3.3 (and a more technical one too), together with migration instructions, can be found on the OpenSIPS 3.3 release notes page. March 28, 2018, at 05:33 PM
by
- Changed lines 8-15 from:
http://www.gearitservices.com/Portals/0/SitePics/SystemIntegration.jpg
The OpenSIPS 3.3 version is built around the integration concept - the OpenSIPS ability to integrate and work together in all possible means with other projects, protocols, systems or concepts. to:
https://blogopensips.files.wordpress.com/2017/11/google-idi_018-1.jpg?w=300&h=200 The OpenSIPS 3.3 version is built around the clustering concept - 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:
Changed lines 20-23 from:
The integration with the SIPCapture engine was a hot topic again. The work in this area focused in adding two new concepts (both on OpenSIPS and SIPCapture sides) when comes to capturing:
to:
Changed line 25 from:
the restto:
the restMarch 16, 2017, at 06:49 PM
by
- Changed lines 13-19 from:
The success of this release - in terms of achieving its integration goal - was strongly weighted by the collaboration with the teams of the partner projects, like SIPCapture, FreeSWITCH or CGRates. A collaboration in terms of ideas, brainstorming, solutions and of course, work. A collaboration that Integrationto:
The success of this release - in terms of achieving its integration goal - was strongly weighted by the collaboration with the teams of the partner projects, like SIPCapture, FreeSWITCH or CGRates. A collaboration in terms of ideas, brainstorming, solutions and of course, work. A collaboration that resulted in solutions and benefits for all the involved communities. The best ofSIPCapture/Homer integrationThe integration with the SIPCapture engine was a hot topic again. The work in this area focused in adding two new concepts (both on OpenSIPS and SIPCapture sides) when comes to capturing:
FreeSWITCH integrationAs a powerful Class5 Engine, FreeSWITCH is the perfect complementary tool for OpenSIPS Added lines 29-30:
March 16, 2017, at 06:33 PM
by
- Added lines 1-25:
About -> Available Versions -> 3.3.x Releases -> Release 3.3.0 OverviewOpenSIPS 3.3 philosophy http://www.gearitservices.com/Portals/0/SitePics/SystemIntegration.jpg
The OpenSIPS 3.3 version is built around the integration concept - the OpenSIPS ability to integrate and work together in all possible means with other projects, protocols, systems or concepts. Integrationthe restMigration from 2.2.x to 3.3.0? |