Build a Push Proxy Gateway on Linux

Starting the gateway
Before you begin with PPG, you need to start the gateway. To do this, you first need to configure it by editing the kannel.conf file. (You can learn how in the "Configuring the gateway" section of the first article in this series.)

After you've configured the gateway, starting it involves two steps. First, start the bearerbox with the following command:

./bearerbox -v 1 <conf_file>

The -v 1 sets the logging level to INFO. With this option, you won't see a large amount of debugging output (the default is DEBUG <conf_file>). <conf_file> is the name of the configuration file you are using with Kannel. The basic distribution packet comes with the sample configuration file wapkannel.conf (in the /gw subdirectory), which is for setting up WAP Kannel. You can edit that configuration file to set up your own specialized system.

After starting the bearerbox, you need to start the wapbox by typing the following command:

./wapbox -v 1 <conf_file>

For more command-line options, review the Kannel User Guide.

Setting up the test environment
I'll set up the test environment by configuring the PPG as well as the client-side mobile handset simulator.

You can download a handset simulator from Nokia (see Resources for a link). Install it and, in the settings, change the gateway IP address to that of the machine where your PPG will be running. You can use an IP address on your internal LAN if you want. You might need to restart the simulator.

Now, to set up the PPG, you must put my_unconfpap.xml and si.xml into the gw/test directory. Then, find the test_ppg executable file, which is the test program for behaving as a push initiator.

Sending push information to the simulator
In tmy_uncnfpap.xml, check to make sure that deliver-before-timestamp and deliver-after-timestamp are set to appropriate values; otherwise, the push might not be delivered to the client. The WAPPUSH value must be set to the simulator's client IP address. The TYPE has to be set to IPv4@ppg.carrier.com. Have a look: the bearer value should be set to CSD.

In si.xml, set the created and si-expires values to the correct timestamp values. If you don't, the push message will be invalid and won't be delivered. Similarly, if you want to work with SL or CO push documents, you need to write your own corresponding XML file.

You are now ready to send a sample push message to the mobile simulator. Just check to make sure that you are in the gw/test directory. To make a push request to the client, type the command shown in Listing 6:

./test_ppg -q http://ppg-host-name:ppg-port/ppg-url<content_file> <control_file>

In my example, <content_file> is the SI document (si.xml) and <control_file> is the PAP document (my_uncnfpap.xml). The ppg-host-name is the hostname of the system running the PPG, and the ppg-port is the PPG port number as set in the kannel.conf file. In the command shown in Listing 6, the -q option is given to run the test program in quiet mode. For various other command-line options, please refer to the Kannel User Guide.

You should see an indication on the simulator saying "push message received." If you want to retrieve this document, then you are redirected to the site that is indicated in the href tag of the si.xml document.

Avenues for further testing
You can try creating your own SI-, SL-, or CO-type documents and testing them in a real-life fashion with a mobile simulator. Push content developers and WAP application developers can benefit from this. You can also use my_cnfpap.xml to send the push request in a confirmed manner; simply change the delivery-method to confirmed in the quality-of-service tag.

Conclusion
In this article, I described how to set up a low-cost push proxy gateway, and how this gateway can help you develop push content and test out applications. Because it uses Linux and standard hardware, this method is easy, has a low cost, is highly configurable, and can help you get started in developing push applications and content.

 |