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:
The operator iceberg1/APCpath/operators/VatOp.java implements the operator. The very similar operator iceberg1/APCpath/operators/VatPCMOp.java is used when the audio data format to be used at the IAP is the PCM codec and not the GSM codec. The operators 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. The program "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).
Running the IAP
The IAP should be run as follows:
java iceberg1.nvsme.Main demo1-vat-iap-bhaskar.cfg
An example configuration file is demo1-vat-iap-bhaskar.cfg. Be sure to check the "smSpec" and "uiCfgFile" parameters. Note: the "uiCfgFile" is not really a file -- its just a configuration string -- the name comes from the original implementation of the IPPhone IAP. The first string in the "uiCfgFile" parameter value gives the codec format to be used by VAT. And the second string gives the uniqueID of the user running the VAT IAP.
The codec 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.
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.