ejabberd STUN Server

ejabberd is now much more Jingle friendly with its STUN server.

STUN (Simple Traversal Utilities for NAT) is a powerful address/network discovery tool, that can helps NAT traversal, which is the main requirements for a media(audio/video) sessions.
NAT traversal techniques are required for peer-to-peer and Voice-over-IP (VoIP) applications. Most techniques requires discover services from a publicly-routable IP address.
STUN is a method that uses the server only when establishing the connection, which saves bandwidth costs server-side, decreases latency and also boosts quality.

Jingle protocol uses STUN in a very efficient and easy way, making STUN the perfect combination for Jingle enabled Clients in order to provide peer-to-peer and great quality media sessions.

Check the diagram to understand why do you need and what can you do with a STUN Server on ejabberd:



Check it out:
svn co http://svn.process-one.net/ejabberd/trunk/src/stun/
http://svn.process-one.net/ejabberd/trunk/doc/guide.html

IM Status Message

Many people use their status messages of IM clients and micro-blog to express their feelings.
Looks pretty cool and very often you have the response or support that you want.
Some weeks ago I had a discussion with a friend about the actual meaning of a feeling can easily get lost in so short chunk of characters.

So today I put on my status text: "Biggest mistake of nature: Incompetence doesn't hurt."
I was actually making reference to a news where cops missed shots and hit innocent people, injuring some and killing one.

But it turns out, that the floating and vague phrase had impact in several colleagues and even ex-colleagues on my roster. Asking what was going on, if any project/people was failing, delayed or something.

I still think that the beauty lies in the eye of the beholder, and the same sentence can have several meanings if read by several people.

So before you put status message about DRM for instance: "I hate you, you MUST die!", you should be careful, as besides people are not sure about it. In fact it pops up a doubt and the attention of everyone in your roster: "Who is he referring? Would be me?". The same thing can happen if you put "I Love You!". For sure there are some people that you definitely don't want to think this is for them.
Remember, your status will be showed usually to all your friends and co-workers.

In the other hand status messages shows themselves as really powerful broadcast tool, use it wisely, so you can get also very fast and good results with it.

"Writing a blog post..."

Jingle Relay Nodes Full Description

In the creation of the very first version of the Jingle Protocol, one of the main goals was to achieve a P2P enable protocol, that would depend on XMPP for routing, but would be also able to negotiate sessions and exchange content without main proxy servers like present SIP deployments.

After 5 years we still don't have any massive deployments containing and fully supported the current specifications, and even the closer to the specification ones are suffering when P2P is not possible and relay is required and there is no available ones.

SIP in the other hand is not very efficient and simple for P2P methods but is widely deployed around the planet as it is much simpler to deploy and although with higher costs, can provide media connectivity.

Jingle Nodes comes in place with the goal of making more nodes available, as it makes the task of having public relays close to trivial, as you just need to run an XMPP client with a Public Node Policy available for everyone. Also makes every buddy in your contact list a potential Node.
Another positive point is that a client don't need to implement a Relay Node if not applicable, it only needs to implement the Usage specification that would be no more than two or three pages of specification as the main logic is on server side.

A few words about Jingle Nodes
Jingle Nodes and Super Nodes are intend to provide easy to use Jingle Relay Type Candidates that can be used in ICE-UDP and also on RAW-UDP Jingle Sessions.
Relay Candidates can provide NAT Traversal for users that don't have STUN/TURN Support, but also for users with STUN/TURN support that the negotiation failed.

What about similar architecture and approach?
The unique similar project is Skype, which is a closed and non inter-operable network.
Skype Network works in a similar way except that on Skype you can't choose whether share your bandwidth or not. And as a closed protocol you can't do anything about it.
On Jingle you can choose to share with:
* everyone
* nobody
* only buddies
* only whitelist
* blacklist
* etc...
In other words you are free to choose and decide about your device and network.

Another similar technologies but with less coverage is STUN/TURN.
STUN is very nicely designed technology, and it is responsible for almost all P2P VoIP traffic available nowadays. The idea is very efficient and assertive.
I also like TURN security and assertion, but it doesn't seem like the market already adopted it very widely to serve as the default VoIP relay system. But both lacks badly in simplicity and implementation timeframe.
TURN RFC is something about 80 pages, which makes it very complex and unpractical for "thin" clients like mobile voip clients, where vendors needs to release a version for almost each new mobile phone model.
Jingle Relay Nodes uses the benefit of the embedded security and flexibility of XMPP to provide the same functionality of Relay, but in a much simpler process and minimal implementation.
So we can finally have XMPP Clients doing VoIP with a pure XMPP Stack Client.

What is it that people really need?
People needs to talk. End users don't necessarily care about which protocol or connection type is being used in the call, but if it effectively has audio and with reasonable quality.
The Jingle Nodes try to promote the beauty of P2P, but without dropping the Jingle Responsibility with the end user, which is call completion.

What does Jingle have and what needs to be done?
Jingle already have specifications for Direct Media, P2P based on ICE-STUN, but it needs an extension to cover Jingle Relay Nodes.
The long term goal is to have Jingle widely deployed across the world and collaborate to this adoption by providing "easy to use" and "always works" solutions.