WebRTCis definitely a game changing technology and desktop phones may soon be on their way to join VHS players in yesterdayland
A while back, I developed an Openfire plugin for Candy (Chats Are Not Yet Dead) which enabled multi-user voice chatting. It included a voice bridge to mix the audio streams on the server side and a Flash-based component to capture and play the audio streams in the web browser. It kinda worked, but has too many issues to be used in a production context.
I have replicated that application with WebRTC just using only HTML5 and JavaSccript. No server-side component for audio mixing and no browser component to handle streams. All audio mixing, capturing and playing is handled by the web browser.
As usual, there are caveats. A star topology with a server-side audio bridge will scale into hundreds of conference participants while client side peer to peer audio conferencing will struggle to get up to 10 users per conference. A ten person audio conference will consume 90 (10x9) peer connections.
However, getting away from conventional ringtone and telephone signaling using SIP or even Jingle allows to explore alternative approaches to voice communication and experience distant digital talking as naturally as possible without the restrictions of a telephone or software replacement. This is definitely the way to go. Sisko calling OâBrien
Click on a tab brings the group chat room into focus. Click again will turn voice on and broadcast everything you say to everyone in the group chat room. Click one more time and your voice is turned off. It works as a toggle. Click on another group chat room tab and your voice be turned off when focus moves away. On the other side, you can turn off the voice of any participant by using Candyâs ignore feature. Just right click on the contact and select ignore. Select unignore to restore back the voice of the participant.
It is that simple. No ringtones, just use your voice with text and say hello
Donât take my word for it, you can try it it out here and the source code is attached to this blog for those would like to a look at the implementation. Even though it does **not **use SIP or Jingle signalling, It uses Jingle Nodes to act a a media relay when users are sitting behind restrictive routers or firewalls.
You need Chrome version 23+ or Chrome Frame with Internet Explorer. Candy has also been updated to work with the Openfire Websockets plugin as well. candy.zip (934694 Bytes)
I have used it in OfChat WebRTC implementation to handle signalling of voice calls and establish a session between two or more participants in a chat or groupchat respectfully.
What I am saying is that in XMPP chat or groupchat, there is no need to signal an incoming call. Session is already established. All we need to do is exchange media SDP (offer/answer). For that we donât need Jingle or even SIP. We just pass the SDP as payload in the
The Demo does not work for me- it says âConnectingâŚâ all the time.
Can u explain what is needed on server side, what on cliet side (beyond chrome browser) and which protocols and ports are used. What about firewalls and proxes issues?
Nothing beyond Openfire and JIngle Relay Nodes is needed on server. It is using standard XMPP MUC. The media only goes to Jingle Relay if Chrome cannot establish a peer connection directly with another peer.
Get hold of WebRTC documentation to find out out what UDP ports Chrome uses. See Jingle Relay Nodes documentation for the UDP ports allocated and used.
XMPP messages are passed over standard http port 80 using websockets. maybe your network has a http proxy server that is blocking websockets
Are there any instructions on how to connect the supplied source code for candy and webRTC with openfire?
Right now I have (im sure quite naively) tried to use apache as the server for the source code and (unsucessfully) direct the javascript to my openfire server.
I certain that I am misunderstanding the task but do not have any other ideas.
I am new to the openfire offerings. I am trying to get âMultiple User Voice Chat with Candy, Openfire & WebRTCâ working. My current step is as follows:
Installed openfire_2013-01-26.tar.gz
Created two user accounts (ie 100 & 200) and can IM using Swift window clints.
Installed candy (ie candy.zip) in the Apacheâs www folder.
When I access the http//192.168.0.233/candy/example page, I get the login page. Everything looks OK
I then enter the user name â bob and press login.
Unfortunately, now I get the following message â âConnectingâ and nothing else happens.
In the Chromeâs console, I see the following message
I have updated the zip file with code from the demo running on redfire.4ng.net/candy. The old code is broken with Chrome ver 24.
I donât see why it should not work with Apache as it uses openfire websockets which allows connections from any domain. I use Jetty web server in Openfire.
I however noticed yoy are trying to access with an IP address. That will not work. You nned to use the domain name you used when configuring your Openfire server. If the name is not in your DNS, then create it or change to a domain name that resolves via DNS.
Hello Dele, I have reinstalled Openfire_2013-01-30 and Candy on a development server that is in the public domain. Unfortunately, I am still getting the same error. [Init] Debugging enabled candy.bundle.js:158 WebRtc.init candy.bundle.js:158 [Connection] Connecting candy.bundle.js:158 [Connection] Authenticating candy.bundle.js:158 Unexpected response code: 404 :1 _onclose - disconnected strophe-connection-websockets.js:706 [Connection] Disconnected candy.bundle.js:158 Would it be possible for you to troubleshoot the problem on my development server remotely? I can email you the login information. Once the system is working, you can then share the information with the group. What do you think? Cheers. Aelix.
The code was a zip file taken from the demo running on redfire.4ng.net. On that server, Openfire web server is running on port 80/443 instead of default 7070/7443. If you are using Openfire web server with defaults and/or you are hosting the candy application elsewhere, then you need to change that line in the code. The code assumes that Candy app is run on same server as Openfire
look for line 191 in libs/strophe-connection-websockets.js
Dele and Vidhuran Here is my setup: 1.Openfire is running with default port setting â no changes were made. 2.Candy (ie redfire.4ng.ne0 version) is installed on the same server in the apache /var/www folder â no changes made to the candy 3.The server is setup in the public domain with Openfire and Candy. Both Admin and Users accounts are working on the Openfire in this setup. Are the Openfire and Candy port setup correctly in this configuration? Thanks Aelix
I have exactly the same setup running apache and candy being served from /var/www, and i also made the change that Dele suggested but for some reason the ws request is still being made without the port number. From the console in chrome i observe that the strophe-connection-websockets.js doesnât contain my change ⌠assuming that it comes from the cache i cleared them but still no effect ⌠kind of puzzled but trying to find out the way âŚ