Voice over IP or Voicechat module...webphone.module maybe ?

Correct me if I'm wrong, but this sounds like a third-party application to me, and all you would have to do to intgrate it with any webpage is assign the correct protocol handler. Like how mailto: calls your e-mail program, http: calls you browser, etc...

I'm not sure what the handler would be for voip... and the user would need software installed, the handler registered in their OS, and probably a voip service number in their drupal profile (dependant on their software).

Cheers,

Kieran

Flash has ability to record and uplaod sound and webcam images, and thus can do what you wan.t I know there is such a flash script/app around, but i cannot find it anymore.

[Ber | Drupal Services webschuur.com]

If you do find a way to do this, conferencing would be a great option as well.

On another topic, the hard thing is finding a system that will work well in all settings, not just developed countries with good high speed access.

I feel that the excitement about VoIP and Drupal is justified but the emphasis on the conversation is wrong. Drupal doesn't have much to add to VoIP in terms of facilitating computer-to-(desktop client) computer or computer-to-phone calling, other than disseminating peoples handles and/or providing callto: links. You can use Skype and related technologies to show when someone is online, which might also be interesting, but this is small stuff.

The real potential for VoIP and Drupal, in my opinion, is getting recorded voice messages and/or full conversations onto the server. Imagine a forum where you can post text replies or voice replies. A dating service where you Skype the person of your dreams and leave a message on the server that they have to pay for to hear. Imagine a citizen-journalist site where people can call the site from their cell phone and report on what is happening in front of them. You can do all this, by the way, with Skype and Pamela[1], though I've talked to developers working with the SkypeAPI who say that even better solutions are on the way.

If anyone is really interested in VoIP programming, these are the ideas to tackle. The first 10 site ideas that come to mind with such a paradigm are absolute money bomb business ideas too.

[1] http://www.pamela-systems.com/

- Robert Douglass

-----
http://www.hornroller.com/French_Horn_News
www.robshouse.net

I just read (most of ) this thread.
Want to say that being able to call a member - and vice versa (answering the caller calls up the member screen in drupal) - would take Drupal some steps towards becoming a hotline product and a crm produkt! Civicspace is working on CRM.

Gunnar Langemark
http://www.langemark.com

Hi,
I have worked with developing VoIP and videoconferencing products and services since 1996. I thought I'd just input my €.02s ... :-)

To have a voice-connection with someone via the PC you need both a client program handling the codec and directory-lookup, as well as a headset/microphone. Most people using VoIP and possibly even have subscriptions to VoIP services, are using this low-cost approach.
The client-program is typically called a softphone.

Recently, companies have started to offer more hardware-based services ... where the user interface is the well-known telephone handset. There are several ways to do this. One is by having a box from http://www.sipura.com/ or similarly, a SIP/H.323 enabled broadband-router, where you would have a telephone jack. Of course in these cases, you deal with telephone-numbers and number-plans from telcos.

When you use other interfaces than the traditional number-pad only telephone handset, you can call using different addresses schemes - which might be a mail-address (very common in SIP-terms), or a IP-address and port-number (very common in H.323 terms - but see ITU standard E.164 for further addressing). Both H.323 and SIP frequently use servers which act as directories (i.e phonebooks) and lists all available users. The Skype service synchronizes such a service, relaying the caller to a direct media-connection afterwards. The directory server is intermediating and is part of the call setup (see ITU Q.931 standard).

The centralized directory server is contacted when the user does the AAA-procedure to login and make himself available. The directory server can be a H.323 Gatekeeper, a SIP-server or similar. Asterisk * is a fantastic product for SIP and other PABX-, IVR- and VoIP-services in general. So, voicemail etc. is normally offered as services through theses servers. Both the SIP- and ITU H.323-standards cover this functionality for voice and video.

There exists proprietary clients which circumvent the use of directory servers, and may offer voicemail and other services of their own.

For Skype to recieve voicemails, you need to pay for the Skype voicemail service. If you have a device or program that let you record your own voicemail, then you will be acting as a server on your own, and the voicemail service would not work when your Skype client is not logged in.

To make VoIP calls you need the client program which includes the codec (or at least the use of the codec). That means the client program must be pre-installed - like NetMeeting, Skype and a whole host of other softphone-clients, or the client must be downloaded at the time of accessing a service - like a Drupal-based website.

Making call-references using pre-installed softphones is a trivial task. Using the standardized callto:-tag (like mentioned before) you can facilitate the direct-connection with no server-directory services involved - using the ip-address and ip-port pair. The catch-22 here is of course NAT- and firewall-traversal. Using the callto:-tag with a username/mailaddress and using a directory-server is much more preferrable.

For the downloaded client to work, it must most times be able to do NAT- as well as firewall-traversal. Most homeusers are subjected to at least NAT. The client must also handle the use of the voice codec, i.e it will use some CPU resources as well as interfacing with hardware resources - most commonly through media-APIs.

With a downloaded client I mean of course a Java applet or a Flash-based application.

When using the downloaded client it is possible to have the client taking care of the voicemail service and store it locally on the PC, but it's also possible for the website to negotiate the storage of the voicemail - acting like a intermediating server. Furthermore, it is also possible for the website to act as a directory server - receiving voicemails for users which are currently not online, or just setting up the call connection/rerouting the call.

There exist some Java-applet based calling softphones, but I have no overview of how many and what standards they adhere to or their capabilities. I remember one from the IBM developersite.

Most hardware-based VoIP products like Sipura uses the G.711 codec which requires around 80kbps both ways to give top quality - equalling or even surpassing ISDN 64-kbps call quality. While most free softphones which are multi-platform might offer a limited range of codecs - like G.711 (or PCM) and GSM (which is a very low bandwidth codec - and bad quality). Most Windows-based softphones offer the usage of many of the bundled commercial codecs on the windows platform which includes low-bandwith high-quality codecs (more CPU-intensive - just like with video) - like G.729.1 etc. which offer toll quality.

There are as you see, several considerations to offering VoIP-enhanced services through a website.

The biggest problem which has mared the Voip-industry has been the commercialization of the codecs as well as the overly complex standards with ever-changing products and services on the Internet. E.g I worked in Telenor in 1997 when we launched the world's first commercial H.323 service and programmed the client on top of Windows TAPI and using Java servlets to interface AAA login to a Ericsson supplied H.323 Gatekeeper (the worlds largest Java program at the time). The service worked ok, and we even had our own numbering plan which meant we had PC-POTS and POTS-PC capabilities. We offered a pricing plan based on Deltathree's IP backbone for VoIP.
Later on, standards like Megaco etc. just showed that there still was things to consider, and H.323 became like a umbrella-standard wanting to interoperate and incorporate every possible function and standard. Typical ITU stuff in other words. I also worked in TANDBERG (after selling my company to them in 1999) making the jump from ISDN-based videoconferencing systems to IP-based videoconferencing systems (both Putin and Bush uses high-end TANDBERG systems to talk to each other).

The SIP standard followed soon with increasingly popularity because of it's simplified text-based protocol similar to HTTP. That meant lower-cost of implentation and production - as well as faster time-to-market.

Now, Skype is very popular using G.711 over AES/Rjindael encrypted tunnels, traversing NAT and firewalls like a hot knife through butter. It also uses advanced technology like Global IP-Sound to smooth packetloss etc.

I don't think that Skype is the final word in IP telephony. The next big thing now is mobile cellular phones connecting through WiFi/WiMax hotspots or cells (WiMax IEEE 802.16 mobile offers roaming and up to 5km ranges). I used to work in NOKIA Telecommunications R&D as well, and in 1995 I was working on the switching platforms with multimedia over ATM networks and IP-tunneling etc. But now, Nokia is supporting Intel in their launch of the first WiMax chipsets, and low-power-requiring WiFi chipsets for mobile cellular phones.

There also exists stuff for connecting normal phones to Skype - see Siemens-site for Skype-phone dongle - which means newer Siemens handsets can connect to the Skype service via your PC - and you can use more advanced addressing than just the numberpad (it has a display with Skype status etc.). Just recently www.ipdrum.com announced a mobile cellular phone connecting device for Skype.

The big thing on the markets is going to be IP-based services which connects to cellular phones - one example is www.who-is.no which sends a map of the address from the phonebook-service when you ask for the address and driving directions to a phonenumber (e.g missed calls).

The other big thing is educational - as also mentioned here - where conferencing and archiving of courses and classes is very important. Mix this in with digital tv services - digitv - and you get the idea; VOD - video-on-demand. This has a potential huge impact in the developing world, where it could mean that rural areas could get access to university courses. Check out e.g BBC and their P2P push, as well as the MIT opencourse stuff for more on this - even mentioned on Wired some times.

Back to the original ideas raised here, you could do a intermediating service, whereby you could chose to reroute to a callto:-tag or reroute to a voicemail-service, based on the fact if the user was logged in or not, or even willing to answer (on no-disturb i.e). Taking the recording of the voicemail is non-trivial since it involves processing and storage of the voice-data possibly using high-cost commercial codecs. The better approach would be instructing the client application to record it locally, and then upload it - or even simultaneously uploading it. It could even be MP3, or better Ogg-Vorbis or AAC. This involves creating a fairly complex client softhphone which would be downloaded when logging in to the site (or perhaps even for anonymous users - optionally maybe). The client would be enabled inside the browser page - and then opening a separate application window when needing to - like when calling or setting options maybe.

When touching on the subject of multi-party conferencing, with muxing of audio - maybe even video, that is so complex and resources-demanding that most websites would not consider this. Take a look at the TANDBERG line of products e.g. They are equipped with several real-time OS-running embedded processors to handle the media streams - no normally equipped PC or server can do this. Examples of these dedicated processors are Philips TriMedia, Equator and TI 320cx64. All of these are multimedia-specialized VLIW-processors.
Muxing only audio is easier, but still requires some well designed very-responsive software and server, since any delay over 250 ms or around there will be an experience like using a walkie-talkie or radio where you say "over" to let anyone else speak, which sort of defies the idea of muxing audio. :-)

In any case - receiving voicemail other than pre-processed data is fairly complex. Requiring something like Asterisk is maybe overkill, but certainly the most flexible since it's a full-fledged PABX. Writing your own software is not a small project if you are going to handle live VoIP and the codecs. Writing your own client might also be a hassle if you need the client softphone to be able to handle receiving calls - which means you need to traverse NAT and/or firewalls. Otherwise the client softphone could "poll" the server - which could create immense problems on a popular website. My TAPI-based client in 1997 polled for continously AAA, but that was every 1 or 2 minutes - hardly a time someone would wait for someone to pick up the phone. Of course calling was directly using Q.931 - not polling, only AAA was polling.

I think the best overall solution would be a type of a wrapper around Skype if it's possible. Whereby it would be downloaded with a Java applet or Flash application - and then some extra functionality could be included which could make the voicemail and other features interact with the Drupal-based website. I'm sure it's not doable yet with the still evolving Skype API - and perhaps they will never allow it - they are a business after all.
I can't think of another SIP-based softphone client right now which can be wrapped - but maybe someone else has the right candidate.

I hope this information can be useful, as to what the considerations and some of the workings of current VoIP technologies are, and trying to incorporate it into a Drupal site, or module.
Also, www.voxilla.com has a lot of VoIP related discussion, on both services, software and equipment - like Asterisk.

Hey, Did this ever go anywhere? Sounds like a cool idea. Are there any live video chat modules? Can you point me to where any working chat or video chat or voice over IP functions are available?

Thanks.

Karl Erb
Communications Strategist
Information Architect, User Interface Designer

I really enjoyed reading this post, big fan. Keep up the good work and please tell me when can you publish more articles or where can I read more on the subject?
Here I can 1 more information about VoIP solution that isOzeki VoIP SIP Softphone solution, 1 of the popular and advance soluiton of VoIP.
http://www.voip-sip-sdk.com/p_91-softphone-development-basics-how-to-use...