Monthly Archives: November 2010

Problems with Ekiga and a D-Link DSL-302G home router

I recently troubleshot a problem with Ekiga 3.2.7 running on Ubuntu 10.10 x86. The application could not successfully make a test call with full two way audio; audio from the far end was not successfully received.

Looking back through the Ekiga list archives revealed at least one other user with similar problems on this model of router:

The solution in my case was to simply assign the host problem system a fixed IP address, and set up a port forwarding rule in the router thusly:

Ekiga Port fowarding rule in the D-Link DSL-302G

Test calls could then be made okay.


Mac OS SIP clients (which play nice with Ekiga)

Seeing as Ekiga isn’t available on Mac OS, I’ve been playing around with the various SIP clients out there for the platform.

So far I’ve found that SIP Communicator and Telephone both work great with Ekiga 3.2.7 on OpenIndiana, at least for VoIP.

SIP Communicator


Convert a physical PC into a VirtualBox virtual machine

This seems to be a fairly popular topic out there, so I thought I’d share my little how-to. It’s not really different to other guides you may read, but given Oracle’s inevitable imminent alienation of the VirtualBox community, the inevitable jacking up of the support costs, the inevitable stifling of development resources and feature enhancements followed by the inevitable fork (perhaps with some patent litigation thrown in for good measure), what better time to try it out? 🙂


My test source physical machine is an old Pentium 4 box running Windows XP Home SP3. It contains a single 75GB HDD, itself holding a single partition occupying the whole disc. Nothing fancy. The objective is to convert the machine into a VMware VMDK image file, then import that into VirtualBox (in this case, version 3.1.4 running on an OpenIndiana oi_147 host). According to the VirtualBox user manual, the VMDK format is fully supported by VirtualBox. If you’re trying this out yourself, note that in this guide I’m assuming prior basic familiarity with creating VMs in VirtualBox.

Our first step is to download and install the free VMware vCenter Converter Standalone application on the physical source PC. You can grab it from the following location – but note you will need to create an online account and register to receive a download link (yuck):

After downloading, simply step through the installation wizard defaults – there are no surprises nor quirks to note.


Once installed, let’s run the vCenter Converter application, and convert our machine to a virtual clone:

vCentre - convert a machine...

Yes, we want to use the machine that is powered on and running the vCenter application itself:

vCenter - powered on local machine...

For now I am saving the clone to the HDD of the machine I am cloning from – we are going to resize the clone’s HDD size, so we won’t have any space issues (obviously use a larger physical disc, pop another disc in the machine, or save to large external storage otherwise). Note that we using VMware Workstation 7.0.x file format, and the name of our clone is “cybernoid-virtual”:

vCenter destination settings

In the Options screen that follows, click on the “Data to copy” entry on the left hand side pane, and on the right hand side click on “Advanced…”, where we can get at the disc resize settings:

vCenter advanced options

We have resized the destination (clone) HDD to be 20GBs (with the “type” set to “not pre-allocated”). Also, for the other options available in this screen, we have specified a single CPU, 500MB of RAM, and NAT networking. Make a note of these latter options and their settings, as we’ll need to manually enter them into VirtualBox when recreating the virtual machine there:

vCenter options

That’s all I configured here, leaving everything else at the defaults, and letting the application clone the physical machine (which took about an hour).


At the end of the process, vCenter Converter had created a folder containing the critical cybernoid-virtual.vmdk file. I copied this file over to my OpenIndiana machine, fired up VirtualBox 3.1.8, and imported it using the VirtualBox Virtual Media Manager.

I then used the VirtualBox New Virtual Machine Wizard to create a Windows XP virtual machine, pointing to the .vmdk file to use for its virtual hard disc. I was careful to set it to use 500MB of memory, and only a single CPU.


Finally firing it up, I was met with a VirtualBox splash screen, followed by a blank, black screen with no other activity. Although the VM reported a status of “Running” it was clearly failing to boot at all. Referring to the VirtualBox Windows migration how-to here…

…I came across the following section:

“…If you perform a Windows installation with default settings in VirtualBox, Halacpi.dll will be chosen as VirtualBox enables ACPI by default but disables the IO APIC by default. A standard installation on a modern physical PC or VMware will usually result in Halaacpi.dll being chosen as most systems nowadays have an IO APIC and VMware chose to virtualize it by default (VirtualBox disables the IO APIC because it is more expensive to virtualize than a standard PIC). So as a first step, you either have to enable IO APIC support in VirtualBox or replace the HAL. Replacing the HAL can be done by booting the VM from the Windows CD and performing a repair installation…”

Rather than shag around with a repair installation, I simply enabled IO APIC in the VirtualBox settings for the machine, and bingo:

Cloned VM running in VirtualBox

My host machine is an Intel Q8200 which doesn’t have Intel VT-x (thanks so much, Intel…), but even so, performance is pretty good.


I also tried the above procedure to create a virtual clone of a laptop running Windows 7 64 bit. It also worked fine, but only after using an IDE storage controller to attach the VMDK to in the VirtualBox settings for the VM – using SATA, the VM would refuse to boot without a BSOD:

VirtualBox storage controller settings

Windows 7 VirtualBox guest

Outgoing SIP call problem in Ekiga 3.2.7 on OpenIndiana

Quick problem with a quick resolution: on my desktop OpenIndiana oi_147 machine, I found I was unable to make SIP voice calls to any of my contacts, nor even a test call to the the test service at

After a quick posting to the Ekiga mailing list with an accompanying debug file, I received a helpful response from another user (Eugen Dedu), who pointed out that packet sizes were too big as a result of too many audio codecs being selected in the application preferences.

After enabling a basic set of audio codecs in Ekiga, I could then place calls fine:

Ekiga audio codecs

Ekiga test call working

Ekiga could do with some fine tuning vis a vis somewhat more helpful error reporting, but all the same I am glad to have this working. For VoIP calls at least there is an impressive amount of interoperabilty on offer here amongst Windows, Linux, and OpenIndiana platforms. With a bit more testing and documentation (eventually branching out to H323, video, and interoperability with commercial hardware-based SIP/H323 solutions) I’m looking forward to recommending Ekiga as a one-stop solution for cross-platform open source desktop A/V conferencing.

Oracle’s virtualisation bundles have no license costs!

No, wait, that’s not quite right…let’s work on this:

Oracle - not quite right


(Received via email this evening…)

Disabling the loud system beep in OpenSolaris / OpenIndiana

I was never bothered by this until upgrading to OpenIndiana on a Dell T3400 running OpenSolaris snv_134. Praveen Kumar has a great how-to which explains what to do:

Tunnelling X over SSH slow?

When connecting from an OpenIndiana machine on a corporate LAN to a home machine on a domestic ADSL2+ line (also running OpenIndiana, via port forwarding), X window sessions over SSH (ssh -X) were so slow to render as to make working a total drag. Enabling the use of compression in the client’s SSH configuration file resulted in a considerable speed-up:

Add the following to /etc/ssh/ssh_config

Compression yes
CompressionLevel 2

ranges from 1 (fastest) to 9 (best).

As far as the server goes for allowing compression by clients, according to man sshd_config:

Controls whether the server allows the client to negoti‐
ate the use of compression. The default is yes.”