From the IBM WebSphere Developer Technical Journal.

Introduction

Internet Protocol (IP) convergence is often used to refer to the moving of all various network types onto IP. Since the data network is predominantly on IP today, this has more to do with how the voice and video networks are moving to IP.

IP telephony and Voice over IP (VoIP) are becoming predominant technologies in enterprises, as well as in the home. Companies such as Avaya, Cisco, Nortel, and Alcatel have had numerous IP telephony offerings for years now. Many of these deployments had initially been in call and contact centers, but now the deployments are becoming more widespread throughout corporations. Meanwhile, IP telephony has weaved its way into homes through phone services like AT&T CallVantage and Vonage, or through the computer interfaces provided by Skype (now a part of Ebay), AOL IM, Google Talk, and many others.

On the video side, the market is at the beginning of moving to IP. IP Television (IPTV) has begun to take off, with big companies like AT&T making offerings to specific cities and Microsoft and Nortel investing a great deal of money in their IPTV infrastructure offerings. Meanwhile, the mobile TV network is also heating up with brands such as ESPN and the NFL beginning to offer mobile service through Sprint PCS.

One main element in the foundation of voice and video convergence on IP is the Session Initiation Protocol (SIP). SIP was designed to help negotiate an interactive communications session between two peers. SIP is the foundation of the next generation telecommunications networks, called the IP Multimedia Subsystem (IMS). Also, many of the IP telephony vendors are now focused on SIP as the control protocol for their IP telephony deployments. With enterprise voice networks quickly moving to IP telephony, there are many possibilities in creating an application that utilizes the converged network to create a high powered application. Other pieces of the infrastructure, such as mobility and collaboration services, are also utilizing SIP heavily now, or will be in the near future. These technologies will further the possibilities for new applications that make workers more productive.

As SIP was modeled after the Hypertext Transfer Protocol (HTTP), many people have been looking at how to combine these technologies for a better user experience. Since HTTP was generally designed as a protocol to transfer graphical information to each user, and since SIP does not have a graphical portion, many have combined the technologies so that the SIP flows use HTTP for its transport to provide a graphical interface. This may include initiating phone calls or instant messaging sessions, monitoring the status of these sessions, or terminating these sessions. Another interesting area of convergence of SIP with HTTP is in the use of Web services. This would include building SIP applications that rely on Web services, or Web services that rely on SIP to drive new innovative function.

IBM WebSphere Application Server added support for the SIP Servlet 1.0 specification, JSR 116, in the 6.1 release. WebSphere Application Server V6.1 also includes support for HTTP servlets, portlets, JSPs, and JSF. With robust support for HTTP or Web-based graphical technologies, many companies develop Web applications to be deployed on WebSphere Application Server. The addition of the SIP servlet specification enables you to easily combine these technologies for rich experiences beyond the Web. One of the primary concepts in the SIP Servlet 1.0 specification is converged applications. The general notion is that one application could contain sessions from multiple protocols and use those protocols to create a rich user experience. Specifically for the current releases, one application may include HTTP and SIP functionality, and the sessions could be intertwined.

Here are some examples of possible converged applications:

1. Initiate a phone call from any displayed phone number. Everywhere a phone number exists on a Web page, a user can click on the phone number and begin a phone call. For applications that display a profile of customers or internal peers, this could enable an easy way to increase productivity by ensuring numbers are not misdialed.

2. Contact someone by phone, instant message, or e-mail. Each e-mail address provides a hot link menu through which a person can be called, instant-messaged, or e-mailed. The call and instant messaging session could be initiated using SIP. Availability of those users online could also be checked using SIP.

3. Proactively monitor a conference call from a Web page. If someone is on a noisy cell phone, or a line has a lot of static, quickly pinpoint that line and enable it to be muted via the Web page.

Examples of converged applications which can increase productivity are boundless. These can be created more simply through the development of common assets, which do things such as enable a telephone call to be made given two addresses. Some assets may need to be customized to the environment. Meanwhile, companies are beginning to create offerings to aid the integration of converged applications.

The application in this article

In this article, we will walk through the development of a converged HTTP and SIP application. The HTTP application will display a Web page that takes the address and port numbers of two SIP User Agent Servers (UAS) and initiate a connection between them. It will also allow the connection to be terminated at any time. This application will be called CallLauncher. For your convenience, this application is also included with this article in a download file.

Setting up the development environment

The Integrated Development Environment (IDE) used for this article is the WebSphere Application Server Toolkit (AST) V6.1, built on the open source Eclipse v3.1.2 technology, which is also the foundation of IBM Rational Application Developer (see Resources).

Prerequisites

This article assumes a basic understanding of protocols over IP, particularly HTTP and SIP, plus a good understanding of the Java™ language. Background knowledge of WebSphere Application Server, the Java Platform, Enterprise Edition (Java EE) and HTTP servlets is helpful to understand all of the concepts included in this document.

This article assumes you have read Part 1: Introducing SIP.

Back to top

Writing a converged application

The steps to create a converged application are detailed below. The high level steps include:

1. Create the SIP project
2. Create the SIP servlet
3. Create the HTTP servlet
4. Write the source code for the HTTP and SIP servlets
5. Deploy the application on the application server
6. Run the application

A. Create the SIP project in AST

1. Start a project under which the source will be developed. To begin, in the Application Server Toolkit (AST), select File => New => Project.

2. In the New Project dialog, you choose the type of project you want to create. Select SIP => Converged Project, then Next (Figure 1).

   
   
   Figure 1. Create a new project
   
   
   

3. Name this new project in the New SIP/HTTP Project dialog (Figure 2). Enter the name of the project in the Project Name field. Here, we call our application CallLauncher. Click Next.

   
   
   Figure 2. Name the converged project
   
   
   

4. The Select Project Facets dialog lets you configure the elements that you want this project to be able to support. For the purpose of our converged application here, we will need the Web options:

   • Dynamic Web Module
   • WebSphere Web (Co-existence)
   • WebSphere Web(Extended)

   plus:

   • Java
   • SIP Module.

   After selecting these facets, click Next.

   
   
   Figure 3. Add Java support
   
   
   

5. On the Web Module dialog, configure these main pieces of information. First, configure the Context Root, which is the base of the URL under which the application server will host the Web Module. In our example, our Context Root is CallLauncher. This means that to call the HTTP servlets that we create, we will have to address the application server and its context root first. For example, it may look like:

   http://application.server.example.com:9080/CallLauncher/MyServlet

   Here, MyServlet is the name of the servlet in this context root, 9080 is the port the application server is listening on, and application.server.example.com is the hostname of the server running the application server. Accept the defaults for the other options on this panel. Click Finished when done to complete the project creation.

   
   
   Figure 4. Configure Web modeule settings
   
   
   

B. Create the SIP servlet

In our example, the CallLauncher sample is used for these tasks:

• It handles the SIP protocol responses from the first user agent server (UAS-1), which was initiated through the HTTP servlet.
• It initiates the request to the second user agent server (UAS-2) after getting a successful response from the first server.

Figure 5 shows the initial call flow for the CallLauncher servlet. Everything above the green line is handled by the HTTP Servlet and everything below the green line is handled by the SIP Servlet. Both servlets are needed to accomplish the objective of this application.

Next, we will create the SIP servlet which will perform the actions above:

6. Select File => New => Other => SIP => SIP Servlet => SIP Servlet, then Next.

   
   
   Figure 6. Create a SIP servlet
   
   
   

7. On the next dialog (Figure 7), you can name the SIP servlet and select the project it is associated with. Select our CallLauncher project and name the Servlet Class name CallLauncherSIP in Java package com.ibm.sip.test. After that, click Next.

   
   
   Figure 7. Specify class file destination
   
   
   

8. If your SIP servlet needed any additional mappings or initialization parameters, they would be added to this dialog shown in Figure 8. We will not have any for this application, so click Next.

   
   
   Figure 8. Enter servlet deployment descriptor-specific information
   
   
   

9. In the next dialog (Figure 9), you can create method stubs for the particular methods you want to implement. For this application, we will implement listen for BYEs (doBye) and any responses (doResponse). Our application does not get any request messages through it, as shown in Figure 5, so these responses are all that are important. Click Finish when complete.

   
   
   Figure 9. Add modifiers, interfaces, and method stubs
   
   
   

10. The servlet is now created at this point.

Before we begin to write the function in the servlets, we will create the HTTP servlet, which is next.

C. Create the HTTP servlet

The HTTP servlet is used to generate a Web page that lets you enter each UAS hostname and port, and simply click to initiate a call between the two. It will also be able to terminate the call. Since HTTP servlets are very common components, this servlet will focus on interacting with SIP and not be a rich Web experience.

11. To create the HTTP select File => New => Other => Web => Servlet and then Next (Figure 10).

    
    
    Figure 10. Create a new servlet
    
    
    

12. On this next window, specify CallLauncherHTTP for the Class name and com.ibm.http.test for the package, then Next (Figure 11).

    
    
    Figure 11. Specify class file destination for new servlet
    
    
    

13. The next panels will be similar to the steps we took when creating the SIP servlet. We did not set any initialization parameters, and selected only to be notified of GET (doGet) requests.

D. Write the source code for the HTTP and SIP servlets

To create the source for these servlets, you may have to open each servlet. You should see the CallLauncher project under Dynamic Web Projects on the left. Under that, there should be a src directory, provided you accepted the defaults in the previous three sections. Each servlet will appear under that src directory. Double clicking on each servlet will put it into edit mode in the main panel (Figure 12).

Write the HTTP servlet

14. The HTTP servlet will be implemented to perform a couple of specific tasks. Figure 13 shows the basic flow of the code that will be created in this servlet. The actual HTML and form will be basic, but they will show the desired interaction with SIP.

    
    
    Figure 13. HTTP servlet basic flow
    
    
    

    We will go through the code that runs with an initial request. Basically, we will create a form with inputs that include the to and from hostnames and ports. The call must be initiated on behalf of one of the users. The form inputs are:

    • toSipAddress
    • toSipPort
    • fromSipAddress
    • fromSipPort.

    resp.setContentType("text/html"); resp.getWriter().print("Call Launcher Sample Application <BR><hr>"); resp.getWriter().print("create new call: <BR>"); resp.getWriter().print("<form>"); resp.getWriter().print("To (host): <input type=\"text\" name=\"toSipAddress\">"); resp.getWriter().print(" Port: <input type=\"text\" name=\"toSipPort\">"); resp.getWriter().print("<br>"); resp.getWriter().print("From (host): <input type=\"text\" name=\"fromSipAddress\">"); resp.getWriter().print(" Port: <input type=\"text\" name=\"fromSipPort\">"); resp.getWriter().print("<input type=\"submit\" value=\"create call\">"); resp.getWriter().print("</form>");

    
    

15. The next major step is to create the function that makes the phone call once the user agent server addresses have been set. We will need to add some code to the servlet to get access to the SipFactory for this application. The javax.servlet.sip.SipFactory interface API provides access to create more requests and sessions from within the application. Declare a variable for the SipFactory and import it. Then, in the servlet initialization, set the SipFactory:

    import javax.servlet.sip.SipFactory; … private SipFactory _sipFactory = null; public void init() throws ServletException { _sipFactory = (SipFactory) getServletContext().getAttribute(SipServlet.SIP_FACTORY); if (_sipFactory == null) { System.out.println("CallLauncherHTTP: Error no SipFactory in context"); } }

    
    

16. With access to the SipFactory, the servlet can now initiate a call. To initiate a call, we will need access to a SipApplicationSession. WebSphere Application Server enables access to the SipApplicationSession from the HttpSession. There are two separate APIs specific to WebSphere Application Server that extend the specification’s APIs to provide access to the SipApplicationSession for converged applications. The first API is from IBMSession, to which the HttpSession inside of WebSphere Application Server can be cast. From the IBMSession, one can get to the IBMApplicationSession, which can be cast to a SipApplicationSession. We add this code to the beginning of the doGet method:

    HttpSession httpSession=req.getSession(); IBMSession extSession = (IBMSession)httpSession; IBMApplicationSession ibmAppSession = extSession.getIBMApplicationSession(); SipApplicationSession appSession = (SipApplicationSession)ibmAppSession ;

    
    

17. The next piece of code we need to add is to fetch the form variables from the form we created above. We can do this through some simple fetching of parameters off the request:

    String toAddressStr = req.getParameter("toSipAddress"); String toPortStr = req.getParameter("toSipPort"); String fromAddressStr = req.getParameter("fromSipAddress"); String fromPortStr = req.getParameter("fromSipPort"); String appSessionId = req.getParameter("appid");

    
    

18. To choose between creating the initial form and initiating a call with servers, we need to check to see if the form variables are set:

    if((toAddressStr!=null) &&( fromAddressStr!=null)){

    
    

    There will be an else code block that will follow this with the initial form code in it.

19. Now that we have the addresses and are prepared to initiate a call, we need to set up the SIP request. Create the SIP URIs that will be included in the To and From fields in the SIP request. Per RFC 3261, ports are not to be included in the To and From fields. The SipURI objects can be created from the SipFactory:

    SipURI to = _sipFactory.createSipURI("user1",toAddressStr); SipURI from = _sipFactory.createSipURI("user2",fromAddressStr);

    
    

20. Since this HttpServlet will only send the first SIP request and the SIP servlet will send the second SIP request, we need to store the From address so it can be accessed later for the second call leg:

    appSession.setAttribute("FROM_ADDRESS", fromAddressStr); appSession.setAttribute("FROM_PORT", fromPortStr);

    
    

21. Next, we can build the SIP INVITE request and send it to the first server. Create the SipServletRequest using the SipFactory and our To and From addresses. Then, create another SipURI to attach the port to before we send the request out. Once the port is set, we can send the invite request:

    SipServletRequest invite = _sipFactory.createRequest(appSession,"INVITE",from,to); SipURI requestUri = _sipFactory.createSipURI("user1",toAddressStr); if (toPortStr != null) requestUri.setPort(Integer.parseInt(toPortStr)); invite.setRequestURI(requestUri); invite.send();

    
    

22. Since this is the result of an HTTP request, we need to push back content to the user indicating status, and include a Terminate button so the call can be terminated:

    resp.getWriter().print("creating a call to: ["+to.toString()+ "] from: ["+from.toString()+"]"); resp.getWriter().print("<form>"); resp.getWriter().print("<input type=\"hidden\" name=\"appid\" value=\""); resp.getWriter().print(appSession.getId()); resp.getWriter().print("\">"); resp.getWriter().print("<input type=\"submit\" value=\"terminate\">"); resp.getWriter().print("</form>");

    
    

23. The next major section of the HTTP servlet is to write the Terminate function, to be executed when the Terminate button is pushed. This simplistic HTTP interaction can assume that if the request parameters are not included in the request, and the SipApplicationSession has been initialized with a session ID, then a call exists. Therefore, we can add a simple else-if statement to check this condition:

    else if((appSessionId!=null) && (!appSessionId.equals(""))){

    
    

24. To terminate the calls, we need to send a BYE to the UAS. To perform this task, pick the first SipSession within the SipApplicationSession and create a BYE for each session that will close the connection. There will be a SipSession created for each UAS, one for the INVITE done by the HTTP servlet, and one for the INVITE that the SIP servlet will perform. Here, we iterate through each session and send a BYE to each UAS:

    for (Iterator iter = appSession.getSessions("SIP"); iter.hasNext();) { SipSession session = (SipSession) iter.next(); session.createRequest("BYE").send(); }

    
    

25. Finally, the status of the termination needs to be displayed back to the user:

    resp.setContentType("text/html"); resp.getWriter().print("Call Launcher Sample Application <BR><hr>"); resp.getWriter().print("terminated call["+appSessionId+"]");

    
    

Write the SIP servlet

26. Access the SIP deployment descriptor (sip.xml) by selecting CallLauncher => SIP Deployment Descriptor => SIP Servlets => CallLauncherSIP. Figure 14 will display.

    
    
    Figure 14. SIP deployment descriptor
    
    
    

27. Be sure to map the SIP servlet to the INVITE method.

28. The SIP servlet has multiple functions (Figures 15 and 16). The first is to connect the second UAS by sending an INVITE request to that UAS once the first request is successful. The doBye in this call flow is to handle the case where one of the user agents initiates the BYE before the terminate button is pressed on the HTTP page.

    
    
    Figure 15. doResponse flow
    
    
    
    
    Figure 16. doBye flow
    
    
    

    We will now work on the flow for connecting the second UAS into the call. Since the INVITE was initiated by the HTTP servlet, the SIP servlet will primarily be responsible for accepting the response from that INVITE request and send the second INVITE. To create requests, we will need access to the SipFactory. We will obtain a reference to the SipFactory much like we did with the HTTP servlet:

    private SipFactory _sipFactory; public void init() throws ServletException { _sipFactory = (SipFactory) getServletContext().getAttribute(SIP_FACTORY); if (_sipFactory == null) { throw new ServletException("No SipFactory in context"); } }

    
    

29. Once we have the SipFactory, we can begin to write the INVITE logic within the doResponse() method. To tell which piece of the flow we are on, we are going to link the requests for each session together. To check to see if this is a response to the INVITE we need to check the request that caused this response:

    SipServletRequest req = resp.getRequest();

    
    

30. Linking the requests together will be a way for us to tell whether one or two requests were sent. Check for the second request as an attribute we will call peer.req. The code to save the peer.req is:

    SipServletRequest req2 = (SipServletRequest) req.getAttribute("peer.req");

    
    

31. As the flowchart in Figure 15 points out, the next step is to check if this is a response to the INVITE. Immediately after that, we need to see if it is a response to the first INVITE sent by the HTTP servlet or the second INVITE sent by the SIP servlet. We will use req2 to tell the difference between responses:

    if (resp.getMethod().equalsIgnoreCase("INVITE")){ if (req2 == null) { if (resp.getStatus() == 200) {

    
    

32. Since this is a contained example, we will not check the responses from the UAS. Normally, we would use this point to see whether or not the response from the first UAS was successful. Instead, we will immediately begin to set up the second call leg. We will reverse the To and From in the creation of the INVITE request, so the first step will be to fetch the To and From address from the first request:

    SipURI to = (SipURI) req.getTo().getURI(); SipURI from = (SipURI) req.getFrom().getURI();

    
    

33. Next, we will get the SipApplicationSession and create the INVITE request. Notice that we flipped the To and From addresses, compared to the similar call in the HTTP servlet:

    SipApplicationSession appSession = resp.getSession().getApplicationSession(); SipServletRequest invite = _sipFactory.createRequest( resp.getApplicationSession(), "INVITE", to, from);

    
    

34. To connect correctly and send this to the second UAS, we will need the address and port. We stored that address in the SipApplicationSession in the HTTP servlet. Here, we will fetch those attributes:

    StringfromAddress = (String)appSession.getAttribute("FROM_ADDRESS"); StringfromPort = (String)appSession.getAttribute("FROM_PORT");

    
    

35. We are now ready to set up the rest of the request to the second UAS. Create the request URI and set the port; we set that on the INVITE request but will not send it quite yet. Since SIP servlets are asynchronous, we need to make the sending of this request the last thing we do in this servlet; otherwise, we will need to worry about synchronization:

    SipURI requestUri = _sipFactory.createSipURI("user2",fromAddress); if (fromPort != null) requestUri.setPort(Integer.parseInt(fromPort)); invite.setRequestURI(requestUri);

    
    

36. We are ready to set up the request with the session content description that we have received. Typically, this sort of description will be in the Session Description Protocol (SDP) format:

    copyContent(resp, invite);

    
    

37. The copyContent method is created to simply copy this session description from one SIP message to another:

    void copyContent(SipServletMessage msg1, SipServletMessage msg2) { try { if (msg1.getContentType() != null) { msg2.setContent(msg1.getRawContent(), msg1.getContentType()); } } catch (IOException ex) { log("Error: " + ex); } }

    
    

38. To link the requests together, we will set the sessions and requests in each other’s session; this is for convenience and not actually required, since the sessions are available in the same SipApplicationSession:

    invite.setAttribute("peer.req", req); invite.setAttribute("peer.resp", resp); SipSession dialog = resp.getSession(); SipSession dialog2 = invite.getSession(); dialog.setAttribute("peer", dialog2); dialog2.setAttribute("peer", dialog);

    
    

39. Send the invite to the second UAS:

    invite.send();

    
    

40. Returning to the flowchart in Figure 15, we need to handle the case where the response is from the second UAS INVITE and not the first. Start by adding an else statement at the scope of the if that interrogated the request to see if the requests were linked through our peer.req linking scheme. If we received the response from the second UAS, we need to send an ACK to the first UAS. Specifically, the flow will look like Figure 17. The ACK is the last thing before the session begins.

    
    
    Figure 17. SIP Flows with the ACK
    
    
    

41. For this particular code, we will send the ACK to the second UAS and then to the first UAS. When sending the ACK to the first UAS, it is important to send the session description back to the first UAS:

    else { SipServletRequest ack = resp.createAck(); ack.send(); SipServletResponse peerResp = (SipServletResponse) resp.getRequest().getAttribute( "peer.resp"); SipServletRequest ack2 = peerResp.createAck(); copyContent(resp, ack2); ack2.send(); }

    
    

42. Looking at Figure 15, we will begin to work on the flows past the INVITE, and to the response of the BYE. Specifically, Figure 18 shows the BYE flow handled by the CallLauncher.

    
    
    Figure 18. Full flow of messages for this scenario
    
    
    

    For the BYE response, we need to accept the BYE response, create a response with the same status code, and send it to the peer UAS:

    else if (resp.getMethod().equalsIgnoreCase("BYE")){ int sc = resp.getStatus(); if (req2 != null) { SipServletResponse resp2 = req2.createResponse(sc); resp2.send(); } else log("CallLauncherSIP: doBye: error: peer req = null"); }

    
    

43. The last piece of the SIP Servlet that needs implemented is the doBye method. Because the two UASs can initiate a BYE without the Terminate button being hit on the Web page, we need to forward on the BYE appropriately. In this scenario, the BYE flow would look like this one described in Figure 19.

    
    
    Figure 19. Flow with a UAS initiated BYE instead of a HTTP initiated BYE
    
    
    

    When receiving a BYE from a UAS, we need to first fetch the peer session to send a BYE on it. We stored that peer session earlier in the attributes of the request. Here, we fetch the peer session:

    protected void doBye(SipServletRequest bye1) throws ServletException, IOException { SipSession dialog1 = bye1.getSession(); SipSession dialog2 = (SipSession) dialog1.getAttribute("peer"); if (dialog2 == null) { throw new ServletException("no peer SipSession; cannot forward BYE"); }

    
    

44. Once we fetch the peer session, we create a SIP BYE request on the peer session to send it to the peer UAS. We will need to copy any session description included in the BYE to terminate the session:

    SipServletRequest bye2 = dialog2.createRequest("BYE"); bye2.setAttribute("peer.req", bye1); copyContent(bye1, bye2); bye2.send();

    
    

That is all we need to do for this simple SIP servlet. We are now ready to test out the code.

E. Deploy the application on the application server

45. There are two ways to test the application. Here, to get a package you can deploy on the application server, you need to export the Servlet Archive (SAR) file from the Application Server Toolkit. Select File => Export.

46. From the Export dialog (Figure 20), select the SAR file and click Next.

    
    
    Figure 20. Export SIP project
    
    
    

47. From the next dialog (Figure 21), select the CallLauncher project as the one to export, then select the directory into which you would like to export the SAR. After this, click Finish.

    
    
    Figure 21. Export SIP project
    
    
    

48. With the application exported, go to the application server administrative console (Figure 22). In the left column, go to Applications => Install New Application.

49. Select the appropriate SAR from the Local file system, specify /CallLauncher as the Context root for this application, then Next. For this simple application, all of the defaults are sufficient.

    
    
    Figure 22. Administrative console
    
    
    

50. The application is now deployed. Using the Applications => Enterprise Applications option on the left, you can start and stop the CallLauncher application as you would any other WebSphere application.

F. Run the application

Once you have deployed the application, you will need to start up two UAS applications. For our test, we used the UAS provided in the free open source tool, SIPp. The details of our SIPp configuration appears in Appendix A.

51. Assuming the context root was specified during the installation of the application, you can access this application on the Web by entering this URL in a browser: http://<server>:<port>/CallLauncher/CallLauncherHTTP, where <server> is your hostname, <port> is the port of the Web container (defaults to 9080 with WebSphere Application Server), and the rest is your context root and servlet name. A simple HTTP page with a form should display, similar to Figure 23.

    
    
    Figure 23. Sample application
    
    
    

52. On the initial Web page, enter the addresses and ports of the two UAS applications and then press create call. A page will display indicating that the call is being created (Figure 24).

    
    
    Figure 24. Sample application result page
    
    
    
53. From this results page, you can terminate the call by pressing terminate.

Back to top

Conclusion

With technologies such as instant messaging, Internet Protocol (IP) telephony, and video over IP becoming more and more popular, a new wave of applications will be created that combine multiple technologies over IP. Creating these converged applications are easy with WebSphere Application Server’s tooling. WebSphere Application Server provides a simple programming model for utilizing the Session Initiation Protocol (SIP) and Hypertext Transfer Protocol (HTTP) seamlessly within one application.

Back to top

More in this series

• Part 1: Introducing SIP

Back to top

Appendix: SIPp UAS configuration

SIPp is a free open source tool for SIP. It’s a sample UAS against which you can test the CallLauncher application. The configuration we used for this sample application is below. You can access SIPp documentation and download the tool directly from the SIPp Web page .

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<!-- This program is free software; you can redistribute it and/or      -->
<!-- modify it under the terms of the GNU General Public License as     -->
<!-- published by the Free Software Foundation; either version 2 of the -->
<!-- License, or (at your option) any later version.                    -->
<!--                                                                    -->
<!-- This program is distributed in the hope that it will be useful,    -->
<!-- but WITHOUT ANY WARRANTY; without even the implied warranty of     -->
<!-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the      -->
<!-- GNU General Public License for more details.                       -->
<!--                                                                    -->
<!-- You should have received a copy of the GNU General Public License  -->
<!-- along with this program; if not, write to the                      -->
<!-- Free Software Foundation, Inc.,                                    -->
<!-- 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA             -->
<!--                                                                    -->
<!--                 Sipp default 'uas' scenario.                       -->
<!--                                                                    -->
<scenario name="Basic UAS responder">
  <!-- By adding rrs="true" (Record Route Sets), the route sets         -->
  <!-- are saved and used for following messages sent. Useful to test   -->
  <!-- against stateful SIP proxies/B2BUAs.                             -->
  <recv request="INVITE" crlf="true">
  </recv>
  <!-- The '[last_*]' keyword is replaced automatically by the          -->
  <!-- specified header if it was present in the last message received  -->
  <!-- (except if it was a retransmission). If the header was not       -->
  <!-- present or if no message has been received, the '[last_*]'       -->
  <!-- keyword is discarded, and all bytes until the end of the line    -->
  <!-- are also discarded.                                              -->
  <!--                                                                  -->
  <!-- If the specified header was present several times in the         -->
  <!-- message, all occurences are concatenated (CRLF seperated)        -->
  <!-- to be used in place of the '[last_*]' keyword.                   -->
  <!--send>
    <![CDATA[
      SIP/2.0 180 Ringing
      [last_Via:]
      [last_From:]
      [last_To:];tag=[call_number]
      [last_Call-ID:]
      [last_CSeq:]
      Contact: <sip:[local_ip]:[local_port];transport=[transport]>
      Content-Length: 0
    ]]>
  </send-->
<pause milliseconds = "500"/>
  <send>
    <![CDATA[
      SIP/2.0 200 OK
      [last_Via:]
      [last_From:]
      [last_To:];tag=[call_number]
      [last_Call-ID:]
      [last_CSeq:]
      Contact: <sip:[local_ip]:[local_port];transport=[transport]>
      Content-Type: application/sdp
      Content-Length: [len]
      v=0
      o=user1 53655765 2353687637 IN IP4 127.0.0.1
      s=-
      t=0 0
      c=IN IP4 [media_ip]
      m=audio [media_port] RTP/AVP 0
      a=rtpmap:0 PCMU/8000
    ]]>
  </send>
  <recv request="ACK"
        optional="true"
        rtd="true"
        crlf="true">
  </recv>
  <recv request="BYE">
  </recv>
  <send>
    <![CDATA[
      SIP/2.0 200 OK
      [last_Via:]
      [last_From:]
      [last_To:];tag=[call_number]
      [last_Call-ID:]
      [last_CSeq:]
      Contact: <sip:[local_ip]:[local_port];transport=[transport]>
      Content-Length: 0
    ]]>
  </send>
  <!-- Keep the call open for a while in case the 200 is lost to be     -->
  <!-- able to retransmit it if we receive the BYE again.               -->
  <!-- pause milliseconds="1000"/ -->
  <!-- definition of the response time repartition table (unit is ms)   -->
  <ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
  <!-- definition of the call length repartition table (unit is ms)     -->
  <CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
			

Back to top

Download

Information about download methods

Resources

Learn

• WebSphere Application Server V6.1: What's new in Version 6.1?
  
  
• WebSphere Application Server Information Center
  
  
• WebSphere Application Server system prerequisites
  
  

Get products and technologies

• Get WebSphere Application Server V6.1 trial download
  
  
• Get Rational Application Developer V6.0 trial download
  
  
• SIPp open source test tool
  
  

About the authors

Erik Burckart is a lead architect of the WebSphere Application Server product. He is a graduate from the University of Pittsburgh'’s School of Information Science, where he studied telecommunications, software development, and human computer interaction. Through his work with SIP servlets in WebSphere Application Server, he has joined the SIP Servlet 1.1 (JSR 289) Expert Group and has made numerous contributions in combining the state of the art Java EE platform with the latest SIP Servlet specification.

Brian Pulito is a development lead on the SIP Proxy team and has worked on SIP technology within IBM for many years. He is a graduate of Vanderbilt University where he studied electrical engineering and physics. He also obtained a Masters degree in electrical engineering from the University of Kentucky. Please send any feedback to Brian at brian_pulito@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Writing a converged application
• Conclusion
• More in this series
• Appendix: SIPp UAS configuration
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers