SIP Forum Test Framework (SFTF) - a testing software for SIP

The SIP Forum Test Framework (SFTF) was created to allow SIP device vendors to test their devices for common errors. And as a result of these tests improve the interoperability of the devices on the market in general.

The SFTF was created by the SIP Forum Technical working Group, and is maintained here on the SIP Foundry website because the SIP Foundry has the appropriate development and other infrastructure required to properly distribute this open source project.

The SFTF currently consists out of two parts:

• The first part is the SIP test framework which allows everyone with a little programming knowledge to write his own tests for SIP devices.
• The other part is is currently a bunch of implemented tests which use this framework to test SIP User Agents for typical known errors.

License

SFTF is distributed under the General Public License (GPL ).

Documentation

User Agent Basic Test Suite 1 table

This table contains a list of all the test which are currently implemented in the User Agent Basic Test Suite 1 with call flows, expect behavior and typical failures. (Note: This page is not yet moved to the new SIP Foundry website. 

User Guide

This page gives you a detailed overview how to get the SFTF running, and what is important in the configuration to get stated with the User Agent Basic Test Suite 1.

Developers Guide

These pages contain detailed explanation of all functions from the test framework. If you are interested in writing your own tests please focus on the TestCase class as its provides the "API". The rest is more of this documentation is probably only interesting for the developers of the framework and its API itself. Note: this documentation is generated with pydoc out of the comments from within the code (similar to javadoc).

(Note: This guide is not yet moved to the new SIP Foundry website. An image of the class diagram is at the link above.)

Communications

Mailing Lists

For questions how to use the program, how to write your own tests, etc., use the SFTF Developers mailing list. If you are not afraid of making your implementations details public you can also report bugs there.

Issue Tracking

Search here for already closed bugs, add new ones and track the existing bugs

Downloads

• View the current code with your web browser.
• Check out the current code via Subversion. Access the repository as follows:

  svn checkout http://scm.sipfoundry.org/rep/sftf

Contributing

If you contribute to this project in any way this will hopefully help to improve the overall standing of the SIP business in general.
Please join the SIP Forum Mailing List for questions or discussions of the existing and any new test cases. If you have questions or bug reports about the framework or one the test implementations don't hesitate to ask them on the SFTF Developers Mailing List.
As usual ideas, feature requests, patches or any new code are always welcome.

Project Coordination

• Project Coordinator: Nils Ohlmeier
• Code Contributers: Nils Ohlmeier, Santosh Ahuja

In order to contribute code or other source material to the SFTF project, you must first execute the SIPfoundry Contributor Agreement; yes, we know that other projects don't always do this - read about why we have it.

Suggestions for SFTF contributors

These are some SFTF areas that need help. If there are other contributions you'd like to make, please don't be shy - get on the mailing list and discuss them.

Audio/RTP capabilities

The framework currently misses any kind of SDP parser. After this is done any kind of support for sending and/or receiving RTP streams would for sure be usefully. Note: a simple SDP parser and very simple support for echoing back RTP to the sender is available for download in the private directory of the author (nils), but it is not yet tested well enough to be released.

Proxy test extensions

The next step on the horizon is to start writing tests for SIP proxies as well. Currently the framework misses code which would ease to write proxy tests (e.g. answering a challenge).

Sanity checks

In general the framework still misses simple functions to make some sanity checks at the end of each test run. For example check if all transactions and dialogs are correctly terminated, or implement the verify function of all the existing header field handlers.