The VAT IAP

This document describes the specifics of the VAT IAP. For a general description of an IAP, refer iap.html.

The VAT IAP is an Iceberg front-end (or proxy if you will) to the VAT audio conferencing tool.

The specifics of the VAT IAP are as follows:

• It has a Java Swing GUI. The GUI is'nt great and there are probably better ways of doing it. But it is okay for basic functionality.
• It implements only outgoing DTMF since incoming DTMF makes no sense to the end user.
• It can operate with vat using one of two data formats: gsm or pcm-ul-8000. (These the two data formats supported by the APC -- of course, this list can be extended).
• It supports only a single session at a time. A functionality that would be trivial to add would be to notify the user of an incoming call (when a call is already in place) and allow the user to hang up the current call, and accept the incoming call.

The GUI

• Enter the callee's email address (Iceberg unique-id) and press "Connect" to establish a call.
• Press "Disconnect" to terminate call.
• On incoming call, press "accept call" within 15 seconds to accept the call.

The files

• Vat_Iap.java is the main file. It implements the routines called by the CA and the APC.
• ConnectListener.java implements outgoing call establishments.
• DisconnectListener.java implements outgoing call terminations.
• DTMFListener.java implements outgoing DTMF tones.
• VatThrClass.java implements the per-session thread. The thread simply exec's vat and waits on it. Note: vatrec is exec'ed instead of vat when the IAP gets the remote IP address as "127.0.0.1" or "0.0.0.0". This happens when the VAT IAP end only receives data and does not send any data (e.g., when listening to songs from the Jukebox). That is, the forward path does not involve any transcoding. The APC does not tell the IAP of the source IP address of the data in these cases. This is a limitation of the current implementation. Vatrec is exec'ed in these cases since vat needs to be given a specific IP address from which to receive data (vat does a bind to a specific IP address -- at least in Linux, vatrec does not).
• vat_iap_cs_class.java -- the call state associated with a session.
• vat_iap_call_state.java -- wrapper around vat_iap_cs_class -- to atomically check and change session state.

Running the IAP

The IAP needs to be run as an iSpace service. Add the following line to your iSpace.config file (the one you pass as argument when you run ninja.ispace.Main.

iceberg.iap.vat_iap.Vat_Iap name-server iPOP[:port] Format

The name-server argument exists for historical reasons -- plug in a dummy value. The iPOP is the machine that is running the iPOP, and the port is the iSpace port on which the iPOP is running (defaults to 1099). Format is one of "gsm" or "pcm-ul-8000". Vat is run with "gsm" format or PCM U-Law 8kHz when given those arguments, respectively.

I had to modify vat a wee-bit to make things work. The original vat strictly runs with RTP data on an even port, and RTCP control on the next odd port. This happens even when you give an odd port as a command-line argument. This restriction created problems when the APC chose ports that were odd. Modifying APC to work-around this seemed less appropriate because of two reasons: (a) it required too much change, and (b) it is a hack to get around a specific restriction. Hence I changed vat to allow operation with odd data ports as well. Here's the change I made to the "vat" TCL script (you can find this by typing "which vat"):

In procedure "AddressBlock instproc data-port", replace the "return [expr $p &~ 1]" with "return $p". Do the same in the procedure "AddressBlock/RTP instproc data-port" as well.