Posts from the ‘Conferencing’ Category
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:
Good to see nothing has changed with regard to Microsoft treating their current and prospective customers like idiots.
Openfire, Kraken, and the Facebook Messenger application
Just a quick duplicate post for an issue which I have encountered using this combination of applications. You can view the forum entry here:
Messages sent via the Facebook Messenger app may not be delivered via Kraken
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.
Cool new features in Spark 2.6.3 and the Kraken Openfire plugin
It’s been a while since I’ve looked at the Spark Java IM client – after Jive Software officially withdraw support and development resources for it I’ve tended to use other clients such as Pidgin, as Spark development had all but seemed to have ceased.
It was a nice surprise then to see that in the year or so since I last looked Spark has had at least a couple of community-developed releases, most recently version 2.6.3. There are a substantial amount of new features available, from OTR support, to a cute built-in language translator and an array of skins – my fave being the MS Office 2K7 lookalike:
Also neat is that the previous IM Gateway plugin for Openfire now lives on in a community-developed variant called Kraken:
http://kraken.blathersource.org/
Once installed in Openfire via the easy web admin BUI, one can control client connections to an array of consumer IM networks. I’ve been trying the v1.1.3 beta 3 release with Google Talk and Facebook users, and it works very well.
There is no Spark release available for OpenIndiana, but that is something I hope to address in the near future.
Another Mac OS SIP client
As well as Blink, X-Lite 4 is another SIP client which plays well with Ekiga:
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:
Cisco WRVS4400N – Skype blocking will never work
Just a quick update in my continuing experience with the Cisco WRVS4400N. As mentioned previously, I and other users have had problems using the device’s IPS facility to block Skype connections, contrary to its feature set which says it’s supported. After raising a support call with Cisco, I have heard back from a support engineer, and they state “since Skype has changed three times since the release of the WRVS4400N, we will not be able to fix this issue”.
So, if you depend on a router for the effective blocking of Skype use by employees on your network, the WRVS4400N obviously cannot be recommended for this specific feature.
Openfire 3.7.0 is out
Finally, news arrives of the latest long-awaited release of the greatest XMPP server out there:
http://community.igniterealtime.org/blogs/ignite/2011/03/02/openfire-370-has-been-released
I believe this is the first full release of the application that has been entirely the product of the surrounding community, ever since Jive Software sadly decided to ditch their involvement in it.
Nice list of new features and fixes here, and great to see they still offer a Solaris installer – which, needless to say, I’ll be trying out on OpenIndiana first.
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.
Speex
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.
PCMA
Calls made from the Milestone to Ekiga worked great, and vice versa.
PCMU
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.
G722
Calls made from the Milestone to Ekiga using the G722 audio codec also worked great, and vice versa.
GSM
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 Ekiga.net 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.
More Mac OS SIP clients (which play nice with Ekiga)
I could never get Blink to work successfully with Ekiga.net, but as of version 0.22.2 on Snow Leopard it now seems to work well with Ekiga.net accounts. Calling to users on Ekiga 3.2.7 and vice versa poses no problem.
