1 2 3 Previous Next


40 posts

SIP Servlet 2.0 and CDI Blog

Posted by binod Jun 18, 2015
SIP Servlet 2.0 makes it possible to use CDI with SIP Servlet applications. It supports SIP Servlet POJOs as component classes that qualify as CDI managed beans. It also defines SIP specific CDI beans and scope types. Lets explore each of them. SIP Servlet POJOs qualify as CDI managed beans With this, now it is possible to inject CDI beans into SIP Servlet POJOs making all features of CDI available to SIP Servlet applications. Note that the lifecycle of the SIP Servlet POJOs are still managed by the SIP container just like other component classes defined in Java EE specification. It also applies to SIP listeners and regular SIP Servlets. SIP specific built-in beans There are five SIP specific built-in beans specified as listed below.
  • javax.servlet.sip.SipFactory
  • javax.servlet.sip.SipSessionsUtil
  • javax.servlet.sip.TimerService
  • javax.servlet.sip.SipApplicationSession
  • javax.servlet.sip.DnsResolver
These objects, which are otherwise familiar to SIP Servlet developers, can now be injected into the a SIP Servlet using @Inject. SIP specific CDI scopes
  • @SipApplicationSessionScoped
  • @SipInvocationScoped
There are two standard scope types defined. When a CDI bean is of SipApplicationSession scope, the lifecycle of that bean will be bound to a SipApplicationSession.  With this, applications can be developed without having to recreate state objects from attributes saved in SipApplicationSession. The lifecycle of the bean will be managed by the container. Given that containers usually manage concurrency and availability at the level of SipApplicationSession, this scope becomes an important feature. Similarly Lifecycle of an object with SipInvocationScope is tied to the invocation of a SIP Servlet POJO or any listener. Here is an example of a bean which is SipApplicationScoped..
public class MyProxy implements Serializable {

  private long startTime;

  public void forward(SipServletRequest req) throws Exception {
    SipURI uri = (SipURI) req.getRequestURI().clone();
    Proxy p = req.getProxy();
    startTime = System.currentTimeMillis();

  public void subsequentRequest() {
    System.out.println("Total elapsed time is " +
      (System.currentTimeMillis() - startTime));
Also, see how a POJO uses it. Note that an instance of myProxt will be is created for each call by the container.
public class SipHandler {

  @Inject MyProxy myProxy;

  public void onInvite(SipServletRequest request) 
    throws Exception {

  public void onRequest(SipServletRequest request) 
    throws IOException {

Hope you find this useful.

JSR 359: SIP Servlet 2.0 Blog

Posted by binod Sep 3, 2012
JSR 359 has been accepted by Java SE/EE executive committee a month back. Please see the specification request for the content of this revision of SIP Servlet 2.0 specification. We have established a java.net project for cordinating and communicating the progress of the specification. The work is about to get started. At the moment, the expert group is being formed and some of the leading sipcontainer/telco vendors have already joined the group. Here is a short how to wiki on "joining the expert group". I will be using this blog for posting the progress on the JSR. So, please watch this space!

A preview release of SailFin CAFE is now available. We announced this project during last JavaOne and then onwards a lot of progress has been made. A number of people from Sun/Oracle and Ericsson contributed code to the project. And many in the community have tried it and gave feedback. Thanks a lot for all contributions. I also want to note that the framework is known to work with multiple sip servlet containers now.

If you are at JavaOne/Oracle Open World today, attend CAFE BOF at 7pm tonight at Hilton to get detailed information on the framework. 

Here is a list of key features. Take a look at the javadoc for all the java apis. 

  • Conversation 
  • Conference 
  • DTMF
  • Instant Messaging (simple text messaging, typing detection)
  • MSRP (File Transfer, Messaging)
  • User Procedures (Registration and Presence)
  • Presence Simulator
  • Media (Playing, Recording etc)
  • Security Annotations
  • Initial REST support
  • Extensibility

A number of blogs are written by developers that give a good idea on the framework. Here is a list of some important ones. The front page of the sailfin cafe website has an exhaustive list of the blogs.

A number of samples are available. You can check them out from svn repository. (svn co --username guest https://sailfin-cafe.dev.java.net/svn/sailfin-cafe/trunk/cafe-samples). Following are some applications available for trying out. 

  • Getting Started (two party call, conference)
  • Music Store
  • Conference Application (with DTMF, Announcements etc)
  • Greeting service
  • Call-When-Online (Presence + Call)
  • Hunt Group

 Download and use it, and send any feedback to users@sailfin.dev.java.net.

Here is a list of SailFin CAFE presentations that we will be presenting in next 2-3 months.

This week there are couple of presentations. The first one is at Munich JUG at 7pm, monday 2nd August. More details are here. The next one is an Industry Talk on tuesday (between 9am and 10.30am) at IPTComm, Munich, Germany. Visit IPTComm website for more details.

In september, there is BOF session at JavaOne. This will be at Tuesday 21 September 7pm at Hilton San Francisco. 

The next one is a Conference Session at TMCNet ITExpo, Los Angeles Convention Centre at 11.30am October 5.

Please join us for the presentation, if you are around locally or if you are attending these conferences.


Here is the second part of the CAFE fundamentals blog series. This time, I am explaining two important interfaces called Communication and UserProcedure with an example. If this is the first time you are hearing about SailFin CAFE, I recommend reading the CAFE fundamentals article and the blog on writing your first CAFE application. The core of this discussion is an example which shows triggering a Conversation when the callee comes online. Just like the earlier examples in my previous blogs, this one also doesn't have any SIP Servlets and is written using the higher level API provided by SailFin CAFE.

At first, lets take a look at Communication interface in CAFE. Just as the name implies it is any form of Communication between 2 or more Participants. It can be text/audio/video/filetransfer etc. There are 6 kinds of Communication interfaces exposed by CAFE at the moment.
  1. Conversation : Communication between two Participants. Typically this is between two user agents (or sip phones). It can also be between a sip phone and a Player/Recorder
  3. Conference: As the name implies it is a communication between more than two user agents, which mandates the use of a media mixer in the media server always. 
  5. IMConversation: This is a text chat between two user agents. 
  7. IMConference: A text chat between more than two participants, which is brokered by the server.
  9. MSRPConversation. A two-party communication that uses MSRP protocols, mainly to transfer files and sending messages. 
  11. MSRPConference: A multi-party communication that uses MSRP protocol internally. This is always brokered by an MSRP relay server in CAFE.
A Communication can be created as a result of arrival of a SIP Message from a user agent or it can be created explicitly by the application (eg: web application). If the Communication is created as a result of an incoming SIP request, CAFE will always treat it as a two party communication. Application can then use the INITIALIZATION event in the CommunicationBean to convert such a two party communication to a multi-party communication. Take a look at this blog for an example.

On the other hand, any interaction or a procedure between a user agent and the server is represented as the interface UserProcedure. Registration, PresenceSource, PresenceWatcher and WatcherInfoSubscriber are the types of UserProcedures. Each UserProcedure has a certain life span associated with it, after which it will expire. Application can refresh the UserProcedure to extend its life. For example, a Registration created by the application would timeout after a period of time. Application can refresh the registration during the ABOUTTOEXPIRE event. Erik has explained UserProcedures in his blogs here and here.
Now, lets take a look at a real example. In this example, a Conversation is initiated either by sip user agent or a web application. However lets imagine that the callee's phone is not online yet. In this service, application creates a PresenceWatcher to watch the Presence status of the callee for for a stipulated period of time. If the callee bring up his phone by that time, the CommunicationBean is notified with a NOTIFICATION pertaining to the PresenceWatcher and the call is then initiated.

The example application contains two CommunicationBeans. First one, CallBean is of the type Conversation for handling events related to Conversation and another (PresenceBean) with type PresenceWatcher to handle the presence notifications.

As you can see in the code, when the Conversation is rejected by the callee, the ParticipantEvent.Type.REJECTED will be invoked. There the application, creates a PresenceWatcher with an expiration time of 5 minutes. So, if the callee switch on his phone in next five minutes, the UserProcedureEvent.Type.NOTIFICATION is triggered in the PresenceBean. And the application in the event creates a Conversation to establish the call again between the parties.
Full source code of the application is checked into the SailFin CAFE SVN repository. Here are the steps to run the sample
  1. Install SailFin and SailFin CAFE as mentioned in this blog.
  3. Checkout the sample and build using maven 2. 
  5. Start the SIP client of one user (eg: Alice) and Make a call to Bob. [For X-Lite tips, see this blog]
  7. Since Bob's phone is not active, after a while, the call will be rejected by the server.
  9. Now start Bob's phone. The moment it starts, a call will be established between the Alice and Bob. 

 Play with SailFin CAFE and let us know your feedback at users@sailfin.dev.java.net.

SIP Servlets provide a server side Java abstraction to  SIP protocol and it is based on familiar servlet model. This enables an application developer to use Java servlet programming to write Converged applications. What exactly is the meaning of "converged applications"?  SIP Servlet Specification explains this as follows

"While the SIP Servlet API can certainly be implemented independently of the HTTP Servlet API, it is expected that many interesting services will combine multiple modes of communication, for example, telephony, Web, email, instant messaging and other server side components like Web services and other Java EE interfaces."
SIP Servlet specification defines SIP Application Session, which is a session that holds child protocol sessions (Http Session and Sip Sessions). The lifecycle of this Application Session is defined by the  application itself. Thus it provides a flexible mechanism to share data between HTTP and SIP Sessions on an application defined scope.  SIP Servlets also enable Java EE components to compose and send SIP requests as per RFC 3261.

SIP Servlets is one step in the right direction. I.e it provides a way to write applications that mixes SIP with other Java EE technologies. However, this forces application developer to learn SIP protocol. That would take the developer to the SIP RFC hell. Take a look at this RFC to list SIP RFCs and imagine an average web developer starting to write SIP applications.

H2G2. Dont Panic!

With that introduction, lets see how does SailFin CAFE simplifies the  SIP application development.

Communication Beans

SailFin CAFE provides what is called "Communication Beans". Essentially they are stateless POJOs that are annotated appropriately. The main difference is that, the bean handles the SIP protocol (and many other telco industry specifications from OMA, 3GPP and IETF) by default and  thus hides it from the developer. The developer can then write his logic to modify the behavior of  Communication Beans. This is done from the perspective of modifying the behavior of "communication" it  is handling rather than SIP protocol itself. By default the CommunicationBean will act as a simple B2bUA. Take a look at this 2-party call and this instant messaging examples for details.

A CommunicationBean can contain annotated methods to handle different events in the Communication.  Take a look at this example, which creates a Conference from the incoming call. Effectively this converts the incoming two party call to a conference. Under the hood, CAFE would use a JSR 309 resource adapter to create the media mixer with a media server and do the necessary SDP negotiation.  Whenever each event (annotated method) gets executed, the injected CommunicationContext would provide the relevent objects to the CommunicationBean implementation. Such objects are the Communication Object, The participant which invoked the event,  Instance of Message (for example a DtmfSignal or TextMessage). etc.

Convergence in CAFE and Agents.

A CommunicationSession object is injected into HTTP Servlets and CommunicationBeans (When we have Java EE 6 based SIP Servlet containers, this would also work on all kind of Java EE artifacts. Thanks to JCDI). An application can use this object to create any kind of Communication.    Different entities in a communication (eg: Communication, Participant, RegistrationProcedure) etc have  different lifecycles and there might be different events happening pertaining to these entities. A converged application might need to execute logic based on such events. For example, in a music player application,  when the communication gets "established", the application might want to play a music. Similarly,  in a conference application, when the host of the communication "joins" the conference, recording  might be activated. Obviously these events will be invoked in the CommunicationBean. But then how will application write their logic linking all these events?

To handle with this, CAFE provides the ability to attach "Agent" objects for different Communication artifacts. An "Agent" is an application defined object that contains data and logic specific to the application. An Agent can be Attached to a Communication or a Participant (or the same Agent can be attached to both). Now, application invoke the Agent to perform the application specific logic whenever the event occurs. Given Communication  artifacts are accessible both from Web Application and from the CommunicationBean, the Agent facilitate  Converged application development in an organized way.

A music player example application is checked in here, which uses most of the functionalities mentioned in this blog. Post any questions you may have of dev@sailfin.dev.java.net. Or follow SailFin on twitter at  http://www.twitter.com/sailfincs.

Much awaited GlassFish V3 is released today. The modular, OSGI based Java EE 6 product has been making headlines for some time now. I have been experimenting V3 for some time now, basically from the POV of SailFin and SIP Servlets. Here are some items on top of mind that are relevant for SIP Servlets and next SailFin release.

  1. Doing a modularized OSGI based SIP Servlet Container and SailFin CAFE is probably the most obvious item
  2. Java EE 6 has standardized module names and application names. That will be applicable for SIP Servlets, especially since application composition in SIP Servlets is based on SIP module names.
  3. The new JNDI namespaces introduced in Java EE 6, especially the module name is quite applicable for SIP Servlets. The current SIPFactory and SIPSessionsUtil lookup should benefit from the newly introduced namespaces (global, module,app) etc along with namespaces. Take a look at Java EE 6 specification (chapter EE5.2.2) for more details.
  4. The servlet extensibility introduced in the latest servlet specification is certainly applicable for SIP Servlets also, especially since Converged Application Frameworks are on the rise
  5. Asynchronous servlets and EJBs would help converged application development, since communication protocols are much more asynchronous than the Java EE technologies and hence it will be a good mechanism for integrating communication with
  6. CDI (JSR 299) is certainly important for SIP Servlets as well. Looking forward to using it for SailFin CAFE

Are there any thing else, you would like to see in SailFin v3? Do send e-mails to sailfin mailing lists (users@sailfin.dev.java.net).

Hope you have read my last blog on using SailFin CAFE with web applications. Mohit has added an entry on how to enable Communication capabilities in JSPs. The approach is exactly same except that the CommunicationSession object is available as a session attribute.

Take a look!


SailFin V2 released! Blog

Posted by binod Oct 27, 2009

SailFin V2 (Sun GlassFish Communications Server 2.0) is released today. See Srikanth's announcement and Prasad's roadmap entry. A number of new features have been added since we released SailFin V1 in January. These include high availability, rolling upgrade, flexible network topology, better over load protection, improved diagnosability, Java based DCR files for the load balancer etc. Diameter support is also available.

The key enhancement in high availability is a new replica selection algorithm for the session replication feature as explained by Sreedhar. It leverages the consistent hashing algorithm the converged load balancer uses. This eases the load distribution after a failure and makes the cluster much more scalable than SailFin v1. Converged Load Balancer itself has been enhanced to support writing DCR rules in Java.

Rolling upgrade capability leverages the session replication. That means, when the cluster instance is restarted after upgrading the HW or SW, the sessions will be restored by retrieving the session replica that exist in the cluster. Bhavani explains all those here along with an example that showcases session replication and rolling upgrade. If you are trying out HA in sailfin, take a look at these tips and tricks.

Flexible network topology allow better usage of multihoming features in the platform. Here is a picture that shows one such deployment architecture. Ramesh's blog here is a very good source of information.

Venu has been blogging very actively about diameter and security features in SailFin. Take a look to know more about Sh, Rf and Ro implementation in the diameter resource adapter here, here and here.

Over load protection has been enhanced significantly. Here is Robert's one pager that explains it. Sankar has then added the ability to receive JMX notifications when overload threshold is reached.

For more information on SailFin V2, please browse sailfin entries in the aquarium blog. Download and try V2 when you get some time. You may also try out the amazon images as explained by Sreeram. Send any feedback you may have to users alias.

Filter Blog

By date: