You are here: Home Tools AVICAN

AVICAN: Application for Video Conferencing on Active Networks

by Administrator last modified Sep 13, 2007 10:48 AM

Audio and Video examples

How create a stream file

User's Manual

Avican Configuration Examples

Implementation issues

Dispatcher informations

Locator informations


Avican is an application for video conferencing on active networks. It is completely written in Java, using standard core API and JMF. It is a centralized video conferencing system: there is a server that redistributes client audio/video streams.





The server presents a modular architecture: each main function is provided by a specific module,  the interaction between modules is managed by a "manager object". It appears like a shell, where it is possible to include a customized module by mobile code functionalities.


The main feature of this application is that the server can migrate through the network to be always in the position that guarantees the best video conference course. The server runs on the intermediate nodes of the network, where it can use the informations managed by active devices to become aware of the network status and can migrate to adapt to it. The server can migrate according to two migration strategies: relocating and cloning. In the former, the original server, after the installation in the destination node has been completed, is detached from the actual site. It is suitable for small scale conferences, where the server migrates to use the best network resources (links, for example). In the latter, the original server is not detached, then more servers are present in the network at the same time. It is suitable for large scale conferences, where each server provides different services according to its "subnet" status.

The client can decide how receiving audio/video stream: at the conference start up or after the conference started, the client sends to the server a message to set the right retransmitting module (Dispatcher) to receive streams. The application provides some default dispatchers, but the client can realize a customized dispatcher and can use it.


The server (reflector) decides the next destination using a specific module: locator. There are some locators provided by the application, but like dispatcher it is possible to use a customized locator. The locator to use is decided at start up.


The server and the client communicate using active messages. The message is a mobile agent launched by a client or by the server, when it arrives at destination it handles its function by itself. The server and the client run inside a mobility run time support, then they publish on their work space methods messages need to operate. Messages are like capsules, they have enough intelligence to make difference between different conditions and to achieve the right operation. For example, the join request message is able to understand if there is a server along the path to the destination it can turn request to. This functionality, as server mobility or customized dispatcher, is provided by a mobility framework: �Code [1].


More detailed architecture can be seen in [2]. A complete description of the tool is in  [3].



Software requirements: JDK (or JRE) 1.1.6 and JMF1.0 (local copies) or superior. JDK 1.2 is not supported.


Hardware requirements:

  • Microsoft Windows (95, 98, NT): Pentium 133MHz or faster processor and at least 32 MB RAM
  • Sparc Solaris (only 2.6 or above): UltraSparc processor recommented and at least 64 MB RAM

 Tests have been executed out on:

  • PC with Pentium at 75MHz with 40MB of RAM on Windows95. The perfomances are quite poor as client (sender and receiver at the same time), but they are better if this machine is used as server even with 4 clients.
  • PC with Pentium at 133MHz with 32MB of RAM on Windows95. The perfomances are good either as client (sender and receiver at the same time) or as server.
  • PC with Pentium-II at 400MHz with 128MB of RAM on WindowsNT v 4.0. In this case the perfomances are higher than all the previous ones either as client or server.
  • Sun Sparc station Ultra1 with 64MB of RAM. There is not any problem when the machine is used either as server or as client.



Characteristics of the present release:

  • version 1.1 updated at July 15th, 1999.
  • the server is able to migrate either by relocating or cloning (see locator instructions for more details).
  • The actual JMF release does not provide API to capture audio/video stream, then now the application provides only to send files previously captured in the acp format using TCPDump and filtering only RTP packets.

The application distribution is available as release.tar.Z. It includes the application Java packages and the �Code classes. JDK and JMF must be previously installed on the target machine. The package must be decompressed in a folder on your local hard disk.



After uncompressing distribution file, before compiling and executing the application, you must set your CLASSPATH environment variable to include Avican and  �Code classes:

  • WIN32: set CLASSPATH = "AvicanParent"\Avican\sources\;"AvicanParent"\Avican\mucode\mucode.jar;%CLASSPATH%
  • UNIX: setenv CLASSPATH "AvicanParent"/Avican/sources/:"AvicanParent"/mucode/mucode.jar:$CLASSPATH

"AvicanParent" is the directory where you decompressed the application. It has been supposed that the environment variables CLASSPATH and PATH have just been set for JDK and JMF, otherwise need you to refer to JDK and JMF installation notes.


How to test Avican

Avican is not able to capture audio and video from external source. For that reason, audio / video files previously captured must be provided to the applications.


After all these steps have been completed, you can finally use Avican. Instructions can be found in the User's Manual.


Known Problems and Bugs


  • When the application is executed on a sparc station the following exception can be thrown: "too many files opened". The solution is to set to a greater value the number of files can be opened at the same time, the command is:
prompt> limit descriptors 256
  • An "out of memory" error has been observed when the program is running on JDK1.2 on Solaris.
  • In the sparc machine there are some problems receiving the audio/video streams: an IO trap is thrown, after a segmentation fault error message.
  • JDK1.2: when the application is running on jdk1.2 there are some exceptions of linkage in the mobile agent executed inside the run time support. Maybe this is a problem of compatibility between this jdk version and mucode actual release. We have to investigate further on and solve the problem together with mucode author.
  • Native Threads: the package does not work well is the Java Virtual Machine is not using the Native Threads. These are the default ones on Windows platforms; vice versa they need to be explicitly turned on on a Sun platform (launching the Java classes with the switch -native)

Maybe, all these problems are caused by our machine perfomances and they are not application bugs. We do not have investigated using a different sparc machine more powerful than an Ultra1 yet.


  • The audio quality is less than video. The streams are captured and then retransmitted, for simplicity, with a delay derived from packet capture time: it is different of original codec delay. This way of retransmitting introduces more playing problems to audio than video streams.
  • In the client interface there could be some problems managing conference participants for client splitting upon cloning.
  • ...other bugs that have not been found yet!!



You can send feedbacks or questions to know more details about application to or to fulvio.risso[at]




[1] G. P. Picco. �Code: A Lightweight and Flexible Mobile Code Toolkit. In Proc. of the second Int. Workshop on Mobile Agents (MA 1998), September 1998.


[2] Mario Baldi, Gian Pietro Picco, Fulvio Risso: Designing a Videconference System for Active Networks. In Springer Journal of Personal Technologies, December 1998


[3] Salvatore Iacono: Implementation of a VideoConferencing Application According to the Active Network Paradigm. Laurea Thesis, Politecnico di Torino, July 1999

Document Actions