Amongst many other things, we’re thinking about a video phone/conferencing solution for our traveling users. The project hasn’t had too much attention in the last months, but received much support lately, leading to both progress and demand.
Expectedly, we’re running in all type of problems, mostly caused in front of the keyboard, but sometimes due to bugs or limitations of the components we try to use. And that’s were this blog enters the game: Whenever we master a problem or solve some situation, you’ll get to read another article ;).
The intended design
As we are in an early stage, these are only basic ideas that we have not yet fully verified – and are only mentioned to give you a general idea of what I’m talking about:
- We want to keep our communications private and protected, so we currently plan to give access to our “road warriors” via VPN, instead of making the central server accessible via Internet.
- Asterisk, which we’re using as an internal service to our VoIP phones since almost forever, will be used to interconnect all clients and to provide some video conferencing solution, too.
- Our clients will be mostly Linux-based. This doesn’t rule out “Microsoft Windows” systems (there are many VoIP solutions for those and other systems), it’s just… we don’t have many of those 😉
- The users are to be equipped with Bluetooth headsets (or cable-based solutions via analog or USB audio, if they prefer), and we want support for that even within our virtual machines: We’re using passively-cooled PCs as “extended X-stations”, providing all I/O (keyboard, video, mouse, audio, USB) for our server-hosted “desktop VMs”.
Very first step
For a starter, we’ve set up an existing “Netbook computer” (an older EeePC, equipped with in-system Bluetooth and webcam) with the latest version of openSuSE (12.2), including KDE 4.8.5 and the software VoIP-phone Ekiga (version 3.3.2). Add a Bluetooth headset (Samsung WEP450) and you get what we had in front of us.
(Yes, we have other systems available, too – at least one which could be used as a second peer to test the video connections ;). Assume these to have similar software setups, just for simplicity’s sake.)
Getting Ekiga to log in to our Asterisk server was a no-brainer, and running video calls was easy, too. (Side note: This is one of the few clients I dare to say this about… unlike Linphone)
PulseAudio trouble
The real trouble started when we tried to use the Bluetooth headset. With openSuSE 12.1, this was a simple “pair & use” action, but with 12.2, this took a lot of searching on the net.
One general problem is the PulseAudio configuration, or probably lack thereof. As we noticed after turning many stones, there are entries in the syslog indicating that PulseAudio segfaults as soon as the headset has connected:
kernel: [Â 144.558576] pulseaudio[2025]: segfault at 8000000 ip b70b16a6 sp bfe605ac error 4 in libc-2.15.so[b6f6e000+19f000]
The rescue…
When you know the trick, it’s easy to fix. But setting up audio is a bit complex with Linux, so it took some time and searching to spot the following solution from RedHat’s Bugzilla:
create /etc/bluetooth/audio.conf containing the lines [General] Disable=Media Enable=Source,Sink,Gateway,Control,Socket
When we created that file on our openSuSE 12.2 system, we finally were able to see and select the entry in KDE’s “systems settings” – “Multimedia” – Phonon – “device priority”. We moved it to the top of the list for both input and output.
Within Ekiga, we went to the audio settings and selected “PTLIB/ALSA” both for audio input and output (but not for the ring tone) – and were operational.
…at least for now.
Unfortunately, after several successful calls and plenty of disconnects of the headset because the headset got carried out of the office, something broke and the Phonon device selection page in KDE’s Multimedia settings left us with a simple “PulseAudio” entry, instead of the earlier list of connected devices. But I’ll leave that to another blog article.