Last Wednesday we did some testing of our Asterisk MeetMe setup, at dekspc medialab in London. Setting up the Asterisk server on the local wired LAN and assembling an assortment of 6 SIP clients, using Ekiga on both Windows and Linux platforms, and a Mac running the SIP client Telephone. Each client registered with Asterisk as users era1 -> era9 and dialled ‘1234’ for the MeetMe conference room.
Possibly due to the hotch-potch of audio hardware we used, and the fact that 4 out of 6 MeetMe clients we’re in the same room (with mics open), we experienced a lot of echoes in the conference call – perhaps this would be different outdoors or using headsets. As shown in the picture at the top of this post, network traffic and Asterisk server cpu/memory resources were quite minimal, even with all 6 clients connected. There are a couple of points to note about MeetMe though – it will only allow voice (no video), and only uses the ulaw audio codec; any voice data using other codecs will be transcoded by the Asterisk server. The CPU usage penalty of such transcoding could quickly overwhelm an Asus 901, and the transcoding process adds lag to the audio stream. Sound quality of the ulaw codec is restricted in MeetMe to 8KHz sampling, which is considerably less than we were using with the more advanced Speex codec, and audio quality is noticeably degraded.
Just for fun we also tried dialling into our Asterisk server from remote SIP clients, opening port UDP 5060 in the LAN firewall in front of our Asterisk server for SIP negotiation. We also opened ports 10,000 to 20,000 for audio data connections and amended the server’s sip.conf with lines saying:
in the [general] section of the file.
Like this, we found that remote clients could register with Asterisk, but no voice data would go in or out, making all connected calls silent. Since SIP trunking is not the most efficient way to make calls into Asterisk through a firewall, we gave up at this point.