Jingle Nodes in Campus Party Brazil

Jingle Nodes Project will be presented in Campus Party Brasil in a very special way. Besides the keynote, there will be also 3 Educational workshops where the protocol and current solutions will be discussed in practice:

• Installing an OpenSource IM Server with support for Audio and Video.
• How to customize and adapt a VoIP Client to suit your personal or company needs.
• How to build your own VoIP Client using OpenSource APIs. 

When in Campus Party Brazil make sure you check out the talk about Jingle Nodes and how you can get independence in your daily communication, therefore protected against "digital dictatorship" blocks like the Skype Block in China and Nimbuzz Block in Syria.

Facebook VoIP Architecture and the Death of Phone Numbers

As we know Facebook supports XMPP for Chat, meaning you can use your preferred XMPP Client to use Facebook for Chat. But do you really think Facebook rolled out XMPP support only for Chat?
If so, you are indeed wrong.
Facebook wants to expend their communication profile. Like others like Google, MSN, Yahoo, Skype, etc, they also want realtime interaction meaning Voice and Video communications.

Reasons:

• Facebook users have more Facebook Friends than contacts in their phonebook.
• People change phone numbers and your are not automatically updated.
• Phone Numbers belongs to Operators/Countries, your Facebook account is much more personal.
• You can control who can call you. On regular phone you are often victim of unwanted calls.
• Phone Calls and SMS are more expensive them IM and VoIP in most cases.
• Facebook average number of Contacts per user is way bigger than Skype.
• Skype is too limited and close to create the same loyalty that Facebook always had.
• If they also open this for XMPP Federation, it would indeed speed up the death of "phone numbers" as we know.

Technology:

• As Facebook already have support for XMPP Chat, certainly they will use XMPP Jingle.
• For Media Relay and Distribution Points? For sure Jingle Nodes will be the simplest, fastest and most reliable way to delivery Multimedia for their gigantic number of users at once.
• How would it look like for browser users? They will use new advanced browser features to have Jingle Clients running on it. Like GMail already have for a long while.
• They already have the PERFECT routing and presence in place, XMPP for Chat, same exact route can be used for Jingle if Facebook enable support for IQ routing in their XMPP network.

Overall Picture:

This post is a proposition of how Facebook will do their Voice/Video support in near future. The use of Jingle and Jingle Nodes is not confirmed at all. But sure will be an extremely bad idea of Facebook to do not do it like described above! I challenge them to do it better and more open than this.

GMail VoIP Coming Soon

Sooner than we though GMail will integrate VoIP services. This happens right after GIPS acquisition, and quite way too late after Gizmo5 acquisition.
Gizmo5 had for a long long time such widget but was using several layers of software from server side transcode, flash capture and an extra plugin.
I really hope they are thinking hard to have their widget based on embedded browser features. As it would be quite simple to embed a real VoIP(RTP/Codec) API in Google Chrome at least. That will really move the perspective on Broswer based VoIP to a new level!

The whole market will also appreciate if they make such API as open as possible so other could also create their browser based VoIP Clients.
We would even be pleasured if such API to be available also on Android Devices.

Google don't disappoint us.

Why Skype UI OpenSource?

When legacy proprietary companies start all of a sudden OpenSourcing their software, a lot of questions are raised. Of course they have their own explanations for the facts, although frequently are not the whole true about the fact.
Since Skype announced their OpenSource UI, I received some email asking why would that happen and what are the reasons behind the curtains.
Here is a personal explanation based on some facts:

Background Story:

• Skype started their business in a market almost empty of competition. VoIP indeed existed, but was NOT directed to end users, neither mass market.
• OpenSource would not make sense as it usually (for big companies) takes way more time and money to build solutions on top of standards then creating your own black box with the solutions of your own problems and challenges inside. And the lack of demand for a standard format was about 99%.
• Another reason is the "secret" factor, as the first ones, they have to create all the buzz around their holly grail and of course ensure the domination.
• That is why(among other reasons) Skype made their business on top of proprietary routing algorithms and proprietary protocols and encryption.

Early VoIP Market:

• In the other hand for very small VoIP services the picture is different as they started on top of OpenSource platforms, even in a time that most of them were experimental. The reason is, the target market was massively smaller than Skype targets. And of course the money to invest was way smaller as well.
• SIP adoption was adopted in almost 99% of the rising small providers that started popping up everywhere in the world.
• Interesting fact is that most pioneer small VoIP providers started with virtual PBX system, not even SIP routers and big platforms. Basically "grow on demand" strategy was adopted as well.

Current VoIP Market Snapshot:

• VoIP is way more spread in the world since Skype started the massification. We have large number of companies building equipments, client soft-phones, VoIP platforms etc...
• We have a ridiculous huge number of VoIP providers which anther ridiculous range of different prices and quality.
• SIP is the main driver for major market. It is used on landlines in Europe and US, it is massively used in company PBX and telephony of big companies. Which are the main source of PAYED VoIP services.
• Skype is smaller in amount of users and revenue, if compared to all SIP Providers together.
• Google acquires Gizmo5 a medium VoIP provider fully operated over SIP. Yes it has direct relation.

Consequences to Skype:

• Skype ubiquity is restricted by their Desktop Client or their very limited IPhone client.
• Skype still growing the amount of Desktop users. But the amount of paying users is still and tends to get lower.
• Skype interoperability is null, as it is based on proprietary system and specifications.
• Competition makes more money and the migration from old Skype users to new VoIP alternatives is big. As educated users knows now how to change and why to change to cheaper and flexible services.
• We have more SIP enabled equipment and computers than Desktops with Skype client installed.

Skype Strategy Turn:

• OpenSource their SILK codec as already mentioned in this blog.
• Open SIP Gateway for Business Users. In order to start competing in a very profitable market slice.
• Bought the patent of their VoIP routing solutions. In order to prepare for an interoperability round.
• Aim for alternative and relatively "virgin" markets like mobile, Linux, netbooks etc:
• Release more usable mobile clients.
• OpenSource as much as possible for Linux as current client is really crap and also Linux users in general don't use closed source applications.

The Reason in Resume:
Skype wants its ubiquity and revenue back, and for that they are investing huge resources in Openness and Standardization, as it is what their market needs and demands nowadays.

In a mash-able hyper-connected world, who is closed and not interoperable will fade.

Jingle on IPhone over 3G and Apple's Plan Exposed

Recently I posted about Jingle achievements, so today I will use the hook to explain how Jingle fits in Apple and also Carriers plans.

As we know main communication suites that we have for Apple Devices are based or at least related with XMPP (IChat, Adium, Bonjour Protocol, etc...).

You might also have noticed that there was no native application on IPhone capable of doing IM or VoIP Calls.

I presume you know the reasons right? IPhone was subsidized by Carriers in order to kick off usage of GPRS Data and increase SMS traffic. Creating the bases for the non sense block of VoIP over 3G on IPhone, as the main goals were conflicting.

Apple always knew that they could not block it forever, although why not block for a while, as we don't have any potential competitor and we can get some extra revenues?

These are all no longer valid, old facts.

The current market is different in many important aspects, such as:

• There are competitors for IPhone market.
• SMS Traffic is reached its maximum peak as it is fated to die due: IM, MicroBlog, Push Notifications, etc...
• WiFi HotSpots are way more spread nowadays.
• VoIP Providers Usage is stronger than ever.
• Carriers started the surrender and changed the focus to DataPlan and aggregated services. 3G is the new goal for operators as they MUST offer an Internet solution or be switched to a WiFi alternative.
• Nokia Platform Maemo is completely focused on Internet Services and Communications.

Let's put the pieces together and reverse engineer the plan based on current available facts:

• Apple opens Jingle/P2P Job Positions on September.
• One week after Motorola announces their Android Phone, Apple announces 3G Calling won't be blocked on AppStore anymore for AT&T and Verizon.
• US Carriers blogged and announced to be Data Plan friendly.
• Nokia Maemo N900 will be release with tons of IM and Communication tools in a matter of weeks from now.

Conclusions:

Having 3G Calling supported on AppStore is the best path to avoid complains about a native App that could do VoIP natively. Which turns out to be very handy to be done using Jingle as the main target is not landlines, but other IPhone/Apple Users, consuming DataPlan and not cannibalizing the last remain landline traffic opportunity. Besides the easy path as Apple already have XMPP based applications. Meaning:

Apple will release a native IM Application with VoIP Capability for IPhone/IPod and Apple products. It is very likely to be Jingle based.

Apple still rely on Carriers for IPhone massive distribution. Meaning:

From now on, Apple will do as much as possible to push 3G usage up. Including Adobe Flash Capabilities in order to increase audio/video streaming usage.

How to use your SIP Server with Nimbuzz Client

You can use Nimbuzz Client (Mobile or PC), which is a XMPP Jingle Client to connect to your SIP Provider or Personal SIP Server(Company Asterisk or iptel.org Services for instance). This proves how powerful and inter-operable Jingle is.

There are some requirements in order to use it:
* Your SIP Server/Provider MUST be connected to the Internet in a public IP.
* Your SIP Server/Provider MUST provide or act like a RTP Proxy. (Asterisk does that by default)
* Your Nimbuzz Client MUST be connected to the Internet, through a connection that doesn't block UDP/RTP Traffic and also allows TCP connections to port 5222, which will be used by the XMPP Connection.

How to setup with your own SIP Server(General):
1) Setup your SIP Server using your domain on port 5060. Setting up a SIP Proxy is optional.
2) Enable RTP Proxy, in order to guarantee audio both ways, even when users are behind NAT.
3) Create the users/passwords.
4) Make sure to configure your firewall correctly enabling UDP in/out traffic to Internet on port 5060 and in all the port range used by your RTP Proxy (usually 15000 to 65000).
5) Log on Nimbuzz Client using your Nimbuzz Account, go to SIP Settings and use the credentials that you created previously:
Username: user01@yourdomain.com
Password: pass
Proxy: (Leave it blank if you didn't setup it)
6) Done, you now should be able to place and receive calls in your Nimbuzz Client using your own SIP Server. (Refer to troubleshooting section in case of issues.)

How to setup with using SIP Provider(iptel.org in the example):
1) Log on Nimbuzz Client using your Nimbuzz Account, go to SIP Settings and use your SIP credentials that you created previously:
Username: userABC@iptel.org
Password: pass
Proxy: sip.iptel.org
2) Done, you now should be able to place and receive calls in your Nimbuzz Client using your SIP Provider. (Refer to troubleshooting section in case of issues.)

Troubleshooting:

* If you cannot even get registered to your SIP Server/Provider:
Double Check your credentials on Nimbuzz SIP Settings and also in your SIP Server Configuration.

* If you cannot get Calls completed:
Debug the SIP Signalling and also refer to your SIP Server Call Routing Configurations. (In Asterisk check for extensions.conf).
When using a SIP provider contact your provider for details of how to place calls(Number format, Valid Destinations, etc).

* If you cannot get Audio Both Ways:
Make sure your SIP Server/Provider has RTP Proxy enable. It is very likely that if you are experiencing this situation, you or the person you are calling to, is behind a NAT.
The interoperability of this service depends on RTP Proxy availability to guarantee both ways audio for users behind NAT.
Check you SIP Server Configuration or contact your SIP provider for further details and support.
Once the RTP Proxy is SIP Provider/Server responsibility.
Also make sure you are using an Internet connection that does NOT block UDP/RTP Traffic. This is a requirement. If using 3G check with your carrier about UDP/RTP restrictions.

I hope this article clarifies a little how to integrate to your SIP Services. If you already using/used another provider, please post comments about how you did it.

More on Jingle Relay Nodes

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 every buddy in your contact list could be a potential Node, and specially 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.

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.

What 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.

SIP Communicator is Coming Back To The Family

After putting on hold Jingle support for some time, Emil Ivov, the SIP Communicator Founder, told me today that they are adding Jingle again in early 2010. And it will also come fully packed with new and powerful features like ICE P2P communication and Video support!

He mentioned that SIP Communicator project have now a speed boost, as they graciously received funding from NLnet foundation, concerning the completion of the ice4j stack, Jingle telephony, brand new support for file transfer, and multi-party conference calls for SIP and Jingle/XMPP.



Some Super Cool Expected Features:
* Jingle ICE - Enabling P2P and server-less communication
* Jingle Video - Enable real time Video chat
* H264 Codec - Provides great video quality with regular bandwidth usage
* ZRTP - Secure and encrypted Audio/Video Streams

Stay Tuned for More Jingle Happy Days!

Why use Jingle?

Back in early 2006 I was working at Jive Software with Matt Tucker in a presentation for OSCON.
We were very excited as it was just after we published the very first Smack-Jingle version containing also the first implementation of Jingle ICE protocol in the world that was based on XSF Standards.

This presentation makes a parallel between SIP and Jingle and also exemplify why Jingle can solve P2P issues on SIP. The illustration of how ICE works is also awesome!

Check the presentation here:
Jingle-Cutting-Edge-Voip

Cheers Matt!

Mobile Voip over XMPP

Mobile Voip is one of the hottest trends now on new generation phones. But what's the most efficient way to do it?
In a time that calling is not the absolute main feature, but another in a combination of: Calling, Presence and Contacts. Telecom companies choose to go for SIP/SIMPLE IMS based systems.
Well it turns out that we all know that it exists but we never saw it live in a mobile in front of us. I mean, at least in a way that the battery survived more that 4 hours or so.

Analyzing IMS specs you will notice that it is nothing but a lot of work around in order to let SIP do what he wasn't meant to do from the beginning. And another question that pops up is interoperability, as the specs are quite open to interpretation in several aspects.
Work-arounds like XCaps which is just a web service but behind a cool name and lack of a defined and more strict way for contact management are leading IMS implementations through a long off-road track. A race that they don't wanna quit as they spent billions of dollars acquiring already obsolete plataforms.

In the other hand XMPP have shown that Presence and Contact List are very simple doable things and that this can inter-operate successfully among different networks, devices and even protocols.
And now it has another advantage, which is the mobile Voip ability. Already deployed live for millions of users on Nimbuzz Network.
One of the coolest features of Jingle it is his almost natural way to deal with P2P negotiations, which leads to much better and reliable negotiation of media specially when compared to SIP.
XMPP Jingle demystified Voip showing the real simplicity behind it, removing all the obfuscated logics behind SIP tags, branchs, CSeqs and transactions. (Check MiniJingle as an example)

All this packed together can guarantee that whatever the market wants in next months and years, XMPP is way ahead when dealing with extensibility, simplicity and interoperability.
Which are the strongest tendencies for near future communication.

Jingle for dummies

I found this old diagram from 2004, describing a easy way to use ICE on Jingle. It also describes in a very simplistic way how it works.
Main differences from regular ICE, are that in the suggested flow, there is no need for STUN connectivity check, everything is done by an ECHO service that justs replies every UDP packet to the sender.
The relay candidates are also not retrieved from a TURN Server, but from an XMPP Service that provide ready to use relay candidates.
Skipping STUN Conn-Check and TURN complexity.



This proposal will be used as an inspiration for Jingle Super Nodes XEP.

Jingle on Streets

It is really cool to now how many new Jingle implementers.
In Jingle Thingle 2009 I noticed that the big SIP Companies were not only just present in the meeting, but also demonstrating and testing their Jingle implementations.

We know that Google is being using Jingle on GTalk to provide Voice and File Transfers for several years, but what we don't know or maybe we didn't summarize is:
* AOL Messaging migrate to XMPP.
* Nimbuzz migrate several millions of Mobile Clients from SIP to Jingle.
* Twitter solved their scalability problems with XMPP.
* CISCO the most important SIP vendor, bought Jabber.
* OpenSER has a XMPP interoperability module.
* Asterisk has now embed support for Jingle.
* YATE has the first real full featured PBX using Jingle.
* Nokia is planning to launch a smart phone with XMPP/Jingle embeded support.

So it really seems like the simple facts that in Jingle you can negotiate several transport types, several contents in the same session opened the minds of these SIP companies to have a look on it. And the fact of Jingle in real use cases is more reliable and much easier to
implement than SIP, consolidating the protocol as the internet age multimedia signalling negotiating protocol.

Follow Jingle specification evolutions at:

XEP-0166 - Jingle
XEP-0167 - Jingle RTP Sessions
XEP-0176 - Jingle ICE-UDP Transport Method
XEP-0177 - Jingle Raw UDP Transport Method
XEP-0234 - Jingle File Transfer
XEP-0251 - Jingle Session Transfer