Restcomm

We are proud to announce our Mobicents Sip Servlets 1.3 version , certified against the Sip Servlets 1.1 specification and working on top of Tomcat 6.0.20 and JBoss AS 5.1.0.GA .This release doesn't propose Mobicents Sip Servlets on top of JBoss ... [More] 4.2.x series anymore. If you need still need support for it, we recommend you to either upgrade to the JBoss 5.x series or buy a JBCP subscriptionAs such our latest release's focus was essentially on the JBoss 5.x version and has a focus on stability and increased performance and the move to JSR 309 for all media examples. This also means Media examples can run on Tomcat as well now :Updated JAIN SIP Stack with better memory and CPU usage, which shows up to 50% perf improvementsMove all MSS Media Examples to JSR 309New Extensions for features outside the JSR 289New Diameter Example Showcasing the usage of Ro/RfMobicents SIP/Converged Balancer reached 1.0.0.FINALClustering and High Availability where many bugs were fixedThe other highlights of this release are :Move to Mobicents Media Server 2.0 CR2Move To Mobicents Diameter 1.2.1More than 40 bug fixesMobicents Sip Servlets is shipped with :Application Router Management Console to configure the Application Router to route SIP Messages to your applicationsAn Enterprise Monitoring and Management Console to effectively manage and monitor the server and your applicationsEducational converged example : Click To CallDiameter event charging example : Diameter Event ChargingFor JBoss 5.1.0 only, Mobicents Media Server 2.0.0.CR2 , Mobicents Diameter 1.2.1.GA , the Mobicents SIP load Balancer 1.0.FINAL and 'all' profile in JBoss with predeployed click to call distributable application to test clustering and mid call failover.Downloads are here, online documentation is here, User Guide is here, the 1.3 changelog and roadmap is here and the Mobicents Google Group for feedback and questions is here.Try out this new awesome release and give us your feedback !Enjoy and Have Fun !The Mobicents Sip Servlets Team [Less]

Mobicents Media Server team released the second stable version of MGCP Impl stack. The main focus was to improve the performance to a level where MGCP signaling doesn't hamper the media quality. We are very happy to take MGCP Stack to a level where ... [More] it can easily achieve 1000 CPS rate, where 1 CPS is round-trip of CRCX, RQNT and DLCX request/response.One of the major changes incorporated is entire stack is now single threaded. This is very important for predictable behavior and to make sure that thread context switching doesn't go beyond control, where media processing cannot be started and executed in stipulated time.The distribution can be found on SourceForge.net. The binary package ismobicents-mgcp-impl-2.0.0.GA.jar:https://sourceforge.net/project/admin/explorer.php?group_id=102670SVN Trunk Checkout http://mobicents.googlecode.com/svn/trunk/protocols/jain-mgcpSVN Trunk Browse http://code.google.com/p/mobicents/source/browse/#svn/trunk/protocols/jain-mgcpSVN Tag Checkout http://mobicents.googlecode.com/svn/tags/protocols/jain-mgcp/mobicents-mgcp-impl-2.0.0.GA/SVN Tag Browse http://code.google.com/p/mobicents/source/browse/#svn/tags/protocols/jain-mgcp/mobicents-mgcp-impl-2.0.0.GAMobicents MGCP Home PageLooking for your feed backEnjoy the most powerful MGCP Stack :) [Less]

Please vote for us if you want to see us at JUDCon : The Free JBoss Users and Developpers Conference held one day before JBoss World 2010 in BostonHere is our submission Title: Mobicents Reloaded (aka 2.0), The Open Source Communications Platform ... [More] Target audience: Telco or Converged (Mixed Telco and Web/JEE) Java Developers & Architects. Abstract: With the advent of IP Convergence, the latest generation of enterprise and web applications are now integrating seamlessly telecommunications and mobile features to enhance the overall user experience, increase customer retention and generate new sources of revenue. Discover how Mobicents 2.0 can help you build those true innovative converged applications through its main components, fully integrated into the JBoss 5 Application Server :JAIN SLEE 1.1 (JSR 240) container : a high-performance, scalable and fault tolerant Service Level Execution Environment designed to support the rapid development of robust telecommunications applications in JavaSIP Servlets 1.1 (JSR 289) container : a container based model that is an extension of the well understood HTTP Servlet model for Telecommunications Over IP applications. It was designed to simplify the development of SIP based applications and convergence with existing or new Java EE applicationsMedia Server (JSR 309) : deliver best-of-breed media gateway functionality to add IVR, Conference,Announcements and recording features to your applications featuring highest quality and allowing you to bridge to the existing legacy phone infrastructure.Diameter : A complete stack allowing you to add to your Telco applications some must-have real world features - Authentication, Authorization and Accounting - to add charging features to your telco applications.SIP Presence Server : Provides presence functionalities to SIP-based networks to enhance your application with Buddy Lists, Presence State, Geo-Location, Message typing information, ... It will also show real world examples how telecoms leverage Mobicents for innovative converged Telco 2.0 applications. Voting happens here :https://community.jboss.org/ poll.jspa?poll=1042Thanks in advance and hoping to see you there ! [Less]

This interesting requirement just keeps popping-up in the middleware world and is a topic of many threads in developer discussions as we are designing our HA architecture to be adequate and performant. The problem stems from a common deployment ... [More] architecture where you have two or more data-centers in distant geographical locations (think WAN distance, where LAN is not possible) . Each data-center site has the same service deployed, but is responsible for serving only the requests from their geographical area. All data centers are independently fault-tolerant, but if one site goes down for any reason, this would cause service outage in the area it is supposed to cover.Geographical failover usually refers to being able to temporary redirect the requests to other more distant data-center sites when a local total data-center failure occurs. Even if it is slower or more expensive, it is better than a completely unavailable service.This problem is common for HTTP and SIP, and the strategies to solve it are very similar. The challenge is in two aspects:Load balancing. Obviously, you need to make sure your local load balancers survive the data center failure. There are many ways this can done, but commonly you can just host the load balancers somewhere close to the users and keep it isolated from the data center. You should also make sure there is enough backup power and network infrastructure to keep them alive for a few hours or days.In Mobicents and JBCP, we introduced pluggable algorithms for the SIP/HTTP converged load balancer, and it is not hard at all to come up with a working solution. For instance, the load balancer algorithm may have two lists of server nodes - local nodes and distant nodes. If and only if all local application server nodes are dead, then the load balancer can start routing to the distant nodes. Plain and simple.If you are using a distributed load balancer (shown in the figure on right), one per site, it will behave the same way, and you may have several additional options depending on the IP load balancer capabilities.As long as the SIP load balancers are aware of the topology, the IP load balancer doesn't have to be aware of the other data-centers. It might be possible to instruct the IP load balancer to route requests to the backup data-center site, but the mechanism doesn't depend on it.State Replication (a.k.a What happens with the ongoing calls after the failure?). In the case of complete data-center failure, the whole LAN cluster will go down. Let's first take a look at the case where Mobicents nodes only replicate state within the data-center network.The ongoing calls are likely to have some state associated with them and this state will be lost without replication. Unlike HTTP, in SIP the containers generally do not deliver requests to the applications if their dialog state doesn't exist in the protocol stack. SIP has strict rules about the state machines in the dialogs and transactions, thus the overall consistency depends on that state. All SIP requests sent after the failure would not succeed and the calls are technically lost. But, let's look at what exactly happens with lost calls in the following cases:Simple media calls, audio or video calls - once the SDP exchange is complete the users can hear each-other and have a normal call without any SIP messages. So the failure in the SIP server will not affect them at all. As long as the Media Server is alive or the Media is flowing directly between the User Agents, the call will be fine. When the users hang-up, the BYE is lost, but it won't matter any more, because the call is over. Unless you need to capture the BYE and do some logic, you will be fine after the failure.SIP-intensive applications - presence, chat, some IVR applications and so on. In these cases the application will fail due to the lost state.Being aware of the limitations, lets see what are the options of for state replication between data-centers.First, you have to realize that if you had enough network capacity to replicate the call state to distant nodes, you could just organize all nodes in small JBoss clusters where the nodes are from different geographical areas. JBoss already has a lot of settings in JBoss Cache/Infinispan and JGroups to fine-tune the connections, even if there is no dedicated feature for geography.Thus, let's assume you don't have enough bandwidth for that. At this point it is very-application specific, because you must decide what part of the state you can lose. There are several options:Partial replication per call between the geographical areas - lose some bits from each callRare replication - do the full replication, but only in steady-state calls when changes are unlikely to occur.Priority calls - pick high priority calls and only replicate them.No replication - invest in reducing the risk of complete data center failure. How hard is that? If the data-center is down, but your users are still online, this implies that there is massive working infrastructure somewhere. Moreover, power and network backup resources are available cheaply and they scale well. In fact, I can think of many reasons why the geographical replication methods mentioned above are not a good idea:There may be a noticeable memory impact. In most implementations the local and the geographically replicated call state resides in different memory structures (so double the memory).The performance impact may be huge - first because of the additional replication protocol logic in each node and second because your data centers must run at lower utilization to be ready to take the extra load in case of data-center failure.Incidentally, the long distance network bandwidth is the most expensive. So you will have to pay for that as well.Investing in hardware fault-tolerant resources for your data-center makes the reliability independent of the software. In other words - even cluster-unaware applications will benefit and will be more reliable.Even if you recover some SIP state and your SIP applications don't fail, you still need to think how to keep the Media Servers alive or to switch them over to the other data-center.Partial replication in general will still produce a lot of lost calls. It is just on best-effort basis.Application are hard to code and test in partially replicated environment. It is an explosion of cases to be considered and tested when developing.In summary, the geographically redundant load balancing is justified and easy to achieve at reasonable price. However state replication between data-centers is too expensive. It is much more efficient to focus on reducing the probablity of data-center failure, which is low anyways. Unless you have some service-specific condition that really fits the model, there is no point in state replication between data-centers. [Less]

Hi all,With the natural evolution of mobile networks towards LTE, 4G networks and the likes, soon we will be in this beautiful world of all IP Communications. We figured that even though Cell Phones were kind of cool, what would be the next step to ... [More] communicate effortlessly. Based on some research done throughout the world and recently some breakthrough on Brain to Brain Communications, we thought it was time to prepare our next move and prepare people to communicate and act with the digital world in a different way and call each other effortlessly by using brain to brain communications applied to telecommunications.Since Brain to Brain Communication is cuurently using electrodes, a computer and an Internet connection. Replacing the electrodes and computer by a little Brain-Computer Interfacing (BCI) device (that would look like a bluetooth earplug) that will be used for capturing brain signals and translating them into bits and will send those bits over the wire through a new protocol called Mobicents Brain's Fool Protocol (MBFP) just like a 4G cellphone would do. The Mobicents server will act as a gateway and convert MBFP to SIP so that you can call your buddies.The possibilities are limitless again and will mostly depend on the device capabilities (that will evolve over time as science gets better knowledge of the brain) that could stream video or what your buddies see directly into your brain, or Text Message you, or send SMS... If you're scared about the government tapping your brain or hackers unleashing viruses, trojan and the likes, security will be a big concern and taken care of very seriously but we can't promise anything, no software is bug free...This won't be limited to Brain to Brain actually, one could easily create Business to Consumer (B2C) type of applications where you wouldn't need TV or 3D TV anymore : video streamed directly into your brain with all the sound, smells, pain, joy etc, what an awesome experience... Where games would be a real brain control world experience, not motion controlled anymore...Where you could record your life literally and not only share pictures and videos with your friends through facebook but real life memories with emotions through the new LifeRecorded social networkThe good thing also would be for disabled people not being able to speak, this way they could communicate much easier and for the blind people to actually see since the device could be tied to a camera that would stream the live feed in their brain...And again this technology will be open source for your greatest pleasureAs they say the brain is the limit... [Less]

Last week or two were quite fruitful for mobicents team. What came out from under our hood?Well:Jain MGCP Stack RC7 - last RC, more info can be found here.Diameter 1.2.0 GA - JSLEE 2.x resources, more info can be found here.MMS 2.0.0.RC1, first Release Candidate from 2.x trunk of MMS, more info can be found here.More will come.

Some changes in maven tools in mobicents platofrm:fix metadataadd jslee 1.1 service archetypeSo now all desired archetypes are there.Maven archetypes can be found here.Also there is good article how to use archetypes to quick start projects, it can ... [More] be found here.How to use archetype from CLI? Please follow:checkoutinstall with mvn installuse following command(for service):  mvn archetype:generate -DarchetypeGroupId=org.mobicents.tools.maven.archetype.slee -DarchetypeArtifactId=jain-slee-11-service -DgroupdId=xxx.y -DartifactId=TestSLee11Archetype_service -DarchetypeVersion=1.0.0.BETA2-SNAPSHOT , where:archetypeGroupId - archetype grouparchetypeArtifactId - id of archetypearchetypeVersion - archetype version, once it is released, it should not be requiredgroupdId - new groupd id of created projectartifactId - new artifact id of created project, also directory name [Less]

My last post about JSLEE 1.1 describes theory of classloading in v1.1 containers. However, how does it look in practice?Well, I must say it looks and works much better than earlier model. But.. yes, there is one small "but", due to inheritance ... [More] restriction it may sometime prove to be problematic, atleast for certain cases. Case 1: General Class Loading schemeTo make problem a bit closer, lets consider two services, each service is composed from the same sbbs: - Sbb[1] - Sbb[2] - Sbb[3]Each sbb references the same RA Types and Profiles - RAType[1] - Profile[1] - Profile[2]To make this a bit more complicated - each service is independent. That is each can be deployed separetly and provide service.Now lets imagine two things:SBBs extends super class which provides common fields(RA Type SBB Interface) methods to manipulate profile, etcThere is shared Utility class which manipulate RA Type message factories to create specific messages, manipulate profiles, etc.Now there is no problem in 1.0 container as classloading was flat. Everything works fine, one or many sbb jars/DUs - it still works.However when one wants to deploy this set of services in 1.1 container, problem shows. In 1.1 container (as it is a bit more organized) we would like to have everything separated:library(Library[1]) with: super class of SBBs, Utility classes and similarsbb-jar.xml, sbb-jar file for each sbbDU for each somponent - services,library,profile and RASince library contains classes each sbb use, each sbb-jar.xml declares dependency on library.From first glance it looks like this deployment should work from kick. Well, it wont...Lets consider Utility class, it operates(depends) on: - RA Type events - RA Type classesSbb super class is very similar in this matter. Both classes are contained in our Library[1].What is wrong? Library[1] does not have any way of referencing RAType classes. That means that Utility class (as well as Sbb super class) has no access to definition of those classes. This will cause failure during runtime or sbb verification.Conclusion: using single jar file for sbbs allows to make this problem dormant. However there seem to be more favored way for 1.1 container. That is:each functional component declares library with classes it usesfunctional component declares dependency on its library in its xml fileany other component may ow declare dependency on library to use certain classesFor this example it would mean following: RA Type[1] Library[1] is declared. LIbrary[1] declares dependency on  RA Type[1] Library[1].Case 2: Event sharingThis problem happens only on shared deployment. That is JSLEE and non JSLEE aplication is deployed in the same container.Lets consider simple web application which fires event "X" into SLEE. Event "X" is received and processed by SLEE service.This makes it clear that X.class should be present in two places:SLEE - since there is service depending on it.web application archive, since it fires it.Since JSLEE v1.1 container no longer shares its classes outside container, it is logical to assume that jar containing X.class should be in both: JSLEE and web archive.Well, logic fails here. It wont work. It will cause well known exception:ClassCastException: Can't cast X to XTo make this work following steps should be followed:- jar containing X.class should be in container library directory- events.jar deployed within SLEE should contain only xml file with even definitionsThats it. [Less]

Open a command line terminal$ sudo apt-get install ncurses-dev$ sudo apt-get install build-essential#Grab sipp 3.1 from sourceforge.net $ wget -m -nd http://downloads.sourceforge.net/project/sipp/sipp/3.1/sipp.3.1.src.tar.gz#extract it locally$ tar ... [More] -xzf sipp.3.1.src.tar.gz$ cd sipp.svnOpen ./sipp.svn/scenario.hpp and add this line#include <limits.h>after#include <sys/socket.h>save the file, and in the terminal do $makeYou're done ;-)UPDATE : The latest unstable snapshot available from http://sipp.sourceforge.net/snapshots/sipp.2009-07-29.tar.gz does not have this problem and does not throw *segmentation fault* as sipp 3.1 does now on my ubuntu 10.04 [Less]