Category Archives: Ekiga

Skype under Microsoft – would you like additional ads with that call?

Great summary in Ars Technica of recent attempts by the brilliant minds at Microsoft to monetize Skype:

“This is part of a larger blending of Skype properties into the Microsoft advertising network,” Wolff said. “Microsoft is selling display ads on Skype’s websites, the Skype ‘home’ pane in the desktop client, and now in voice calls. How would you feel if Apple or Google did this to your mobile calling experience? It’s invasive and gets in the way of good calling experience.”

There’s never been a better time to check out a Free Software VoIP alternative, really.


Skype and Microsoft’s silly Bing Bar

Sure-fire sign that Skype is now another fine Microsoft product – and therefore unsuspecting users can expect to have installed a toolbar for a second-rate search engine as well as have their browser homepage altered:

Skype Bing Bar installation

Good to see nothing has changed with regard to Microsoft treating their current and prospective customers like idiots.

Interview with Damien Sandras, creator of Ekiga

As posted on the Ekiga users mailing list, this is an interesting interview conducted recently with Damien Sandras. Lots of good stuff here, from his views on the future of the project to how it compares with the default VoIP apps in Ubuntu.

Another Mac OS SIP client

As well as Blink, X-Lite 4 is another SIP client which plays well with Ekiga:

X-Lite 4

It’s a reasonably well-designed application, although the inclusion of built-in advertising is a turn-off.

You can view a comprehensive list of Ekiga-compatible clients here:

I’m giving back to open source communities – are you?

Open source has brought a lot of happiness into my life – exposure to cutting edge technology (thanks Sun Microsystems), an awesome no-cost operating system (running rings around the proprietary alternatives) for me, my friends and family, and thousands upon thousands of applications which allow me to perform practically any computing task imaginable, from the creative to the commonplace.

I’ve often thought about the ways I could contribute back – but given my limited funds and lack of coding chops, what could I possibly do to help out in the communities from which the products I use and enjoy originate?

Well, I’m proud to say I’ve found a way – and I now invest a sizeable amount of time in private to assist with the documentation efforts for Open Wonderland and Ekiga. In the case of Open Wonderland, large amounts of legacy documentation on (following Oracle’s abandonment of the project) need to be migrated to a community-run instance of JSPWiki (itself an open source wiki engine which comes highly recommended, by the way). For Ekiga, there is already a wealth of excellent documentation, but it’s spread out over a number of different locations, and needs updating and tidying up.

Either way, it’s a great feeling to be giving something worthwhile back, and knowing that other people out there really can benefit from the work of a non-developer. 🙂

Sipdroid interoperability with Ekiga 3.2.7

I’ve recently been playing around with various mobile SIP clients, testing how well they work making calls to Ekiga 3.2.7 clients running on the desktop. Following are some notes I’ve collected using Sipdroid 2.0.1 Beta, running on a Motorola Milestone with Android 2.1.

In all tests, I am using the Milestone on the Vodafone New Zealand 3G network, while my desktop clients are all connected to either corporate LANs with public IP addresses, or running NATed on home networks.

Generally, for voice calls, Sipdroid plays quite well with Ekiga using this network arrangement, but there are some niggles regarding the various audio codecs either SIP application supports. A summary of this follows.



First, it appears that the speex (11kbit) codec in Sipdroid’s implementation is just plain incompatible with either the Speex 8khz or Speex 16khz codecs featured in Ekiga.

Enabling only the speex (11kbit) codec in Sipdroid, and Speex 8Khz in Ekiga, I could make calls to Ekiga from the Milestone fine, but calling from Ekiga to the Milestone results in an incompatible codec error at the phone end, and the call then immediately terminates.

Enabling only speex (11kbit) in Sipdroid, and Speex 16Khz in Ekiga, calls cannot be made in either direction. Calling from the Milestone to the PC, Ekiga gets an incoming call notification but on accepting the call, the connection is lost at the PC end, with a notification that the call was missed. On the Milestone, it simply continuously reads “Dialling”. Connecting to the Milestone from the PC, one gets the same codec error as above before the call terminates.



Calls made from the Milestone to Ekiga worked great, and vice versa.



Calls made from the Milestone to Ekiga using PCMU also worked great, and vice versa.


An interesting observation at this point is that if the PCMA, PCMU and Speex codecs are all enabled in both Ekiga and Sipdroid, and in Ekiga Speex is sorted in the audio codecs window to be at the top, then calls made from Ekiga to the Milestone will fail with the codec incompatibility error. Calls made from the Milestone to Ekiga however are fine, but will fall back to a PCMU/PCMA codec.



Calls made from the Milestone to Ekiga using the G722 audio codec also worked great, and vice versa.



Calls made from the Milestone to Ekiga using the GSM audio codec also worked great, and vice versa.

Sluggish presence updates in Ekiga 3.2.7?

Generally, it’s not unusual to observe that the “Online” status of remote users on Ekiga 3.2.7 is slow to update when that user quits his/her Ekiga client. According to the developers on the mailing list, this is a known issue, and due to Ekiga not unregistering the account when the application is quit. After running a few tests, I see variances over five to eight minutes between when a remote user quits her Ekiga client, and her online status being correctly updated in my client (so that she is visibly offline).

Anyway, good to know it’s a known problem and will be looked at eventually.

Ekiga presence

More Mac OS SIP clients (which play nice with Ekiga)

I could never get Blink to work successfully with, but as of version 0.22.2 on Snow Leopard it now seems to work well with accounts. Calling to users on Ekiga 3.2.7 and vice versa poses no problem.

Blink on Snow Leopard

Theora SIP video freezes with rapid movement on Ekiga

One heck of a bizarre (and serious) bug seemingly afflicting Ekiga 3.2.7, at least on Windows.

The following video (.ogg format) was captured on an OpenIndiana oi_147 machine, running Ekiga 3.2.7. It is receiving a call from a Windows 7 (64 bit) machine, also running Ekiga 3.2.7. Theora is the only enabled video codec at both ends. Both machines have public IP addresses, and are connected to a corporate LAN.

The video below (click to play) illustrates how if rapid movement is made in front of the webcam attached to the Windows machine during the call, video can be made to freeze. Note that the application and call continues to run – just that video remains frozen.

Theora freezing on Ekiga for Windows

At the very beginning of the video we can see an incoming call from the Windows client being accepted, followed by a stable connection with good video quality. In this example, I have chosen to deliberately freeze the video 25 seconds into the call. At around 23 seconds in, I make a rapid hand movement in front of the Windows machine’s webcam; the video freezes almost immediately. The camera is then zoomed in to show that the call is in fact still active (audio for example is fine). The call is then terminated.

The freezing is much, much more easy to induce with low “Maximum video bitrate” settings in the Ekiga client preferences. All my tweaking involved adjusting the bitrate, while leaving the “Picture Quality” slider parked at maximum frame rate (i.e. all the way to the right).

1) With “Maximum video bitrate” set to 64Kb/s, the video will freeze with very slight movement; more often than not it will freeze as soon as the call is connected.

2) With “Maximum video bitrate” set to 1024Kb/s, I can reproduce the behaviour exhibited in my original video above, as that was what the settings were when the video was recorded.

3) With “Maximum video bitrate” set to a high number, e.g. 3072Kb/s, then it becomes very difficult to freeze the video deliberately; lots of flailing around in front of the camera to induce a freeze (it can still be done however).

Settings above ~4000Kb/s seem to revert to the behaviour observed when set to ~1000Kb/s however.

I have also reproduced this issue on Ekiga running on Windows XP Professional SP3.


Leave a comment if you have a firm idea of what’s going on here.

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.