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
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
- 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.
- 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.
- Vat_Iap.java is the main file. It implements the
routines called by the CA and the APC.
- ConnectListener.java implements outgoing call
- DisconnectListener.java implements outgoing call
- 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
- vat_iap_call_state.java -- wrapper around
vat_iap_cs_class -- to atomically check and change session
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
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,
Modifications to VAT
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.
Bhaskaran Raman, email@example.com
Last modified: Sat Jun 3 00:20:44 PDT 2000