Multiple User Voice Chat with Candy, Openfire & WebRTC

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.

Image1.jpg

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)

1 Like

Very nice, sir! :wink: I’ll try this out by adding these features to my WebRTC beta programm.

Is the reason you don’t use Jingle is because of Jingle issues, or because of issues with the websockets plugin dealing with jingle messages?

Nothing wrong with Jingle

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?

Tx for ur work

Sorry, it does not work for you.

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.

Any help is much appreciated, thanks!

Hello Dele & team,

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:

  1. Installed openfire_2013-01-26.tar.gz

  2. Created two user accounts (ie 100 & 200) and can IM using Swift window clints.

  3. Installed candy (ie candy.zip) in the Apache’s www folder.

  4. When I access the http//192.168.0.233/candy/example page, I get the login page. Everything looks OK

  5. I then enter the user name – bob and press login.

  6. Unfortunately, now I get the following message – “Connecting” and nothing else happens.

  7. In the Chrome’s console, I see the following message

[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

Any idea as to what I am doing wrong? I would love to get this demo working. Thanks for your help and support.

Cheers

Aelix.

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.

I get the error

WebSocket connection to ‘ws://rig1.kyla.fi/ws/server?username=null&password=null&resource=ozssx8v2h’ failed: Unexpected response code: 404

could this be because Jingle Node fails to verify the public IP address.

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.

Aelix,

I pretty much get the same error that you are getting

[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

WebSocket connection to ‘ws://rig1.kyla.fi/ws/server?username=null&password=null&resource=19noci4qg’ failed: Unexpected response code: 404 index.html:1

_onclose - disconnected strophe-connection-websockets.js:706

[Connection] Disconnected candy.bundle.js:158

From this post http://community.igniterealtime.org/blogs/ignite/2012/11/25/webrtc-demo-for-open fire-using-websockets-jinglenodes-plugins#comment-7728i get the intuition that the Websocket connection url has to include the port number if the service is being run from a different webserver.

Aelix,

I pretty much get the same error that you are getting

[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

WebSocket connection to ‘ws://rig1.kyla.fi/ws/server?username=null&password=null&resource=19noci4qg’ failed: Unexpected response code: 404 index.html:1

_onclose - disconnected strophe-connection-websockets.js:706

[Connection] Disconnected candy.bundle.js:158

From this post http://community.igniterealtime.org/blogs/ignite/2012/11/25/webrtc-demo-for-open fire-using-websockets-jinglenodes-plugins#comment-7728i get the intuition that the Websocket connection url has to include the port number if the service is being run from a different webserver.

Aelix,

I pretty much get the same error that you are getting

[Init] Debugging enabled

WebRtc.init

[Connection] Connecting

[Connection] Authenticating

WebSocket connection to ‘ws://rig1.kyla.fi/ws/server?username=null&password=null&resource=19noci4qg’ failed: Unexpected response code: 404 onclose - disconnected

[Connection] Disconnected

From this post http://community.igniterealtime.org/blogs/ignite/2012/11/25/webrtc-demo-for-open fire-using-websockets-jinglenodes-plugins#comment-7728i get the intuition that the Websocket connection url has to include the port number if the service is being run from a different webserver.

Aelix,

I get pretty much the same error that you get ,

[Init] Debugging enabled

WebRtc.init

[Connection] Connecting

[Connection] Authenticating

WebSocket connection to ‘ws://rig1.kyla.fi/ws/server?username=null&password=null&resource=u1tuz3vdu’ failed: Unexpected response code: 404

_onclose - disconnected

[Connection] Disconnected

From this post http://community.igniterealtime.org/blogs/ignite/2012/11/25/webrtc-demo-for-open fire-using-websockets-jinglenodes-plugins#comment-7728 i get the intuition that the WebSocket connection should be made to a url that also includes the port number in case if you are running it from a difference web server.

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

Chats are Not Yet Dead = CANYD

I think you should rename it Chats are not dead yet

It’s the same thing…

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 …

It works if the request is made to ws requests are made through port 7070.