Standard Jingle on Google

After many year after its creation and early adoption, Google finally announced the switch from their own Jingle variant to the Standard Jingle Version created, approved and maintained by XMPP Foundation.
This comes in the right moment after the previously GIPS Media Company now owned by Google itself, announced the OpenSource WebRTC Project. Which intends to provide multimedia and realtime communication capabilities to Browser like Firefox, Chrome, Opera, etc...

Google intend to bring rich communication also to their other browser products like Orkut, iGoogle and even adSense with Ads that could place direct calls to the announcers.

This will enabled direct compatibility to the already know Jingle Clients Jitsi, OneTeam, Pidgin and others. The amplifier of this announcement is that soon we may be seeing native Jingle Support on Android OS, which will make a great and powerful opposition to Skype Mobile Market.

Nimbuzz was the very first Mobile Company to runs their entirely Voice Services over Jingle since 2007. They would have immediate benefit if they were allowing XMPP Federation, which currently is blocked. For now they support GTalk Calls but requires the user to have a Google account registered (which is not a big problem, but not as handy as it could be).

Hopefully Jingle Nodes will also be adopted soon as the default mechanism for Relay Sharing Discovering for Jingle. Stay tuned for more good news. 

ISP and Operators Take Another Hit on VoIP Blocking

"In view of those characteristics, Advocate General Cruz Villalón considers that the installation of that filtering and blocking system is a restriction on the right to respect for the privacy of communications and the right to protection of personal data, both of which are rights protected under the Charter of Fundamental Rights. By the same token, the deployment of such a system would restrict freedom of information, which is also protected by the Charter of Fundamental Rights."

The text above was extracted from the public document: http://curia.europa.eu/jcms/upload/docs/application/pdf/2011-04/cp110037en.pdf

This also mean that VoIP filtering applied by Vodafone and other operators in Europe, is illegal.

The more stupid Operators blocks VoIP more the market drives to an IM based communication, which they cannot block. They are the responsible for sinking their own business due their greed and incapacity of adapting to a new communication era. Innovate or fade.

Operators that blocks, filter or censor rich communication like VoIP and Streaming, they have a much shorter lifespan than you might think.

Skype Down, the Closed P2P Issue

You may be wondering why Skype is Down if it is a P2P network. That is not hard to answer, it is a closed P2P Network which the Fallback Servers and Main Nodes are entirely dependent on Skype itself. So if something goes wrong with them, there is no real fallback like you would have in a distributed regular P2P network like BitTorrent, UseNet or Jingle Nodes.
The main issue is that only Users from within Skype can share the Routes, but not users on different Networks and Domains like you can do with Jingle Nodes.
Skype official response was that they were creating "mega-super-nodes"? I don't know what does that mean, but I'm sure it still have same single point of failure of the current system. Until Skype don't come up with a Federated System, where providers, services and users can share Routes, they will always suffer from outages. And of course the most affected are the users and business that depends directly on them. Nearly 20 Million Users are suffering from the outage.

Open Standard Free alternatives that can provide reliability and superior quality:

Clients with Jingle Nodes Support:
* Nimbuzz (Mobile and Desktop)
* SIP Communicator (Jitsi) (Desktop)
* OneTeam (Desktop)

Services with Jingle Nodes Support:
* Nimbuzz (Free)
* Talkr.im (Free)

Don't wait for Skype to come up with "hyper-ultra-mega-super-nodes" to migrate to reliable software.

Google Acquires GIPS

Today was announce the conclusion of the buying process of GIPS by Google.
What does that mean?

Here are some hints:

• HTML5 predicts lots of extra features that needs to be provided by the browser. Which means that they are really looking forward to remove the crappy dependency of Adobe Flash, which currently is required for 99% of all Browser Based Voice Over IP Applications. Which besides the Adobe Plugin requirement, also requires traffic and negotiation passing through Adobe Media Servers... (Adobe shall get what they deserved for their manipulation, never supporting Standard RTP Streams)
• GIPS was the best in the market "Quality Wise". They always offered top quality codecs and APIs to main Real Time Communication Companies from Desktop Skype to Mobile Nimbuzz.
• Goggle already used not only GIPS software but also GIPS iLBC codec. Which is a great quality for low bandwidth Internet Communication with extra awesome packet loss support.

In resume GIPS was a very great choice!

Semi-Fiction Fact:

Google looked for some solution and buying the whole company was the easiest and quickest way to get it done...

Mobile VoIP is now Illegal in Egypt

The Government of Egypt made mobile VoIP officially illegal this week.
It would even be acceptable if it was for all VoIP, but not. VoIP still acceptable if provided by the State Hold Telecom Companies of Egypt.
Main blocks includes Skype and known international SIP providers. Although I'm not the biggest fan of Skype closed protocol, I consider this completely unfair and offensive against Skype.

More than a political problem for Egypt citizens this is a crime against their freedom.

It is more than clear that the only reason is money, as State Telecoms were almost bankrupt end of last year. This is a criminal behavior aiming the State and not Citizens that should be condemned by other countries as well.

Jingle fortunately still not blocked, so if you blocked on Egypt, feel free to re-enforce mobile VoIP usage over Jingle.

Suggested Clients:

• Nimbuzz on Symbian, Windows Mobile, Android and IPhone
• Native GTalk Client for Maemo

IPhone Over 3G

I proudly announce that we have the first Jingle based VoIP Application on IPhone that supports Calling Over 3G!
This application is Nimbuzz, a fully featured Client that supports VoIP via Nimbuzz Contacts, NimbuzzOut, Skype, GTalk, Yahoo, MSN and it is also a SIP Client. It is the Mobile VoIP Freedom Gadget.
The battry consumption really rocks if compared with regular SIP Clients, plus the benefit to be able to receive and place calls, through different methods without any extra battery consumption.
The Application is Free on Apple AppStore and it is also available with VoIP support for Symbian, Android and Windows Mobile.

It uses XMPP and Jingle as the main bus for their services, enabling also the usage of your Nimbuzz account through other Clients like Adium, Pidgin, PSI, Empathy, Pandion, etc...

Gizmo5 is Now Part of Google's Family

+

Yesterday Google announced the purchase of Gizmo5, a SIP Service provider, that is being around for quite sometime. And I already received some emails questioning about Jingle's future in Google, as Gizmo is a fully SIP based services. So here comes the summary:

Why Gizmo5 and not Skype or other VoIP Service Providers?

• Gizmo uses SIP, which is an Open Standard. Buying anything closed and proprietary would cost Google a lot of money and huge drawback on integrations.
• Gizmo is a much more open and known for its interoperability with other SIP Providers. Skype has absolute ZERO interoperability and it is mainly a closed P2P service, which Google already solved in a way more elegant way.
• Main focus on calling from and to PSTN. Last thing it needs is another P2P Service.

What happens with Jingle on GTalk now?

Nothing! Google needs the flexibility that it offers and specially the natural integration with XMPP Wave Services. I don't see Google releasing Wave Services over SIP for now.
Jingle is by far the best solution for Internet Calling, and this is not a fact only mentioned by XMPP fans, but also by SIP Developers (Asterisk, SER, YATE, etc...).

Will GTalk support SIP now?
That is a tricky question, as there are two very close solutions, with pros and cons that I can't judge from Google's perspective what is better. Basically Google can solve it through:

1. Jingle/SIP Gateway, XMPP has a very reliable way to interconnect legacy gateways. Nimbuzz for instance already have all its SIP Services working through their XMPP Jingle Clients. They support third party SIP Providers and recently they also have released an embedded solution for calling to PSTN called NimbuzzOut.
2. Include a SIP Stack in Google Talk Clients. Which is not big deal. As we are plenty of SIP client side solutions and it is very easy to embed.

The point here is that I personally don't think Goggle is willing to implement SIP on  their widgets of web chat voice/video solutions like we have already on GMail. Making Jingle/SIP a necessity anyhow if they also want to allow their users place calls to PSTN also from a Website Flash Widget.

IMHO Google will probably go for a Jingle/SIP gateway, solution that I quite like for two reasons:
I already build such solution, and it works incredibly good! And has great scalability as well.
I also worked last year in the draft specification document that describes the integration Jingle/SIP Interoperability in Media Sessions.
If Google allows me to suggest: Go for Jingle!

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.

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.