JBoss.orgCommunity Documentation

Chapter 2. SIP Servlets Server-Installing, Configuring and Running

2.1. SIP Servlet-Enabled JBoss Application Server: Installing, Configuring and Running
2.1.1. Java Development Kit (JDK): Installing, Configuring and Running
2.1.2. Pre-install Requirements and Prerequisites
2.1.3. Downloading
2.1.4. Installing
2.1.5. Setting the JBOSS_HOME Environment Variable
2.1.6. Configuring
2.1.7. Running
2.1.8. Using
2.1.9. Testing
2.1.10. Stopping
2.1.11. Uninstalling
2.2. SIP Servlet-Enabled Tomcat Servlet Container: Installing, Configuring and Running
2.2.1. Java Development Kit (JDK): Installing, Configuring and Running
2.2.2. Pre-Install Requirements and Prerequisites
2.2.3. Downloading
2.2.4. Installing
2.2.5. Setting the CATALINA_HOME Environment Variable
2.2.6. Configuring
2.2.7. Running
2.2.8. Stopping
2.2.9. Using
2.2.10. Testing
2.2.11. Uninstalling
2.3. Configuring
2.3.1. Configuring SIP Connectors
2.3.2. Application Routing and Service Configuration
2.3.3. SIP Servlets Server Logging

The Mobicents SIP Servlets Server can run on either the JBoss Application Server or the Tomcat Servlet Container. This section details how to install the SIP Servlets Server on top of the JBoss Application Server. For installation instructions for the Tomcat Servlet Container, refer to Section 2.2, “SIP Servlet-Enabled Tomcat Servlet Container: Installing, Configuring and Running”

Note

It is recommended that the SIP Servlets Server is run on the JBoss platform. Some functionality, including the ability to execute some SIP Extension examples, is not available in the Tomcat version.

Differences Between a Standard JBoss Installation and the Mobicents SIP Servlets Version

Provided here is a list of differences between a standard JBoss Application Server installation one customized for SIP Servlets. The differences include:

  • The server/default/deploy directory contains both HTTP and SIP Servlet applications (WAR and SAR2 files).

  • The server/default/deploy/jboss-web.deployer and server/default/deploy/jbossweb.sar units have been modified to provide extended classes to the standard JBoss container classes, in order to allow SIP applications to be loaded and the SIP stack to be started.

  • The server/default/deploy/jboss-web.deployer and server/default/deploy/jbossweb.sar context.xml files have been modified to allow the extended manager to manage SIP sessions and SIP application sessions in addition to HTTP sessions.

  • The server/default/deploy/jbossweb.sar/ server.xml file has been modified to provide extended classes to common JBoss Web containers. The classes allow SIP applications to be loaded, and the SIP stack to be started.

  • The server/default/deploy/jbossweb.sar/ jboss-beans.xml file has been modified to allow the JBoss container to process SIP messages.

  • The server/default/deployers/ metadata-deployer-jboss-beans.xml file has been modified to allow JBoss to parse sip.xml deployment descriptors and SIP metadata annotations.

  • The server/default/deploy/jboss-web.deployer/META-INF/jboss-service.xml file and the server/default/deploy/jboss-web.deployer/META-INF/webserver-xmbean.xml file have been modified so that it is now possible for JBoss containers to correctly deploy SIP servlets and converged applications.

  • A dars directory containing all of the Default Application Router (DAR) properties files for using the various SIP Servlets applications (which come bundled with the release) has been added to the server/default/conf directory.

  • Additional JAR files have been added to enable SIP Servlet functionality; these are located in the server/default/deploy/jboss-web.deployer/ and server/default/deploy/jbossweb.sar/ directories.

The Mobicents Platform is written in Java; therefore, before running any Mobicents server, you must have a working Java Runtime Environment (JRE) or Java Development Kit (JDK) installed on your system. In addition, the JRE or JDK you are using to run Mobicents must be version 5 or higher[1].

Should I Install the JRE or JDK?

Although you can run Mobicents servers using the Java Runtime Environment, we assume that most users are developers interested in developing Java-based, Mobicents-driven solutions. Therefore, in this guide we take the tact of showing how to install the full Java Development Kit.

Should I Install the 32-Bit or the 64-Bit JDK, and Does It Matter?

Briefly stated: if you are running on a 64-Bit Linux or Windows platform, you should consider installing and running the 64-bit JDK over the 32-bit one. Here are some heuristics for determining whether you would rather run the 64-bit Java Virtual Machine (JVM) over its 32-bit cousin for your application:

  • Wider datapath: the pipe between RAM and CPU is doubled, which improves the performance of memory-bound applications when using a 64-bit JVM.

  • 64-bit memory addressing gives virtually unlimited (1 exabyte) heap allocation. However large heaps affect garbage collection.

  • Applications that run with more than 1.5 GB of RAM (including free space for garbage collection optimization) should utilize the 64-bit JVM.

  • Applications that run on a 32-bit JVM and do not require more than minimal heap sizes will gain nothing from a 64-bit JVM. Barring memory issues, 64-bit hardware with the same relative clock speed and architecture is not likely to run Java applications faster than their 32-bit cousin.

Note that the following instructions detail how to download and install the 32-bit JDK, although the steps are nearly identical for installing the 64-bit version.

Downloading

You can download the Sun JDK 5.0 (Java 2 Development Kit) from Sun's website: http://java.sun.com/javase/downloads/index_jdk5.jsp. Click on the Download link next to "JDK 5.0 Update <x>" (where <x> is the latest minor version release number). On the next page, select your language and platform (both architecture—whether 32- or 64-bit—and operating system), read and agree to the Java Development Kit 5.0 License Agreement, and proceed to the download page.

The Sun website will present two download alternatives to you: one is an RPM inside a self-extracting file (for example, jdk-1_5_0_16-linux-i586-rpm.bin), and the other is merely a self-extracting file (e.g. jdk-1_5_0_16-linux-i586.bin). If you are installing the JDK on Red Hat Enterprise Linux, Fedora, or another RPM-based Linux system, we suggest that you download the self-extracting file containing the RPM package, which will set up and use the SysV service scripts in addition to installing the JDK. We also suggest installing the self-extracting RPM file if you will be running Mobicents in a production environment.

Installing

The following procedures detail how to install the Java Development Kit on both Linux and Windows.

Important

You do not need to install a -compat package in addition to the JDK if you installed the self-extracting RPM file! The -compat package merely performs the same SysV service script set up that the RPM version of the JDK installer does.

Configuring

Configuring your system for the JDK consists in two tasks: setting the JAVA_HOME environment variable, and ensuring that the system is using the proper JDK (or JRE) using the alternatives command. Setting JAVA_HOME usually overrides the values for java, javac and java_sdk_1.5.0 in alternatives, but we will set them all just to be safe and consistent.

Setting the JAVA_HOME Environment Variable on Generic Linux

After installing the JDK, you must ensure that the JAVA_HOME environment variable exists and points to the location of your JDK installation.

Setting the JAVA_HOME Environment Variable on Linux

You can determine whether JAVA_HOME is set on your system by echoing it on the command line:

~]$ echo $JAVA_HOME

If JAVA_HOME is not set already, then you must set its value to the location of the JDK installation on your system. You can do this by adding two lines to your personal ~/.bashrc configuration file. Open ~/.bashrc (or create it if it doesn't exist) and add a line similar to the following one anywhere inside the file:

export JAVA_HOME="/usr/lib/jvm/jdk1.5.0_<version>"

You should also set this environment variable for any other users who will be running Mobicents (any environment variables exported from ~/.bashrc files are local to that user).

Setting java, javac and java_sdk_1.5.0 Using the alternatives command
Selecting the Correct System JVM on Linux using alternatives

On systems with the alternatives command, including Red Hat Enterprise Linux and Fedora, you can easily choose which JDK (or JRE) installation you wish to use, as well as which java and javac executables should be run when called.

As the root user, call /usr/sbin/alternatives with the --config java option to select between JDKs and JREs installed on your system:

root@localhost ~]$ /usr/sbin/alternatives --config java

There are 3 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
   1           /usr/lib/jvm/jre-1.5.0-gcj/bin/java
   2           /usr/lib/jvm/jre-1.6.0-sun/bin/java
*+ 3         /usr/lib/jvm/jre-1.5.0-sun/bin/java


Enter to keep the current selection[+], or type selection number:

In our case, we want to use the Sun JDK, version 5, that we downloaded and installed, to run the java executable. In the alternatives information printout above, a plus (+) next to a number indicates the one currently being used. As per alternatives' instructions, pressing Enter will simply keep the current JVM, or you can enter the number corresponding to the JVM you would prefer to use.

Repeat the procedure above for the javac command and the java_sdk_1.5.0 environment variable, as the root user:

~]$ /usr/sbin/alternatives --config javac
~]$ /usr/sbin/alternatives --config java_sdk_1.5.0
Setting the JAVA_HOME Environment Variable on Windows

For information on how to set environment variables in Windows, refer to http://support.microsoft.com/kb/931715.

Testing

Finally, to make sure that you are using the correct JDK or Java version (5 or higher), and that the java executable is in your PATH, run the java -version command in the terminal from your home directory:

~]$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b03)
Java HotSpot(TM) Client VM (build 1.5.0_16-b03, mixed mode, sharing)
Uninstalling

There is usually no reason (other than space concerns) to remove a particular JDK from your system, given that you can switch between JDKs and JREs easily using alternatives, and/or by setting JAVA_HOME.

Uninstalling the JDK on Linux

On RPM-based systems, you can uninstall the JDK using the yum remove <jdk_rpm_name> command.

Uninstalling the JDK on Windows

On Windows systems, check the JDK entry in the Start menu for an uninstall command, or use Add/Remove Programs.

The latest version of Mobicents SIP Servlets for JBoss is available from http://www.mobicents.org/mss-downloads.html. The top row of the table contains the latest version.

Each version of the SIP Servlets Server is comprised of two separate binary distribution files: one which is MSS for JBoss, and the other which is MSS for Tomcat. Download SIP Servlets Server for JBoss and continue with the following instructions.

Once the requirements and prerequisites have been met and you have downloaded the binary distribution zip file, you are ready to install the MSS for JBoss binary distribution. Follow the instructions below for the selected platform, whether Linux or Windows.

Configuring MSS for JBoss consists of setting the JBOSS_HOME environment variable and optionally customizing the MSS for JBoss server by adding SIP Connectors, configuring the application router, and logging.

After setting JBOSS_HOME according to the instructions in the following section, refer to Section 2.3, “Configuring” to learn how to configure MSS for JBoss.

Alternatively, after having set JBOSS_HOME, the MSS for JBoss server can be run. Return to this section to configure it later.

The Mobicents Platform (Mobicents) is built on top of the JBoss Application Server (JBoss AS). You do not need to set the JBOSS_HOME environment variable to run any of the Mobicents Platform servers unless JBOSS_HOME is already set.

The best way to know for sure whether JBOSS_HOME was set previously or not is to perform a simple check which may save you time and frustration.

Checking to See If JBOSS_HOME is Set on Unix

At the command line, echo $JBOSS_HOME to see if it is currently defined in your environment:

~]$ echo $JBOSS_HOME

The Mobicents Platform and most Mobicents servers are built on top of the JBoss Application Server (JBoss AS). When the Mobicents Platform or Mobicents servers are built from source, then JBOSS_HOME must be set, because the Mobicents files are installed into (or “over top of” if you prefer) a clean JBoss AS installation, and the build process assumes that the location pointed to by the JBOSS_HOME environment variable at the time of building is the JBoss AS installation into which you want it to install the Mobicents files.

This guide does not detail building the Mobicents Platform or any Mobicents servers from source. It is nevertheless useful to understand the role played by JBoss AS and JBOSS_HOME in the Mobicents ecosystem.

The immediately-following section considers whether you need to set JBOSS_HOME at all and, if so, when. The subsequent sections detail how to set JBOSS_HOME on Unix and Windows

You DO NOT NEED to set JBOSS_HOME if...
You MUST set JBOSS_HOME if...

Naturally, if you installed the Mobicents Platform or one of the Mobicents server binary releases which do not bundle JBoss AS, yet requires it to run, then you should install JBoss AS before setting JBOSS_HOME or proceeding with anything else.

Setting the JBOSS_HOME Environment Variable on Unix

The JBOSS_HOME environment variable must point to the directory which contains all of the files for the Mobicents Platform or individual Mobicents server that you installed. As another hint, this topmost directory contains a bin subdirectory.

Setting JBOSS_HOME in your personal ~/.bashrc startup script carries the advantage of retaining effect over reboots. Each time you log in, the environment variable is sure to be set for you, as a user. On Unix, it is possible to set JBOSS_HOME as a system-wide environment variable, by defining it in /etc/bashrc, but this method is neither recommended nor detailed in these instructions.

Procedure 2.5. To Set JBOSS_HOME on Unix...

  1. Open the ~/.bashrc startup script, which is a hidden file in your home directory, in a text editor, and insert the following line on its own line while substituting for the actual install location on your system:

    export JBOSS_HOME="/home/<username>/<path>/<to>/<install_directory>"
  2. Save and close the .bashrc startup script.

  3. You should source the .bashrc script to force your change to take effect, so that JBOSS_HOME becomes set for the current session[2].

    ~]$ source ~/.bashrc
  4. Finally, ensure that JBOSS_HOME is set in the current session, and actually points to the correct location:

    Note

    The command line usage below is based upon a binary installation of the Mobicents Platform. In this sample output, JBOSS_HOME has been set correctly to the topmost_directory of the Mobicents installation. Note that if you are installing one of the standalone Mobicents servers (with JBoss AS bundled!), then JBOSS_HOME would point to the topmost_directory of your server installation.

    ~]$ echo $JBOSS_HOME
    /home/silas/mobicents-all-1.2.1.GA-jboss-4.2.3.GA/jboss/
Setting the JBOSS_HOME Environment Variable on Windows

The JBOSS_HOME environment variable must point to the directory which contains all of the files for the Mobicents Platform or individual Mobicents server that you installed. As another hint, this topmost directory contains a bin subdirectory.

For information on how to set environment variables in recent versions of Windows, refer to http://support.microsoft.com/kb/931715.

To start the server, execute one of the startup scripts in the bin directory (on Linux or Windows), or by double-clicking the run.bat executable batch file in that same directory (on Windows only). It is recommended that the JBoss Application Server is started using the terminal or Command Prompt because the messages displayed during startup can be used to debug, and subsequently correct, any problems. In the Linux terminal or Command Prompt, a successfully started server will return the following information (ending with "Started in 23s:648ms"):

17:48:01,247 INFO  [Server] JBoss (MX MicroKernel) [4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)] Started in 20s:861ms

Detailed instructions are given below, arranged by platform.

After installation, there should be one pre-configured sample application deployed in the default server onfiguration. You can use it to verify that the server is installed and running correctly. The application name is “org.mobicents.servlet.sip.example.SimpleApplication”. From the Sip Servlets Management Console you can make sure it is subscribed to receive INVITE and REGISTER SIP requests. It is a simple Click2Call application allowing SIP registration and calling phones from the Web user interface.

The scenario for this example consists of the following steps:

Procedure 2.8. Testing the Click2Call sample application

  1. Open up a browser to http://localhost:8080/click2call/. If you have no registered SIP clients you will be asked to register at least two.

  2. Configure your SIP clients to use the sip servlets server as a register and proxy. (IP address : 127.0.0.1, port: 5080) By default it will accept any password

  3. After the registration you will see a table where each cell will initiate a call between the corresponding clients.

  4. Close the calls.

  5. Navigate to http://localhost:8080/click2call/simplecall.html, which is a simplified version that doesn't require registered clients.

  6. Enter the URIs of the two SIP phones you just started and click "Submit"

  7. The phones should be ringing again. You can pick them up and you will know that the SIP and the HTTP containers are working properly.

You can also run Mobicents SIP Servlets on top of the Apache Tomcat Servlet Container. This section provides information on the requirements and prerequisites for running MSS for Tomcat, as well as instructions on how to download, install, configure, run, use, stop, test and uninstall it.

Keep in mind that not all capabilities provided by running Mobicents SIP Servlets Server on top of the JBoss Application Server are available with MSS for Tomcat. In particular, MSS for Tomcat lacks support for both clustering and failover; MSS for Tomcat nodes can utilize the SIP load balancer, however.

If you are interested in clustering and failover support, or would rather run the Mobicents SIP Servlets Server on top of the JBoss Application Server, go to Section 2.1, “SIP Servlet-Enabled JBoss Application Server: Installing, Configuring and Running”.

Differences Between the Standard Tomcat Installation and One Customized for the SIP Servlets Server

Provided here is a list of differences between a standard Tomcat Servlet Container installation and the SIP Servlets Server for Tomcat installation. The differences include:

  • The server.xml configuration file has been modified to provide extended classes to the standard Tomcat container classes, in order to allow SIP applications to be loaded and the SIP stack started.

  • A dars directory containing the default applications' router properties files for using the SIP Servlet Click-to-Call application (which comes bundled with the release) has been added to the conf directory.

  • Additional JAR files which can be found in the lib directory have been added to enable SIP Servlet functionality.

Installing the Java Development Kit

The Mobicents Platform is written in Java; therefore, before running any Mobicents server, you must have a working Java Runtime Environment (JRE) or Java Development Kit (JDK) installed on your system. In addition, the JRE or JDK you are using to run Mobicents must be version 5 or higher[3].

Should I Install the JRE or JDK?

Although you can run Mobicents servers using the Java Runtime Environment, we assume that most users are developers interested in developing Java-based, Mobicents-driven solutions. Therefore, in this guide we take the tact of showing how to install the full Java Development Kit.

Should I Install the 32-Bit or the 64-Bit JDK, and Does It Matter?

Briefly stated: if you are running on a 64-Bit Linux or Windows platform, you should consider installing and running the 64-bit JDK over the 32-bit one. Here are some heuristics for determining whether you would rather run the 64-bit Java Virtual Machine (JVM) over its 32-bit cousin for your application:

  • Wider datapath: the pipe between RAM and CPU is doubled, which improves the performance of memory-bound applications when using a 64-bit JVM.

  • 64-bit memory addressing gives virtually unlimited (1 exabyte) heap allocation. However large heaps affect garbage collection.

  • Applications that run with more than 1.5 GB of RAM (including free space for garbage collection optimization) should utilize the 64-bit JVM.

  • Applications that run on a 32-bit JVM and do not require more than minimal heap sizes will gain nothing from a 64-bit JVM. Barring memory issues, 64-bit hardware with the same relative clock speed and architecture is not likely to run Java applications faster than their 32-bit cousin.

Note that the following instructions detail how to download and install the 32-bit JDK, although the steps are nearly identical for installing the 64-bit version.

Downloading

You can download the Sun JDK 5.0 (Java 2 Development Kit) from Sun's website: http://java.sun.com/javase/downloads/index_jdk5.jsp. Click on the Download link next to "JDK 5.0 Update <x>" (where <x> is the latest minor version release number). On the next page, select your language and platform (both architecture—whether 32- or 64-bit—and operating system), read and agree to the Java Development Kit 5.0 License Agreement, and proceed to the download page.

The Sun website will present two download alternatives to you: one is an RPM inside a self-extracting file (for example, jdk-1_5_0_16-linux-i586-rpm.bin), and the other is merely a self-extracting file (e.g. jdk-1_5_0_16-linux-i586.bin). If you are installing the JDK on Red Hat Enterprise Linux, Fedora, or another RPM-based Linux system, we suggest that you download the self-extracting file containing the RPM package, which will set up and use the SysV service scripts in addition to installing the JDK. We also suggest installing the self-extracting RPM file if you will be running Mobicents in a production environment.

Installing

The following procedures detail how to install the Java Development Kit on both Linux and Windows.

Important

You do not need to install a -compat package in addition to the JDK if you installed the self-extracting RPM file! The -compat package merely performs the same SysV service script set up that the RPM version of the JDK installer does.

Configuring

Configuring your system for the JDK consists in two tasks: setting the JAVA_HOME environment variable, and ensuring that the system is using the proper JDK (or JRE) using the alternatives command. Setting JAVA_HOME usually overrides the values for java, javac and java_sdk_1.5.0 in alternatives, but we will set them all just to be safe and consistent.

Setting the JAVA_HOME Environment Variable on Generic Linux

After installing the JDK, you must ensure that the JAVA_HOME environment variable exists and points to the location of your JDK installation.

Setting the JAVA_HOME Environment Variable on Linux

You can determine whether JAVA_HOME is set on your system by echoing it on the command line:

~]$ echo $JAVA_HOME

If JAVA_HOME is not set already, then you must set its value to the location of the JDK installation on your system. You can do this by adding two lines to your personal ~/.bashrc configuration file. Open ~/.bashrc (or create it if it doesn't exist) and add a line similar to the following one anywhere inside the file:

export JAVA_HOME="/usr/lib/jvm/jdk1.5.0_<version>"

You should also set this environment variable for any other users who will be running Mobicents (any environment variables exported from ~/.bashrc files are local to that user).

Setting java, javac and java_sdk_1.5.0 Using the alternatives command
Selecting the Correct System JVM on Linux using alternatives

On systems with the alternatives command, including Red Hat Enterprise Linux and Fedora, you can easily choose which JDK (or JRE) installation you wish to use, as well as which java and javac executables should be run when called.

As the root user, call /usr/sbin/alternatives with the --config java option to select between JDKs and JREs installed on your system:

root@localhost ~]$ /usr/sbin/alternatives --config java

There are 3 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
   1           /usr/lib/jvm/jre-1.5.0-gcj/bin/java
   2           /usr/lib/jvm/jre-1.6.0-sun/bin/java
*+ 3         /usr/lib/jvm/jre-1.5.0-sun/bin/java


Enter to keep the current selection[+], or type selection number:

In our case, we want to use the Sun JDK, version 5, that we downloaded and installed, to run the java executable. In the alternatives information printout above, a plus (+) next to a number indicates the one currently being used. As per alternatives' instructions, pressing Enter will simply keep the current JVM, or you can enter the number corresponding to the JVM you would prefer to use.

Repeat the procedure above for the javac command and the java_sdk_1.5.0 environment variable, as the root user:

~]$ /usr/sbin/alternatives --config javac
~]$ /usr/sbin/alternatives --config java_sdk_1.5.0
Setting the JAVA_HOME Environment Variable on Windows

For information on how to set environment variables in Windows, refer to http://support.microsoft.com/kb/931715.

Testing

Finally, to make sure that you are using the correct JDK or Java version (5 or higher), and that the java executable is in your PATH, run the java -version command in the terminal from your home directory:

~]$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b03)
Java HotSpot(TM) Client VM (build 1.5.0_16-b03, mixed mode, sharing)
Uninstalling

There is usually no reason (other than space concerns) to remove a particular JDK from your system, given that you can switch between JDKs and JREs easily using alternatives, and/or by setting JAVA_HOME.

Uninstalling the JDK on Linux

On RPM-based systems, you can uninstall the JDK using the yum remove <jdk_rpm_name> command.

Uninstalling the JDK on Windows

On Windows systems, check the JDK entry in the Start menu for an uninstall command, or use Add/Remove Programs.

You can download the latest version of MSS for Tomcat from http://www.mobicents.org/mss-downloads.html. The top row of the table holds the latest version. Note that each release of the Mobicents SIP Servlets Server is comprised of two separate binary distribution files: one which is MSS for JBoss, and the other which is MSS for Tomcat. Download Mobicents SIP Servlets Server for Tomcat and continue with the following instructions.

Once the requirements and prerequisites have been met and you have downloaded the binary distribution zip file, you are ready to install MSS for Tomcat. Follow the instructions below for your platform, whether Linux or Windows.

Procedure 2.13. Installing the MSS for Tomcat Binary Distribution on Linux

  1. For this example, we'll assume you're currently in your home directory, which is where you downloaded the zip file to. First, create a subdirectory to hold the unzipped MSS for Tomcat files. It is good practice to include the version number in this directory name; if you do so, remember to correctly match it with the version of the MSS for Tomcat distribution you downloaded.

    ~]$ cd downloads
  2. In downloads, create a subdirectory to hold the unzipped MSS for Tomcat files. It is good practice to include the version number in this directory name; if you do so, remember to correctly match it with the version of the MSS for Tomcat binary distribution you downloaded.

    ~]$ mkdir "mss-tomcat-<version>"
  3. Move the downloaded zip file into the directory you have just created:

    ~]$ mv "mss-1.0.GA-apache-tomcat-6.0.14-0904221257.zip" "mss-tomcat-<version>"
  4. Move into that directory:

    ~]$ cd "mss-tomcat-<version>"
  5. Finally, use Java's jar -xvf command to extract the contents of the zip file into the current directory, thus completing the install:

    mss-tomcat-<version>]$ jar -xvf "mss-1.0.GA-apache-tomcat-6.0.14-0904221257.zip"
    • Alternatively, if Linux's unzip utility is present on your system or is installable, you can use it in lieu of Java's jar -xvf command:

      mss-tomcat-<version>]$ unzip "mss-1.0.GA-apache-tomcat-6.0.14-0904221257.zip"

      Note

      You can also use unzip's -d <unzip_to_location> option to extract the zip file's contents to a location other than the current directory.

  6. To free disk space, you may want to delete the zip file once you've extracted its contents:

    mss-tomcat-<version>]$ rm "mss-1.0.GA-apache-tomcat-6.0.14-0904221257.zip"

Procedure 2.14. Installing the MSS for Tomcat Binary Distribution on Windows

  1. For this example, we'll assume that you downloaded the binary distribution zip file to the My Downloads folder. First, using Windows Explorer, create a subdirectory in My Downloads to extract the zip file's contents into. When you name this folder, it is good practice to include the version number; if you do so, remember to correctly match it with the version of the MSS for Tomcat binary distribution you downloaded. In these instructions, we will refer to this folder as mss-tomcat-<version>.

  2. Double-click the downloaded zip file, selecting as the destination folder the one you just created to hold the zip file's contents.

  3. At this point, you may want to move the folder holding the MSS for Tomcat binary files (in this example, the folder named mss-tomcat-<version>) to another location. This step is not strictly necessary, but it is probably a good idea to move the installation folder from My Downloads to a user-defined location for storing runnable programs. Any location will suffice, however.

  4. You may want to delete the zip file after extracting its contents in order to free disk space:

    C:\Users\Me\My Downloads\mss-tomcat-<version>>delete "mss-1.0.GA-apache-tomcat-6.0.14-0904221257.zip"

Before running the Mobicents server you are installing, you should consider if you need to set the CATALINA_HOME environment variable. Setting it (or re-setting it) will always work. Whether or not you need to set CATALINA_HOME depends on the following factors:

The following instructions detail how to set CATALINA_HOME on both Linux and Windows.

Procedure 2.15. Setting the CATALINA_HOME Environment Variable on Linux

  1. The CATALINA_HOME environment variable must point to the location of your Tomcat installation. Any Mobicents server which runs on top of the Tomcat servlet container has a topmost directory, i.e. the directory in which you unzipped the zip file to install the server, and underneath that directory, a bin directory. CATALINA_HOME must be set to the topmost directory of your Mobicents server installation.

    Setting this variable in your personal ~/.bashrc file has the advantage that it will always be set (for you, as a user) each time you log in or reboot the system. To do so, open ~/.bashrc in a text editor (or create the file if it doesn't already exist) and insert the following line anywhere in the file, taking care to substitute <mobicents_server> for the topmost directory of the Mobicents server you installed:

    export CATALINA_HOME="/home/<username>/<path>/<to>/<mobicents_server>"

    Save and close .bashrc.

  2. You can—and should—source your .bashrc file to make your change take effect (so that CATALINA_HOME is set) for the current session:

    ~]$ source ~/.bashrc
  3. Finally, make sure that CATALINA_HOME has been set correctly (that it leads to the right directory), and has taken effect in the current session.

    The following command will show the path to the directory pointed to by CATALINA_HOME:

    ~]$ echo $CATALINA_HOME

    To be absolutely sure, change your directory to the one pointed to by CATALINA_HOME:

    ~]$ cd $CATALINA_HOME && pwd

Once installed, you can run the Tomcat Servlet Container by executing the one of the startup scripts in the bin directory (on Linux or Windows), or by double-clicking the run.bat executable batch file in that same directory (on Windows only). However, we suggest always starting Tomcat using the terminal or Command Prompt because you are then able to read—and act upon—any startup messages, and possibly debug any problems that may arise. In the Linux terminal or Command Prompt, you will be able to tell that the container started successfully if the last line of output is similar to the following:

Using CATALINA_BASE:   /home/silas/temp/apps/mobicents/sip_servlets_server/mss-tomcat-1.0
Using CATALINA_HOME:   /home/silas/temp/apps/mobicents/sip_servlets_server/mss-tomcat-1.0
Using CATALINA_TMPDIR: /home/silas/temp/apps/mobicents/sip_servlets_server/mss-tomcat-1.0/temp
Using JRE_HOME:       /etc/java-config-2/current-system-vm

Detailed instructions are given below, arranged by platform.

Detailed instructions for stopping the Tomcat Servlet Container are given below, arranged by platform. Note that if you properly stop the server, you will see the following three lines as the last output in the Linux terminal or Command Prompt (both running and stopping the Tomcat Servlet Container produces the same output):

Using CATALINA_BASE:   /home/silas/temp/apps/mobicents/sip_servlets_server/mss-tomcat-1.0
Using CATALINA_HOME:   /home/silas/temp/apps/mobicents/sip_servlets_server/mss-tomcat-1.0
Using CATALINA_TMPDIR: /home/silas/temp/apps/mobicents/sip_servlets_server/mss-tomcat-1.0/temp
Using JRE_HOME:       /etc/java-config-2/current-system-vm

SIP Connectors are added in the same way as HTTP Connectors: by adding a <Connector> element under the <Service> element in the container's server.xml configuration file.

Mobicents SIP Servlets has three SIP Connectors configured by default : UDP And TCP are running on the binding IP Address of the container and port 5080 and TLS is running on the binding IP Address of the container and port 5081

For example, to add a SIP Connector on the IP address 127.0.0.1, on port 5080, using the UDP transport protocol, you should insert the following XML element:


SIP <connector> Attributes

port

The port number on which the container will be able to receive SIP messages.

ipAddress

The IP address at which the container will be able to receive SIP messages. The container can be configured to listen to all available IP addresses by setting ipAddress to 0.0.0.0 <sipPathName>.

protocol

Specifies the connector is a SIP Connector and not an HTTP Connector. There is no need to change this property.

signalingTransport

Specifies the transport on which the container will be able to receive SIP messages. For example, "udp".

usePrettyEncoding

Allows Via, Route, and RecordRoute header field information to be split into multiple lines, rather than each header field being separating with a comma. The attribute defaults to "true". Leaving this attribute at the default setting may assist in debugging non-RFC3261 compliant SIP servers.

useStun

Enables Session Traversal Utilities for NAT (STUN) support for this Connector. The attribute defaults to "false". If set to "true", ensure that the ipAddress attribute is not set to 127.0.0.1. Refer to Section 7.4, “STUN Support” for more information about STUN.

stunServerAddress

Specifies the STUN server address used to discover the public IP address of the SIP Connector. This attribute is only required if the useStun attribute is set to "true". Refer to Section 7.4, “STUN Support” for more information about STUN and public STUN servers.

stunServerPort

Specifies the STUN server port of the STUN server used in the stunServerAddress attribute. You should rarely need to change this attribute; also, it is only needed if the useStun attribute is set to "true". Refer to Section 7.4, “STUN Support” for more information about STUN.

addressResolverClass

Specifies the gov.nist.core.net.AddressResolver implementation class that will be used by the container to perform DNS lookups. The default class used by the container is org.mobicents.servlet.sip.core.DNSAddressResolver but any class implementing gov.nist.core.net.AddressResolver NIST SIP Stack interface and having a Constructor with a org.mobicents.servlet.sip.core.SipApplicationDispatcher param can be used. To disable DNS lookups, this attribute should be left empty..

sipStackPropertiesFile

Specifies the location of the file containing key-value pairs corresponding to the SIP stack configuration properties. This attribute is used to further tune the JAIN SIP Stack. If this property is omitted, the following default values are assumed:

  • gov.nist.javax.sip.LOG_MESSAGE_CONTENT=true

  • gov.nist.javax.sip.TRACE_LEVEL=32

  • gov.nist.javax.sip.DEBUG_LOG=logs/mss-jsip-debuglog.txt

  • gov.nist.javax.sip.SERVER_LOG=logs/mss-jsip-messages.xml

  • javax.sip.STACK_NAME=Mobicents-SIP-Servlets

  • javax.sip.AUTOMATIC_DIALOG_SUPPORT=off

  • gov.nist.javax.sip.DELIVER_UNSOLICITED_NOTIFY=true

  • gov.nist.javax.sip.THREAD_POOL_SIZE=64

  • gov.nist.javax.sip.REENTRANT_LISTENER=true

Mobicents SIP Servlets also adds its own properties to allow for even more configuration and flexibility :

  • If the property org.mobicents.servlet.sip.SERVER_HEADER is set, A Server header will be added to all SIP Responses leaving the container.

  • If the property org.mobicents.servlet.sip.USER_AGENT_HEADER is set, A Server header will be added to all SIP Requests leaving the container.

useStaticAddress

Specifies whether the settings in staticServerAddress and staticServerPort are activated. The default value is "false" (deactivated).

staticServerAddress

Specifies what load-balancer server address is insterted in Contact/Via headers for server-created requests. This parameter is useful for cluster configurations where requests should be bound to a load-balancer address, rather than a specific node address.

staticServerPort

Specifies the port of the load-balancer specified in staticServerAddress . This parameter is useful in cluster configurations where requests should be bound to a load-balancer address rather than a specific node address.

Note

A comprehensive list of implementing classes for the SIP Stack is available from the Interface Sip Stack page on nist.gov. For a comprehensive list of properties associated with the SIP Stack implementation, refer to Class SipStackImpl page on nist.gov.

The application router is called by the container—whether JBoss or Tomcat—to select a SIP Servlet application to service an initial request. It embodies the logic used to choose which applications to invoke. An application router is required for a container to function, but it is a separate logical entity from the container. The application router is solely responsible for application selection and must not implement application logic. For example, the application router cannot modify a request or send a response.

For more information about the application router, refer to the following sections of the JSR 289 specification: Application Router Packaging and Deployment, Application Selection Process, and Appendix C.

In order to configure the application router, you should edit the Service element in the container's server.xml configuration file:


Provided here is a description of the SIP Service element's attributes:

className

This attribute specifies that the servlet container is a converged (i.e. SIP + HTTP) servlet container. This attribute can also be used to handle load-balancing and failover.

sipApplicationDispatcherClassName

This attribute specifies the class name of the org.mobicents.servlet.sip.core.SipApplicationDispatcher implementation to use. The routing algorithm and application selection process is performed in that class.

darConfigurationFileLocation

The default application router file location. This is used by the default application router to determine the application selection logic. Refer to Appendix C of the JSR 289 specification for more details.

additionalParameterableHeaders

Comma-separated list of header names that are treated as Parameterable by the container. The specified headers are classed as valid, in addition to the standard Parameterable headers defined in the Sip Servlets 1.1 Specification.

Setting and getting parameters is allowed for the standard, and additional parameters. Parameters that are not specified in additionalParameterableHeaders will result in a ServletParseException error.

baseTimerInterval

Specifies the T1 Base Timer Interval, which allows the SIP Servlets Container to adjust its timers depending on network conditions. The default interval is 500 (milliseconds).

For more information about available timers, refer to RFC326 "Table of Timer Values"1, and the document contained in the 3GPP-IMS TS 24.229 v9.1.0 specification ZIP archive.

Most of the timers present in the tables depend on T1, except for T2, T4, and Timer D (for the client transactions). The underlying SIP Servlets JAIN SLEE stack places further conditions on T2, T4, and Timer D through baseTimerInterval.

dispatcherThreadPoolSize

The number of threads used for processing SIP messages inside the Sip Servlets container by the dispatcher. The default value is 4.



[1] At this point in time, it is possible to run most Mobicents servers, such as the JAIN SLEE Server, using a Java 6 JRE or JDK. Be aware, however, that presently the XML Document Management Server does not run on Java 6. We suggest checking the Mobicents web site, forums or discussion pages if you need to inquire about the status of running the XML Document Management Server with Java 6.

[2] Note that any other terminals which were opened prior to your having altered .bashrc will need to source ~/.bashrc as well should they require access to JBOSS_HOME.

[3] At this point in time, it is possible to run most Mobicents servers, such as the JAIN SLEE Server, using a Java 6 JRE or JDK. Be aware, however, that presently the XML Document Management Server does not run on Java 6. We suggest checking the Mobicents web site, forums or discussion pages if you need to inquire about the status of running the XML Document Management Server with Java 6.