a SIMPLER conference call system

Skaperen · 07-13-2012, 11:28 AM

I'm trying to do conference calls with skype and this is just not working well above 3 people.

I think it would be better to have a "dial in to" type conference system. But PSTN dialing makes no sense anymore, so it should just be done over UDP or SCTP.

Existing tools are oriented to also using PSTN and it is making them overly complex to configure. I'm looking for something to do voice conferencing that is just IP-only and leaves out all the other stuff. Video and chat are OK, but all over IP-only is the goal.

It would need a client, of course. Multi-platform for the client is a plus (Linux, BSD, OSX, and that other OS would be last).

Software like Asterisk is just way overkill for things like this, and I want to avoid it.

Edit:
It would be better to just call this an "IP-based voice conferencing system" or IVCS.

mjolnir · 07-13-2012, 02:24 PM

I may be missing some of your parameters here but would something like a google+ hangout work here? I use a 3g Mifi 2200 and get good results with both audio and video with up to 8 other people plus you can call out to landlines.

Skaperen · 07-13-2012, 02:33 PM

Quote:

Originally Posted by mjolnir

I may be missing some of your parameters here but would something like a google+ hangout work here? I use a 3g Mifi 2200 and get good results with both audio and video with up to 8 other people plus you can call out to landlines.

I'm looking for the software so I can run something myself, on my own server. Going through outside providers is out of the question. Anything like Asterisk is too much. I do NOT want a phone system. I want just a conferencing system that sits idle doing nothing until a conference is needed. Then everyone "calls in" by running the app, tell it which hostname (or IP), optional port number, providing a conference identity and password. Maybe a user name and user password. TLS encryption. Traffic all goes to and back from the server (I run the server part on).

A client for Linux is a must. A client for OSX is a plus. A client for Windows may interest other people.

schneidz · 07-13-2012, 02:57 PM

in the past i've done stuff like use netcat and pipe raw audio packets too/from /dev/dsp.

Skaperen · 07-13-2012, 03:15 PM

Things I do not want to use and reasons why:

Quote:

Asterisk is a software implementation of a telephone private branch exchange (PBX); it was created in 1999 by Mark Spencer of Digium. Like any PBX, it allows attached telephones to make calls to one another, and to connect to other telephone services including the public switched telephone network (PSTN) and Voice over Internet Protocol (VoIP) services. Its name comes from the asterisk symbol, “*”.

I don't want a PBX or any of the complications of setting up a PBX. All I need is conferencing based on IP, not PSTN.

Quote:

Elastix is an open source Unified Communications Server software that brings together IP PBX, email, IM, faxing and collaboration functionality. It has a Web interface and includes capabilities such as a Call Center software with predictive dialing.

I don't need to bring all this other stuff together. I just need basic voice conferencing. Text chat within the conference would be a plus. Video might also be. I don't need predictive dialing or a call center.

Quote:

FreeSWITCH is free and open source communications software for the creation of voice and messaging products. It is licensed under the Mozilla Public License (MPL), a free software license. Its core library, libfreeswitch, is capable of being embedded into other projects, as well as being used as a stand-alone application.

I don't need a phone switch. I don't need to create voice and messaging products.

Quote:

The GNU Gatekeeper (abbreviated as GnuGk) is an open-sourced project that implements an H.323 Gatekeeper based on the OpenH323 or H323Plus stack. A gatekeeper provides address translation, admissions control, call routing, authorization and accounting services to an H.323 system defined on the H.323 standard by ITU-T.

I don't need all that stuff. I don't need any standardizing beyond having clients on major platforms (free on the free platforms).

Quote:

MySIPSwitch is an experimental stateful SIP Proxy server sponsored by Blue Face to allow the use of multiple supplier SIP accounts from a single SIP login. It basically means that you can use many SIP accounts with a single piece of hardware (IP Phone, ATA or softphone).

I doubt a proxy will do the job. Looks like yet another phone switch (seems we have plenty of those).

Quote:

SIP Express Router (SER) is a SIP server licensed under the GNU General Public License. It can be configured to act as SIP registrar, proxy or redirect server. SER features presence support, RADIUS/syslog accounting and authorization, XML-RPC-based remote control and others. Web-based user provisioning, serweb, is available.

I don't need all that stuff that may or may not really be needed for a phone switch. Registering, proxying, and redirecting are not things I need. I don't want RADIUS (overkill ... a passwd file should be good enough).

Quote:

Yate (acronym for Yet Another Telephony Engine) is a free and open source communications software with support for video, voice and instant messaging. It is an extensible, GPL licensed, telephony engine mainly focused on VoIP and PSTN. It is written in C++, having in mind a modular design, allowing the use of scripting languages like Perl, Python or PHP to create external functionalities.

Looks like another phone switch system. I don't need the external functionalities.

Quote:

Mumble is a voice over IP application primarily designed for use by gamers, similar to programs such as TeamSpeak and Ventrilo.

Mumble uses a client–server architecture which allows users who want to talk to each other connect to the same server. It has a very simple administrative interface and most of the engineering effort is put into sound quality and low latency. All communication is encrypted to ensure user privacy.

This seems to be going in the right direction, but ...

Quote:

A Mumble server (called Murmur) has a root channel and a hierarchical tree of channels beneath it. Users can link channels together to temporarily create large virtual channels. This is useful during larger events where a small group of users may be chatting in a channel, but they will be linked to a common channel with other users to hear announcements. It also matches well with team-based FPS games. Each channel has an associated set of groups and access control lists which control user permissions. The system is fairly complex allowing many different usage scenarios, but this complexity also makes it hard to configure.

Complexity is what I want to avoid. All this might be of great interest to gamers. I just need voice conferencing over simple apps.

Quote:

There is an integrated overlay for use in games. The overlay shows who is talking and what linked channel they are in. As of version 1.0, users can upload their own avatars to represent themselves in the overlay, creating a much more personalized experience. As of version 1.2, the overlay works with most Direct3D 9/10 and OpenGL games on Windows and has OpenGL support for Linux and Mac OS X. DirectX 11 game support is planned, but the project manager working on the overlay does not have access to DX11 hardware to test on.

Overly complicated for the purpose I need.

Skaperen · 07-13-2012, 03:21 PM

Quote:

Originally Posted by schneidz

in the past i've done stuff like use netcat and pipe raw audio packets too/from /dev/dsp.

For two people maybe that might work. Any buffer latency due to rate differences?

But what I need is to support multiple people within the same conference, access control into the conference (password is sufficient), and encryption. Low latency is essential. UDP would seem to be the correct transport since if a chunk of data is lost, it takes too much to go back and recover it.

And I need clients for other platforms.

The server would accept connections, enable encryption, determine what conference is desired, verify the conference password, and tie into that conference (transfer the socket to that conference's daemon). User names is a plus. Audio would be compressed reasonably. The daemon would add together all the audio samples and output the summed value back to everyone. Feedback detection and fixup would be nice. Tools to set up and tear down conferences would be good.