Testing SIP applications by using the IBM Rational Performance Tester Extension for SIP

Document options PDF - Fits A4 and Letter 586KB (25 pages) Get Adobe® Reader® Document options requiring JavaScript are not displayed New site feature Check out our new article design and features. Tell us what you think. Rate this page Help us improve this content

Level: Intermediate

Vijay Bhadriraju (vbhadrir@us.ibm.com), Senior Software Engineer, WAS SIP Technical Enablement, IBM Research Triangle Park Lab, North Carolina, IBM　

10 Jun 2008

This article explains the complete procedure of testing Session Initiation Protocol (SIP) applications by using the IBM® Rational® Performance Tester Extension for SIP, Version 7.0.1. It illustrates testing a SIP application deployed in the SIP container of a remote WebSphere Application Server Network Deployment Version 6.1. The article is geared toward functional testing rather than performance testing of SIP applications, and it is intended for developers and testers of SIP applications.

The SIP container is a component of WebSphere Application Server V6.1 that manages the complete life cycle of SIP applications. The container is a converged container that can host converged applications. Converged applications contain both SIP and HTTP artifacts. A SIP application is a Java program that uses at least one SIP servlet written to the JSR 116 specification. A SIP servlet is a Java based application that performs SIP signaling compliant to the JSR 116 SIP servlet specification. The SIP servlet specification is developed by the Java Community Process.

Prerequisites

You should have a good understanding of the SIP protocol and the various SIP messages (request and response codes) and the status codes of these messages to use the Rational Performance Tester for SIP tool. The SIP RFC 3261 provides a complete description of the various SIP headers, message elements, and the status codes available.

What you will learn

Rational Performance Tester is a performance test tool for automating the load and scalability testing of server based applications. The Rational Performance Tester for SIP is an extension to Rational Performance Tester that enables the testing of SIP applications. Rational Performance Tester for SIP provides tools to test SIP applications for functional correctness and run performance tests by emulating multiple users.

This article illustrates the use of the Rational Performance Tester for SIP tool for functional testing of SIP applications. It explains the complete process involved in testing SIP applications using the Call Forwarding SIP sample included in IBM WebSphere Application Server Toolkit Version 6.1.1. The complete process covers these steps:

1. Set up the SIP network.
2. Test by using Rational Performance Tester.
3. View and interpret test results in Rational Performance Tester.

Explanation of the Call Forwarding sample used in this exercise

The Call Forwarding sample is a converged application that is provided as a SIP sample in the samples gallery of IBM WebSphere Application Server Toolkit Version 6.1.1. A converged application includes definitions of both HTTP and SIP artifacts.

The Call Forwarding sample has both HTTP and SIP servlets, which is what makes it a converged application. In these exercises, you will use this sample as the SIP application to test. The HTTP servlet in the sample provides a user interface (UI), shown in Figure 1, to configure the forwarded call address mapping. In the UI, a new mapping is created by entering the Public SIP address and the Forwarding SIP address and then clicking Submit. The Clear button is used to clear any existing mapping. For the exercises in this article, you will use the mapping shown under existing mappings in the Figure 1.

Call Forwarding sample functionality

The Call Forwarding sample demonstrates the call forwarding feature typically seen in public switched telephone networks, but it uses a SIP network. When a SIP call is placed to a SIP URI, the call is forwarded to another SIP URI, based on the mapping defined by the sample, by using the UI shown in Figure 1.

Figure 2 depicts the SIP call flow between two user agents (UAs): UA1 and UA2. Using the mapping defined in Figure 1, UA1 corresponds to alice@9.42.136.135 and UA2 corresponds to alice@9.42.136.126.

Set up the physical test environment

The physical test environment shown in Figure 3 has been used to test the Call Forwarding sample. This section explains the steps involved to set up this environment.

Set up User Agent 1

For purposes of this article, UA1 is a Microsoft Windows machine with Rational Performance Tester for SIP installed, along with its Agent Controller. The Agent Controller in Rational Performance Tester is a daemon process that enables client applications to launch host processes and interact with agents that coexist within host processes. Rational Performance Tester listens to SIP messages on default port 5555, which is an arbitrary number chosen for this software. This port number can be changed by Preferences:

1. Select Window > Preferences.
2. In the Preferences view, expand Test, and select SIP Test Playback. You can change the SIP UDP listening port there to a value other than 5555.

Set up WebSphere Application Server V6.1 Network Deployment version

The WebSphere Application Server v6.1 Network Deployment version is installed on a remote RedHat Linux Enterprise Edition Version 4.0 server (hereafter called just Linux) by using the "Application Server" profile, which gives one application server instance. Installation instructions of WebSphere Application Server are not covered in this article, but you can find them in the WebSphere Application Server Installation Guide (see Resources). You can also find instructions there for installing the latest Fix Packs. For this article, we updated the software by using the WebSphere Application Server 6.1.0.9 Fix Pak.

The Call Forwarding Sample included in the Samples Gallery of the toolkit is loaded into the WebSphere Application Server Toolkit workspace and exported as a SIP archive file (SAR file). See the SIP Tools Developer Guide in the WebSphere Application Server Toolkit

Tip:
Because it is a converged application, the Call Forwarding sample in the WebSphere Applicaition Server Toolkit can be exported as WEB archive (WAR) file or as a SAR file.

The SAR file is deployed to WebSphere Application Server through the WebSphere Application Server Integrated Solutions console. The steps to deploy the Call Forwarding SAR file to WebSphere Application Server include:

1. From any machine launch the console by using this URL: http://hostname:9060/ibm/console
2. Log into the console by entering your User ID and Password if security is enabled on your WebSphere Application Server.
3. On the Welcome page, expand Application and then select Install New Application.
4. In the right pane:
   • If the SAR file is on the local file system, click Browse ,
   • If the SAR file is on a remote system, select Remote File System before clicking Browse.
5. Select the Call Forwarding SAR file from the file system that was exported from the toolkit.
6. Because the Call Forwarding sample is a converged application, a context root is required for deploying it. Enter the string CallForwardingSample in the Context root field.
7. Accept all defaults, and click Next.
8. Accept all defaults at the next option, and click Next.
9. Accept all defaults again, and click Next.
10. Click Finish.
11. Click Save link on the last panel that shows the results of deploying the Call Forwarding sample. This is an important step that saves the master configuration in WebSphere Application Server.
12. Click Enterprise Applications in the left navigation view, and make sure that the CallForwardingSample.sar file is listed, with the application status of Stopped.
13. Select the check box in the Select column for the CallForwardingSample.sar file, and click Start to start the application.

The Application Status should change to started, which is indicated only by a green arrow pointing to the right, as Figure 4 shows. This screen capture also shows the deployed CallForwardingSample application in the Name column, toward the left.

These steps complete the deployment of the Call Forwarding sample on a remote WebSphere Application Server , and the application is ready for testing.

Set up User Agent 2

UA2 is a Linux v4.0 box configured to act as a listening agent to the SIP calls forwarded by WebSphere Application Server, based on the mapping defined in the call forwarding application UI as described in Figure 3. The Agent Controller program in Rational Performance Tester for SIP provides the functionality to act as a listening agent. The Agent Controller is installed on the Linux box. To install the Agent Controller:

1. Install the Installation Manager software included with Rational Performance Tester on the Linux box.
2. Install the Agent Controller by using the Installation Manager.

The Rational Performance Tester for SIP installation CD includes both of these programs. The Installation Manager must be installed first, so that you can use it to install the Agent Controller. After installing the Agent Controller on Linux, you need to launch the program for it to act as a listening agent. To start it, use the ./RASStart.sh command, which is located in this folder on Linux:
/opt/IBM/SDP70Shared/AgentController/bin

This completes the setup of UA2.

Test the sample

Testing the Call Forwarding sample on a remote WebSphere Application Server machine using Rational Performance Tester for SIP extension involves creation of the following artifacts in Rational Performance Tester.

1. Create a Performance Test Project.
2. Create a SIP test.
3. Configure the SIP test.
4. Create a counterpart test for SIP test created in Step 2.
5. Configure the counterpart test.
6. Create a Performance Schedule.
7. Run the Performance Schedule.

Create a performance test project

Follow these steps to create a Performance Test Project:

1. From the File main menu, select New > Performance Test Project to launch the project creation wizard.
2. In the wizard, enter the project name as SampleTests, and click Finish.
3. In the Create New Test from Recording wizard, click Cancel.

Figure 5 shows the Sample Tests performance test project created, which displays in the Test Navigator view after you complete those steps. The creation and configuration of various SIP test artifacts shown under the SampleTests project are explained in sections that follow.

To create the SIP test suite:

4. From the File menu, select New > Other.
5. In the New SIP Test wizard, expand SIP Test, select SIP Test, and click Next.
6. In the the Name field, enter CallForwarding as the test name and click Finish.

After the SIP test is created, the Performance Test editor opens on the CallForwarding test, as shown in Figure 6.

Configure the SIP test

Next, you create the SIP messages for testing the Call Forwarding SIP application deployed on the WebSphere Application Server. The UA1 machine that has Rational Performance Tester installed initiates the SIP call. The SIP messages are built according to the call flow for that Call Forwarding application (see Figure 2).

Follow these steps to create the SIP messages that originate from UA1:

1. In the Performance Test editor, select CallForwarding.
2. Click Add button to launch the pop-up menu, and select Send Request.
3. In the New SIP request - Send wizard, leave the default settings.
4. Where the Select request method is INVITE, select the Default Dialog and click Finish.

The Invite request that you just created shows an error. To correct this error, you must set the Request URI in the URI field of the Send Request test element:

5. Select the Send Request test element, and enter alice@9.42.136.135:5060 in the URI text field.
6. Save the editor by clicking the diskette icon. This removes the error on the Send Request test element.

The To and From message headers need to be configured for the Send Request SIP message. The To header field specifies the "logical" recipient of the request and the From header indicates the initiator of the request.

7. In the Message Headers table, select the To header and click Modify. This puts the To header in edit mode.
8. In the URI field, enter alice@example.com and, for the Display name, enter alice.
9. Click Next to edit the From header, which is next SIP header in the INVITE request.
10. In the URI field, enter vijayb@ibm.com and, for the Display name, enter vijayb.

The Send request that you just created needs to be configured to send the request to the WebSphere Application Server server where Call Forwarding application is deployed. As described previously, the WebSphere Application Server is running on a Linux server with this IP address: 9.42.136.135. The SIP container in the WebSphere Application Server is listening on the default SIP port: 5060. The WebSphere Application Server server responds to the Send request from UA1, and the SIP test needs to cater for responses from the server. The next four steps cater to WebSphere Application Server responses:

11. Select Send Request, click Add, and select Receive Response.
12. In the New Receive Response wizard, select 100 Trying, which is the expected response based on the call flow.
13. The 1xx response in SIP are provisional responses. Therefore, make this response provisional by selecting the Optional check box under Test Element Details.

The tool provides a verification feature to verify the response codes received by Rational Performance Tester for Send requests sent. This feature can verify the response codes and the content associated with responses. In this scenario, you use the verification feature to verify response codes from WebSphere Application Server.

14. Select the Receive Response message, click the Add, and select Response Code Verification Point. The pane on the right in the editor changes to show the response code verification test element details.
15. Check Enable Verification Point.

The Exact Expected Code value is the response code that will be verified in the response. It can be unchecked to add lower and upper boundaries for the expected response code that provide a range value for the response code verification. Response Code Verification Points can be added to all responses. For this test scenario, they are added only for the 100 Trying response code.

16. Select the Send request, click Add, and select Receive Response.
17. In the New Receive Response wizard, select 180 Ringing, which is the response expected after 100 Trying.
18. Select the Send request, click Add, and select Receive Response again.
19. In the New Receive Response wizard, select 200 OK, which is the response expected after 180 Ringing.

(Optional) Complete the SIP dialog

The steps that follow are optional but are explained to demonstrate a complete SIP dialog. UA1 acknowledges the 200 OK response by sending an ACK request to UA2, where the call was forwarded. An ACK SIP message confirms that the call between UA1 and UA2 is established. The ACK request is sent directly to UA2 and does not go through the WebSphere Application Server SIP container, thus the URI for the ACK request points to the UA2 IP address, which is 9.42.136.126.

1. Select CallForwarding Test, click Add, and select Send Request.
2. In the New SIP Request dialog, select ACK for the Select request method and Default Dialog and then click Finish.

The ACK request needs to be configured just like the INVITE request created previously.

3. Select the Send ACK test element and enter alice@9.42.136.126:5555 in the URI text field.
4. Save the editor by clicking the diskette icon. This removes the error on the ACK Send Request test element.
5. In the Message Headers table, select the To header and click Modify. This puts the To header in edit mode.
6. In URI field, enter alice@9.42.136.126:5555 and, for the Display name, enter alice.
7. Click Next to edit the From header, which is next SIP header in the ACK request.
8. In URI field, enter vijayb@ibm.com and, for the Display name, enter vijayb.

The SIP call between UA 1 and UA 2 is ended by a BYE SIP message sent from UA 1 to UA2.

9. Select CallForwarding test, click Add, and select Send Request.
10. In the New SIP Request dialog, select BYE for the Select request method and Default Dialog and then click Finish.

The BYE request needs to be configured just like the INVITE request, previously.

11. Select the Send BYE test element and enter alice@9.42.136.126:5555 in the URI text field.
12. Save the editor to remove the error on Send Request test element.
13. In the Message Headers table, select the To header and click Modify to put the To header in edit mode.
14. In URI field, enter alice@9.42.136.126:5555 and, for the Display name, enter alice.
15. Click Next to edit the From header, which is next SIP header in the BYE request.
16. In URI field, enter vijayb@ibm.com and, for the Display name, enter vijayb.

UA2 responds to the BYE sent by UA1 by a 200 OK, which needs to be added to UA1 to receive a response from UA2.

17. Select the Call Forwarding test, click Add, and select Receive Response.
18. In the New Receive Response wizard, select 200 OK, which is the expected response.

Create a SIP counterpart test for your SIP tests

The counterpart test in Rational Performance Tester for SIP represents the SIP message flow for the SIP end point that responds to the SIP messages from the originator. In this scenario, UA2 represents the SIP end point, as depicted in the call flow in Figure 2. Rational Performance Tester provides a convenient way of creating the SIP test messages that originate from UA2 by using the Create counterpart SIP test action that is available for a SIP test.

Follow these steps to create the counterpart test for the CallForwarding test:

1. Right-click the CallForwarding test and select Create counterpart SIP test from the drop-down menu.
2. For the counterpart test suite name, leave the prepopulated name, CallForwarding_counterpart and click OK.
3. In the Test Navigator, double-click the CallForwarding_counterpart test suite to launch the performance test editor for the counterpart test.

Figure 7 shows the test editor for the CallForwarding_counterpart test suite

In the counterpart test editor, you can see that all of the SIP responses and requests for the request and responses of UA1 are automatically created for you. The Create counterpart SIP test action creates all of the SIP messages for the counterpart test, based on the UA1 SIP test messages. You need to configure only the URI for the counterpart test and add any verification points that are necessary.

Configure the counterpart tests

Configure the URI, To URI, and From URI of the SIP responses and requests from the counterpart tests with UA2 as the originator and UA1 as the terminating SIP agent:.

1. For the Receive INVITE, ACK, and BYE responses, set the request URI to alice@9.42.136.126:5555.

Create a Performance Schedule

The Performance Schedule artifact in Rational Performance Tester is used to configure the following elements of SIP tests.

• The test suites executed
• The sequence for running the test suites
• Whether multiple users are to run the tests simultaneously (limited to 5 virtual users currently, but you can purchase a license to be able to run more virtual users)
• Which machines in the domain will run each test suite

Figure 8 shows the Performance Schedule created for testing the Call Forwarding sample.

Complete these steps to create a new performance schedule:

1. Right-click the Sample Tests project and, from the drop-down menu, select New > Performance Schedule.
2. In the Performance Schedule wizard, in the Name field, enter CallForwarding_PerformanceSchedule and then click Finish. This opens the Performance Schedule editor.
3. In the Schedule Contents, right-click User Group 1 and, from the drop-down menu, select Add > Test.
4. In the Select Performance Tests dialog, select the CallForwarding test.

Specify that users in User Group 1 are to run CallForwarding test. By default, the number of users is set to 1, which is what you will use for testing the CallForwarding test.

5. Right-click CallForwarding_PerformanceSchedule and, from the drop-down menu, select Add > UserGroup. This action creates UserGroup 2.
6. Right-click User Group 2 and, from the drop-down menu, select Add > Test,
7. In the Select Performance Tests dialog, select CallForwarding_conterpart test.

Now you need to specify that users in User Group 2 will run the CallForwarding_counterpart test. You will use the default of one user for testing CallForwarding_counterpart test. Consistent with the physical test environment depicted in Figure 3, the CallForwarding_counterpart needs to run on the UA2 machine, which has an IP address of 9.42.136.126.

Tip:
The CallForwarding and CallForwarding_conterpart SIP test suites are available globally to the Rational Performance Tester workspace. Therefore, they can be added to any Performance Schedule in the workspace.

8. Under Schedule Element Details for User Group 2, select Run this group on the following locations.
9. Click Add New to launch the Add Location dialog. In this dialog, enter the following values and then click OK:
   • Hostname: 9.42.136.126
   • Name: Alice's forwarded call PC
   • Deployment directory: /tmp
   • Operating System: Linux

This creates an entry in the hosts table. For each remote machine configured for the SIP test in this way, an entry shows in the Test Project, Figure 5 shows for "Alice's forwarded call PC."

Run the Performance Schedule

1. To run the performance schedule, right-click CallForwarding_PerformanceSchedule.
2. From the drop-down menu, select Run As > Performance Schedule.

This action launches and runs the schedule and then launches the non-editable SIP Performance Report for these tests. Figure 9 shows the Overall tab of the report. The next section explains the details of the tests results and their interpretation.

Review and interpret the test results

For each run of the Performance Schedule, an entry gets added in the performance project with the timestamp for when schedule ran, as shown in Figure 5. The Performance Tests Run view, which is located at the lower-left corner in Rational Performance Tester, displays the results of each test and the details of performance results for each host machine involved in the test. The SIP Performance Report, shown previously in Figure 9, has several tabs that display results for the SIP tests.

SIP Performance Report

For this scenario, we are interested in the functional test verification of the Call Forwarding sample. The performance report has six tabs. The tabs of interest here are the Overall and Summary tabs:

• Overall tab. Provides results as vertical bars. The bar on left depicts the percentage of requests that were run verses that were successful on all machines in the SIP network domain under test. The bar on the right displays the percentage of total number of verification points that were registered in the tests and that have passed.
• Summary tab. This tab has three sections and provides the following information about the test results:
  • Summary. The number of users that executed the test, time elapsed for the total test and the final result of the test.
  • SIP Interactions Summary. The total number of SIP requests sent received by all machines and succeeded in the test domain. It also shows the total verification passed in the test.
  • Response Times Summary. The average, maximum and minimum response times for all the hosts in the domain and the first response time for all hosts in the domain.

Test Log

The Test Log in Rational Performance Tester is a useful non-editable editor where you can view the functional test results of the test. To launch the Test Log:

1. Right-click the Performance Schedule test run from the Test Navigator view.
2. Select Display Test Log.

The Test Log editor has two tabs, Overview and Events, as shown in Figures 10 and 11. The tabs show these test details:

• Overview. This tab contains four sections that convey various information about the test results:
  • General Information. Shows the name and descriptions supplied by the user to this Performance Schedule.
  • Common Properties. Shows the final verdict of the test runs, which is pass in this case. The start and stop time of the test. The type of test performed which is a performance schedule in this case and the host where the test was run which is localhost in our scenario.
  • Verdict Summary. Shows a pie chart with the percentages of the test results that passed and failed. It is a 100% pass in this test scenario. Pass percentages are shown in green and errors are shown in yellow.
  • Verdict List. This list shows a breakup of the all the individual verdicts per SIP test, per user group, per verification point that put together to make up the overall verdict. Each verdict in this list is a link which when clicked highlights the same verdict in the Events tab.

• Events. This tab shows the complete expanded view of the Performance Schedule for the SIP tests executed. The expanded view shows the various artifacts of the schedule as a tree view on the left, with detailed information related to each selected event on the right. For a SIP test, the SIP call flow in this tab is a very important and pertinent piece of information. There are four sections in this tab that either show or are hidden, based on the element type selected in the Events list. The Events and Properties sections are the ones that are important for a SIP test. They provide this information:
  • Events. This section shows the expanded view of the Performance Schedule. This view contains the user groups and the SIP tests executed by each group. Under each SIP test, the complete SIP call flow (SIP requests and responses) for the SIP test and the verdict for that test are shown. The results on any verification points set in the tests are also shown.
  • Properties. This section changes dynamically, based on the selection made in the Events list. Figure 11 shows a screen capture with a SIP INVITE request selected in the Events tree view.
    • The Severity field shows the severity of any problem found during the test (error, warning, or information). For this test, it shows only information, because there were no problems encountered.
    • The Time field shows the when the test was executed.
    • The Text field shows the details of the SIP Header and SIP Message elements for the SIP INVITE request that was sent by UA1. You can find the explanation of each SIP Header or Message element on the SourceForge Web site.

Figure 11 shows the information provided by this tab for the Call Forwarding test.

You now know how to use the IBM Rational Performance Test for SIP extension to test SIP applications over a SIP network.

Share this article Digg this story Post to del.icio.us Slashdot it!

Resources

• Read the SIP Tools Developer Guide section of the WebSphere Application Server Toolkit for additional useful information.
  
  
• Read Introduction to the SIP Modeling Toolkit for IBM Rational Software Architect, an article that discusses the SIP Modeling Toolkit, a set of domain extensions to the Rational Software Architect platform. The toolkit provides the tooling necessary for you to leverage the Rational Software Architect platform in a natural way to design and develop the domain-specific technology for the Session Initiation Protocol (SIP).
  
  
• Check out the SIP Modeling Toolkit. This toolkit adds Session Initiation Protocol (SIP) extensions to the base modeling and development platform provided by IBM® Rational® Software Architect. It makes it easier to use model driven development for the creation of applications using the SIP protocol and (JSR-116) SIP servlets, allowing you to focus on the development of the real work: the business functionality.
  
  
• Read the WebSphere Application Server Installation guide section of the WebSphere Application Server Toolkit for additional useful information.
  
  
• Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
  
  
• Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Additionally, some "Getting Started" courses are available free of charge.
  
  
• Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.
  
  
• Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

• Download trial versions of IBM Rational software.
  
  
• Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
  
  

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  
• Functional and GUI Testing forum: Ask questions about functional testing.

About the author

		Vijay Bhadriraju is a Senior Software Engineer working for IBM Software Group in Research Triangle Park Lab, North Carolina. He has 14 years of IT industry experience with 6 years spent in developing Rational and WebSphere Studio IDEs and 6 years spent in Smalltalk consulting services. He currently works on enabling IBM Business Partners on IBM IP Multimedia Subsystem and WebSphere software. He holds a Bachelor of Engineering degree in Computer Science.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top