Mobicents is now being built and tested continuously on a high end Sun Netra 440 box running Solaris. This machine is a typical choice of telco carriers for their core network.
Read more: http://forums.java.net/jive/thread.jspa?messageID=34158&tstart=0#34158
Sunday, December 25, 2005
Monday, December 19, 2005
Mobicents presentation at JavaPolis
The JavaPolis Birds-Of-a-Feather presentation of Mobicents was quite fun. The room was full and there were a few standing people. The audience consisted mostly of developers with explicit interest in VoIP.
The discussion started with a quick poll. It turned out that 100% of the attendees were familiar with VoIP but none of them has written a VoIP application. This was no surprise to me. The first few slides of my presentation explained why I think most developers are not writing their own VoIP code. Several people in the audience shared their own thoughts on this paradox. It boiled down to two fundamental problems - 1) Until recently there was no widely available open source platform for developers to play with; 2) Unlike the Web, there is no truly public VoIP network, such that developers can deploy a new VoIP app and have anyone try it easily. Instead there are a number of VoIP islands such as Skype, Google Talk, and Yahoo! Messenger.
Then went into several examples of new kinds of communications services. Every had a chance to voice an opinion and add new ideas to the examples. It turned into a lively brainstorming session that made everyone realize that there are a lot of interestign applications that can be implemented when voice, video, mobility, location and web are mixed together.
The conversation was so involved that we went over time and had to leave the room because the next presenter walked in. The offline discussions we also pretty interesting. A number of folks wanted to know about the Mobicents roadmap and where they could help.
We also talked about SLEE best practices and architecture blue prints for complex applications such as call centers.
Take a look at the presentation and feel free to post your comment on this blog.
Mobicents-JavaPolis-2005.pdf
A good experience overall. The JSLEE community is growing out of the Early Adopters phase.
Ivelin
The discussion started with a quick poll. It turned out that 100% of the attendees were familiar with VoIP but none of them has written a VoIP application. This was no surprise to me. The first few slides of my presentation explained why I think most developers are not writing their own VoIP code. Several people in the audience shared their own thoughts on this paradox. It boiled down to two fundamental problems - 1) Until recently there was no widely available open source platform for developers to play with; 2) Unlike the Web, there is no truly public VoIP network, such that developers can deploy a new VoIP app and have anyone try it easily. Instead there are a number of VoIP islands such as Skype, Google Talk, and Yahoo! Messenger.
Then went into several examples of new kinds of communications services. Every had a chance to voice an opinion and add new ideas to the examples. It turned into a lively brainstorming session that made everyone realize that there are a lot of interestign applications that can be implemented when voice, video, mobility, location and web are mixed together.
The conversation was so involved that we went over time and had to leave the room because the next presenter walked in. The offline discussions we also pretty interesting. A number of folks wanted to know about the Mobicents roadmap and where they could help.
We also talked about SLEE best practices and architecture blue prints for complex applications such as call centers.
Take a look at the presentation and feel free to post your comment on this blog.
Mobicents-JavaPolis-2005.pdf
A good experience overall. The JSLEE community is growing out of the Early Adopters phase.
Ivelin
Wednesday, December 14, 2005
Google Talk and Jabber Software Foundation submit a proposal for Jingle - standard voice and video extension for XMPP
Google Talk is delivering on its promise to standardize the voice protocol. The team chose to support an ongoing effort at the Jabber Software Foundation by providing feedback to the Jingle protocol specification.
Here is an excerpt from the spec:
The spec document is written in an accessible language. It was easy for me to grasp the concepts and scetch out the basic interactions between calling parties. Looks like a protocol that should be relatively easy to implement in client devices.
The authors deliberately chose to push as much complexity as possible to gateways and servers. Even more so than in SIP. In several sections in the document the text points out why certain features were implemented differently than SIP, which shows the advantage that the authors had designing something from scratch taking into account lessons learned from SIP experience.
I have been told in the past from engineers at several telco operators that SIP is somewhat heavy to implement for thin mobile devices as compared to XMPP. At the time Jingle was not standardized, so the comparison could not have been complete. Still their experience was an indication that XMPP may be a formidable competitor to SIP for VoIP signaling.
For as long as both protocols are open standards, I am only expecting good things to happen for both mainstream developers and end user.
See the full text of the Jingle Specification Document.
Here is an excerpt from the spec:
Upon communication with members of the Google Talk team, it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified therein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.
The spec document is written in an accessible language. It was easy for me to grasp the concepts and scetch out the basic interactions between calling parties. Looks like a protocol that should be relatively easy to implement in client devices.
The authors deliberately chose to push as much complexity as possible to gateways and servers. Even more so than in SIP. In several sections in the document the text points out why certain features were implemented differently than SIP, which shows the advantage that the authors had designing something from scratch taking into account lessons learned from SIP experience.
I have been told in the past from engineers at several telco operators that SIP is somewhat heavy to implement for thin mobile devices as compared to XMPP. At the time Jingle was not standardized, so the comparison could not have been complete. Still their experience was an indication that XMPP may be a formidable competitor to SIP for VoIP signaling.
For as long as both protocols are open standards, I am only expecting good things to happen for both mainstream developers and end user.
See the full text of the Jingle Specification Document.
Subscribe to:
Posts (Atom)