1 2 3 Previous Next

binod

40 posts
There are some key differences to programming SIP applications compared to usual Java EE applications, which are mostly based on HTTP. Often SIP Servlets are used to create a service that involve multiple SIP Sessions and SIP Application Sessions. The SIP protocol is much more asynchronous than HTTP and hence SIP Servlet POJOs need to handle many kinds of requests and responses. Both these can lead to a number of scenarios which can cause concurrency issues. Lets look at one such scenario which can cause a deadlock.

https://www.dropbox.com/s/jsva7lzmc542eww/sipservlet-concurrency.png?raw=1

As you may see above, there may be situations two threads in an application may access the SIP Application Sessions locked by the other thread. Obviously, this also depends how exactly the container is handling the concurrency. In any case, it is a clear issue in writing portable applications. SIP Servlet 2.0introduces two capabilities to solve this issue.

1) A standard concurrency control mode for SIP Servlet Applications.

 package com.example; import javax.servlet.sip.SipServlet; @SipApplication (name = “Foo”, concurrencyMode = ConcurrencyMode.APPLICATIONSESSION) 
If you have an annotation like this in your SIP Servlet POJO, then the container performs concurrency control at the level of the application session. It ensures various tasks that access the application session are not executed at the same time.

2) A set of concurrency utilities for SIP.

Making use of JSR 236 (Concurrency Utilities for JavaTM EE) SIP Servlet 2.0 defined a few concurrency utilities for SIP Servlets. It help SIP Servlet Application to run a task concurrently with a specified SIP Application Session as the context. Note that the general behavior of these utilities are defined by JSR 236. SIP Servlet 2.0 defines the behavior of the specified JNDI objects specific for SIP Servlet Applications.
  • ManagedExecutorService
    : java:comp/ManagedSipExecutorService
  • ManagedScheduledExecutorService
    : java:comp/ManagedScheduledSipExecutorService
  • ContextService
    : java:comp/SipContextService
  • ManagedThreadFactory
    : java:comp/ManagedSipThreadFactory
Apart from these, the SIP Servlet 2.0 also defines three "execution properties" that allow an application to specify the SIP Application Session to use as the context while running the tasks. See below for the properties.
  • javax.servlet.sip.ApplicationSessionKey
    : Specifies the SIP application key.
  • javax.servlet.sip.ApplicationSessionId
    : Specifies the application session ID.
  • javax.servlet.sip.ApplicationSession.create
    : Indicates that the container creates a new SipApplicationSession and use it as the context.
2.a) Submitting a task with the SIP Application Session of SIP Servlet POJO as the context,
To do this, application do the following.
  1. Inject a
     java:comp/ManagedSipExecutorService
    using
    @Resource
    annotation
  2. Create a
    Callable
    or
    Runnable
    that contain the business logic.
  3. submit the
    Callable
    or
    Runnable
    from the SIP Servlet POJO.
Here is an example code
 @SipServlet public class ExamplePOJO1{ @Resource(lookup=”java:comp/ManagedSipExecutorService”) ManagedExecutorService mes; @Invite protected void onInvite(SipServletRequest req) { // Create a task instance. MySipTask implements Callable... MySipTask sipTask = new MySipTask(); // Submit the task to the ManagedExecutorService... Future sipFuture = mes.submit(sipTask); } } 
2.b) Submitting a task with a specific SIP Application Session as the context
To do this, application do the following.
  1. Inject a
     java:comp/ManagedSipExecutorService
    using
    @Resource
    annotation
  2. Create a
    Callable
    or
    Runnable
    that contain the business logic.
  3. Create a Contextual Proxy object of the
    Callable
    or
    Runnable
    using the
    java:comp/SipContextService
    utility.
  4. submit the Contextual Proxy object.
Here is an example code to explain how this may be done.
 @Resource(lookup = "java:comp/SipContextService") ContextService sipCS; @Resource(lookup = "java:comp/ManagedSipExecutorService") ManagedExecutorService sipMES; @Inject SipSessionsUtil ssu; public void doAsync(final String sasId, final String appState) { Map props = new HashMap<>(); props.put(SipServlet.SIP_APPLICATIONSESSION_ID, sasId); final SipSessionsUtil util = ssu; Runnable task = (Runnable & Serializable) () -> { final SipApplicationSession session = util.getCurrentApplicationSession(); int counter = (int) session.getAttribute("counter"); session.setAttribute("counter", ++counter); session.setAttribute("appState", appState); }; Runnable proxyTask = (Runnable) sipCS.createContextualProxy (task, props, Runnable.class, Serializable.class); sipMES.submit(proxyTask); } 
With these capabilities, the application can run the above scenario without concurrency issues.

https://www.dropbox.com/s/jmg9nn4ergbwij1/sipservlet-concurrency-new.png?raw=1

This is just a snapshot of the functionality being provided. There are a number of advanced capabilities possible. Some of the interesting ones are given below
  1. Use
     java:comp/ManagedScheduledExecutorService
    for scheduling tasks instead of TimerService
  2. Run the contextual proxy with specified SIP Application Session as the context directly on a thread (eg: MDB thread) without submitting the task
  3. You may also use a ManagedTask instead of Contextual Proxy.
Sorry for the long article. Hope this helps writing SIP Servlet Applications with better concurrency control and portability.
binod

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.. 
@SipApplicationSessionScoped
public class MyProxy implements Serializable {

  private long startTime;

  public void forward(SipServletRequest req) throws Exception {
    SipURI uri = (SipURI) req.getRequestURI().clone();
    req.setRequestURI(uri);
    Proxy p = req.getProxy();
    p.proxyTo(uri);
    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. 
@SipServlet
public class SipHandler {

  @Inject MyProxy myProxy;

  @Invite
  public void onInvite(SipServletRequest request) 
    throws Exception {
    myProxy.forward(request);
  }

  @AnyMethod
  public void onRequest(SipServletRequest request) 
    throws IOException {
    myProxy.subsequentRequest();
  }

}
Hope you find this useful.  

There are a number of topics JSR 359EG is working on. These are on a number of different categories. It includes improving the RFC coverage of SIP specification (SIP outbound), Modernizing programming (using POJOs), better alignment with Java EE (CDI, latest servlet spec), SIP over websockets, Extensibility, Better concurrency control, Updates to B2B etc. In this blog series, I am planning to give an update on these features and others that we are working on in the expert group. Lets start with SIP POJOs. Expert group in our f2f in January felt that, time is probably right to provide a simplified and more modern way to write SIP servlet applications. Also, SIP has much more methods and types of messages than a typical http servlet application handles (GET, POST etc). So, the need for a simpler programming model with a lesser dependency on

GenericServlet

is more obvious for a SIP servlets. So, with SIP Servlet 2.0, a POJO can be annotated with an @SipServlet annotation and the java methods in such a SIP POJO will be able to able act as SIP message handler. Following is an example of such a SIP POJO.

 @SipServlet public class FooPOJO { @Invite public void handleInviteRequest(SipServletRequest request) { //... } @Invite public void handleInviteResponse(SipServletResponse response) { //... } @ProvisionalResponse public void handleSuccessResponse(SipServletResponse response) { //... } } 

Each of the SIP method annotations use one or more defined SIP meta annotations, which make the story more extensible. Take a look at the definition of @Invite and @SuccessResponse below.

 @Retention(RUNTIME) @Target({METHOD}) @SipMethod("INVITE") public @interface Invite { } 

As you can see, the

@SipMethod

meta annotation drive the logic.

 @Retention(RUNTIME) @Target({METHOD}) @SipResponseRange(begin = 100, end = 199) public @interface ProvisionalResponse { } 

and here @SipResponseRange meta annotation decide the logic. There are couple more meta annotations defined in the specification. It is possible for application to define their own annotations by using one or more of these meta annotations. The container is expected to behave based on the meta annotations, that appear on annotations put in a method, rather than the annotations itself.

 @Retention(RUNTIME) @Target({METHOD}) @SipResponseRange(begin = 200, end = 299) @SipMethod("INVITE") public @interface MySucessfulInviteResponse { } 

As you can see above, an application has used

@SipMethod

and

@SipResponseRange

for a custom annotation.

 @Retention(RUNTIME) @Target({METHOD}) @SipPredicate(InitialInvite.Predicate.class) @SipMethod("INVITE") public @interface MyInitialInvite { class Predicate implements javax.servlet.sip.Predicate { @Override public boolean apply(final SipServletRequest request) { return request.isInitial(); } } } 

And in the above example, application has used a more powerful

@SipPredicate

to specify a custom filtering logic. Such custom annotations can now be used to annotate a SIP handler method. More information (eg: method selection criteria) on this and also about all other features are available in the early draft. Join the sipservlet-spec java.net project to participate in the process.

binod

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
  2. 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. 
  3. IMConversation: This is a text chat between two user agents. 
  4. IMConference: A text chat between more than two participants, which is brokered by the server.
  5. MSRPConversation. A two-party communication that uses MSRPprotocols, mainly to transfer files and sending messages. 
  6. 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 explainedUserProcedures 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.
  2. Checkout the sample and build using maven 2. 
  3. Start the SIP client of one user (eg: Alice) and Make a call to Bob. [For X-Lite tips, see this blog]
  4. Since Bob's phone is not active, after a while, the call will be rejected by the server.
  5. 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 Servletsprovide 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 andSailFin 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 sinceapplication 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).



CommunicationBean defined in SailFin CAFE act as the listener for any communication events. For example, in case of instant messaging between two SIP clients, a CommunicationBean would intercept all the messages. These messages are available to the CommunicationBean implementation as POJO. That also mean that, you can implement the business logic in the CommunicationBean.

This example demonstrates using google translate APIs to translate the IM between two SIP users. There is a nice and simple java client for the google translate API that I use for this sample. Take a look at this gist showing the CommunicationBean implementation. The translation is based on the language set in in the HTTP Servlet.

    

Complete application and steps to execute are available here. And here is the javadoc of the SailFin CAFE.




  


RFC 3994standardized how SIP applications implement "Indication of Messages" or "Typing detection" at protocol level. SailFin CAFE provides a simple way to detect typing using a Communication Bean. Also a web application can send a "Message Indication" to a SIP client.

Here is the code that implements receiving Instant Messages and Message Indication from a SIP client.

@CommunicationBean
public class SimpleCommsBean {

    @Context CommunicationContext ctx;

    @CommunicationEvent(type=CommunicationEvent.Type.MESSAGEINDICATION)
    void handleMessageIndication() {
        IMConversation conv = (IMConversation) ctx.getCommunication();
        MessageIndication msg = (MessageIndication) ctx.getMessage();
        System.out.println("Message State : " + msg.getState());
        System.out.println("Next Message Type : " + msg.getNextMessageType());
    }

    @CommunicationEvent(type=CommunicationEvent.Type.MESSAGEARRIVED)
    void handleMessage() {
        IMConversation conv = (IMConversation) ctx.getCommunication();
        TextMessage msg = (TextMessage) ctx.getMessage();
        System.out.println("Received Message" + msg.getText());
    }
}

In the code above, the first event gives an indication about the message (eg: whether the user is actively typing, what is the type of next message etc). In the next event, the application receives the actual message. Both these , on a typical SIP Servlet application , would be received as the content of a SIP message and application would need to interpret the content. Message Indication is an xml document, which would otherwise need to be parsed by the SIP Servlet. Here the CAFE framework handles the parsing the message content and provides it as an appropriate POJO to the application.

Similarly, a servlet or JSP would send a Message Indication or Text Message to SIP client by creating an IMConversation. Here is the sample servlet code that send IM message.

   @Context CommunicationSession session;

    @Override
    protected void doGet(HttpServletRequest request,
    HttpServletResponse response) throws ServletException,
    java.io.IOException {
    
        java.io.PrintWriter out = response.getWriter();
        String party1 = request.getParameter("party1");
        String party2 = request.getParameter("party2");
        try {
            out.println("");
            IMConversation conv  = session.createIMConversation(party1);
            conv.addParticipant(party2);
            conv.createMessageIndication().send();
            conv.createTextMessage("Hi There").send();
            out.println("IMConversation started between " + party1 + "and" + party2);
        } catch (Exception e) {
            out.println(e);
        }
For more information take a look at the javadoc for IMConversation, TextMessage and MessageIndication.



  

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 CommunicationSessionobject is available as a session attribute.

Take a look!

So far I have described how create server applications that handle call, conference and IM using SailFin CAFE. In this edition lets take a look at how to add communication capabilities to web applications in a (very) simple way.

I like to start with the code. So, here is some code that implements making a phone call between two parties from the web application.

package my.test;

import javax.servlet.ServletException;
import javax.servlet.http.*;
import org.glassfish.cafe.api.*;

public class CommunicatingServlet extends HttpServlet{

    @Context CommunicationSession session;

    @Override
    protected void doGet(HttpServletRequest request,
    HttpServletResponse response) throws ServletException, java.io.IOException {

        java.io.PrintWriter out = response.getWriter();
        try {
            out.println("");
            String party1 = request.getParameter("party1");
            String party2 = request.getParameter("party2");
            Conversation conv  = session.createConversation(party1);
            conv.addParticipant(party2);
            out.println("Call started between " + party1 + " and " + party2);
        } finally {
            out.println("");
            out.close();
        }
    }

}


 

As you can see in the code above, an instance of CommunicationSession object is injected into the HTTP servlet. The session can then be used to create a conversation object specifying the parties in the call. All the further SIP protocol handling will be done by CAFE framework as per RFC 3725, unless the application wishes to modify any behavior (which I will explain another day).

CommunicationSession can be used to create any communication artifacts like conference, conversation, IMConversation etc as per the need of the application. It also share the session between communication bean and HTTP servlet. For example, for creating a conference between three people, the code would be something like the following.

            Conference conf  = session.createConference();
            conf.addParticipant(party1);
            conf.addParticipant(party2);
            conf.addParticipant(party3);

Similarly, for sending a message, the code would be.

            IMConversation conv  = session.createIMConversation(party1);
            conv.addParticipant(party2);
            conv.createTextMessage("Hi There").send();

To run the application, execute the following steps.


  
binod

SailFin V2 released! Blog

Posted by binod Oct 27, 2009

SailFin V2 (Sun GlassFish Communications Server 2.0) is released today. See Srikanth'sannouncement 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.

In this edition, I am explaining, how to write a simple IM server using SailFin CAFE.

If you have read my earlier blogs on SailFin CAFE (here and here) then there is nothing additional need to be done!. The same applications that supports 2-party calls or Conference application are already capable of handling IM between two users.

package my.test;
@org.glassfish.cafe.api.bean.CommunicationBean
public class YourCommunicationPOJO {
}

That means the above code will support IM also, apart from supporting 2-party calls.

Here are the steps to run this application.

  • Downloadand Install latest SailFin V2 build
  • Download and install latest SailFin CAFE build.
  • Package the application using the normal web application packaging format. Use your favorite IDE to do that. For compilation, please use SAILFIN_HOME/lib/communication-api.jar.
  • Start/Restart SailFin and deploy the application (eg: asadmin deploy firstcafe.war)
  • Now your application is ready to test against any SIP phones. To use X-Lite sip phone, follow the steps below.

  • Setup two X-Lite phones with accounts "alice@example.com" and "bob@example.com" respectively. They will register with SailFin CAFE
  • Send IM messages between alice and bob.

  • https://bloggers.dev.java.net/files/documents/84/144668/cafe-im.png
    In the following weeks, I will cover more features like, integration with web applications, redirecting the call, rejecting call, typing detection etc.

Filter Blog

By date: