The Good, the Bad and the Ugly

Skype have closed one more third-party this week. Nimbuzz announced that, like Fring, they were forced by Skype to stop supporting it in their Clients.
It is even more evident now, that the good signs about Skype Openness we saw beginning last year are completely flushed now, probably due their eagerness of pursuing an IPO and new management.
Although, what they did not count is the bad impact in their own user base and public image effects of such blocks. It proves once more that companies should not rely on Skype as something solid to build product features. Not only that, according to Skype, third-party MUST not build product features based on their services.
Skype also claim they have an API. Really? Not exactly, they have a Client SDK/API. And why it matters, is that if a client or device want to make use of it, they need to have exclusive granted privileges for a black box piece of software to be embedded and shipped within your product. Yes, if you want to support Skype, you need to build your product on top of that, and also make sure the product is exclusively Skype friendly. If that wasn't enough they also say that they do not guarantee for how long the piece of software will be valid.
Skype wants to do what AOL did, trying to force their users to install their Software and only use their own Browser/Client to access Internet. 
The Bad.


SIP is widely adopted worldwide specially among technical people, geeks and behind the curtains, even used as base landlines telephony like in Netherlands.

• The interoperability is something achievable theoretically, meaning that several different SIP Clients can talk to each other
• SIP release the Telecom from the "Dark Ages" to the "Modern Times", showing that Telephony could be done using IP and good software
• Vast majority of Communication equipments and platforms have support for it.
• It enabled the possibility to create huge portfolios of Value aggregated Services based on Legacy Telecom Centrals
• It is responsible for the cheap VoIP as we know it
• Most terminations that Skype buys, are provided via SIP
• Estimated numbers of SIP Providers worldwide is bigger than 50.000
• SIP Providers can sell termination minutes not only to end users, but also to other Providers

Although there are some not pretty facts about SIP:

• SIP Protocol is not as practical and simple as it should be by 2010
• SIP is not extensible, the current attempt of extending it (3GPP) is failing badly, taking more than 10 years of pure specifications, without any success to reach mass market. The current result is a HUGE stack of workarounds badly described and full of contradictions
• SIP Calling is great and almost straight-forward, but Messaging, Presence, Contacts and Extended Services are way too complex for current Market Status
• SIP is always backed by big corporations that tries to mystify it, trying as much as possible to postpone the life-cycle of the protocol.
• The current Market needs and demands extra features than only Calling. There is no such thing as a mass market SIP based service with extensive features like: Presence, Contacts, Whiteboard, Video, File Sharing etc.
• Apple Facetime is a frustrated attempt to use SIP for extended Video Call service ( Why frustrated? A service that works based on "trial-error" and does not have interoperability support in 2010, is a failure by default ). Apple end up implementing a half-SIP, half-XMPP, half-STUN solution. Which is completely closed for interoperability. It claims to implement it ALL, and supports NONE.
• The complexity of the protocol makes it hard and restricted to highly specialized developers, which have their jobs lifetime guaranteed, but decreases the potential mass adoption of the protocol. The Ugly. 

Google Call over Jingle with a SIP Gateway on their XMPP Server

I just confirmed in my Wireshark that Google Call on Gmail uses exactly what I recommended in a previous post back in 2009 when they acquired Gizmo5. And YES, it's Jingle!
Their wise choice of having a portable and extensive protocol(XMPP) as the bus and having specialized technologies like SIP, will grant them a flexibility never seen before on platform and device portability.
Their master plan is to be able to delivery mass market a cheap and alternative method for calling the old fashioned telephone numbers. And sure they have the right platform and tools in their hands:

Android

Almost all Android phones have with GTalk application pre-installed, which already runs a nice XMPP Client, besides other great alternatives like Nimbuzz.

Now imagine what Google can bring to the market without much effort due their choice of using Jingle extension of XMPP for their service? Google Call support on Android phones. That is the key and reason behind this service.



Overview Diagram:

Skype API Available for Beta

This story was commented in this blog several times. And so far nothing significant really happened. Why Skype keep trying to fill the gaps of its solution on leafs and not in the root of the problem?

Skype understand the importance of standing as a Service provider and no longer a simple Client provider. Something that cannot be accomplished without massive adoption in different devices, platforms and software.
Although we can reflect once again about the approach that has being used by them.

• Skype API is something that will work only for Skype Network. The flexibility of the service goes immediately to the ground. So if you implement it, make sure you know you won't be to re-use the code somewhere else.
• They are claiming some openness based on an old client side SDK API model. Which dismiss all potential of the currently heavily deployed solutions like SIP, which is everywhere, from Servers, Platforms, Hardware, Gateways etc... I'm not a SIP fan, although strategically would be wiser for them.
• Skype shares bandwidth without user concerns. Would you be up to risk embedding such black box into your own application or Product?
• Most IMPORTANT! Latest Skype IPhone client mention about not being free anymore from certain date. So if you are looking forward to implement Skype, bare in mind they can actually start charging for their services or clients at some point, which may turn your "FREE" application useless.

I'm glad they are moving forward towards Openness, but I still think they have a long way until having it done properly.

Apparently they may need to speed it up since Apple announced that Facetime on IPhone 4g, will use Open Standards including SIP, STUN and ICE. Which is a mature P2P technology heavily used and deployed and of course the same as we are using on XMPP Jingle Specifications.
Open Standard P2P already won this 'battle' which Skype still persists to fight.

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!

Google AppEngine Limiting Telephony Application

If you sign up for a Google App Engine account you will have the following statement in the Terms of Service:

"You agree not to use the XMPP API to operate or to enable any telecommunications service or in connection with any applications that allow users to place calls to or receive calls from any public switched telephone network."

Google basically is blocking any usage of XMPP to communicate with telephony networks. In practical terms is limiting any usage of XMPP API for a SIP/Jingle or H323/Jingle Gateway, etc...

Although it is not that bad, once it implicit allows the usage for Pure Internet Calling purposes. It remind me about the all discussion around FCC, on Google "fighting" with Apple to get his Application into IPhone AppStore.
As I mentioned before, all this overrated discussion is possibly part of a Marketing Plan to Advertise the Google Voice Service, as it showed itself a big failure so far.
Once Google is following exactly the same bounds of restrictions as Apple in the App Engine.

This post does not have as intention, judge the Apple or Google for their games and strategies. But it has the purpose of warning and public awareness about Voice Over IP Market, now played by new powerful players.

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.

Nimbuzz Jingle/SIP Gateway

Nimbuzz recently announced that they converted all their clients to Jingle.
Considering the amount of supported Calling Gateways by Nimbuzz, it also means that they have not only a SIP/Jingle Gateway but also: Jingle/Skype, Jingle/MSN, Jingle/Yahoo, Jingle/Flash, Jingle/...

It is one more time proven that Internet Users no more need several applications running in their computers or mobile devices in order to chat with other User in different networks like MSN, Skype, Yahoo, and all the other closed networks.

Looks like Nimbuzz is one step ahead on protocol unification when talking about single stack network solutions, doing ALL other networks did using several protocols and stacks, using only ONE big Joker, XMPP.

And XMPP proves again to be a perfect ecosystem for integration, interoperability, flexibility and extensibility.

I'm very excited about what going to happen when interoperability break through Instant Messaging, Social Networks and Microblogs. In my very personal opinion, whoever is ahead will win the race, as timing is and always were everything on Internet.

Quote:
"How big will the Cloud composed by: GTalk, Twitter, Nimbuzz, Facebook, AOL, GoogleWaves and all other players that already announced the convertion?"

Single Stack or Die

The current Internet is a real Babylon. A huge number of new protocols, languages, scripts, etc... Are being created every year.
The consequence of that is 30% of current internet development efforts is to be compatible and updated with most of them.

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

SIP Providers P2P Try-out Fails

Some SIP providers and server developers thinks that it is possible to guess if a user can send/receive RTP traffic direct in his IP if the SIP Signaling network is public IP.
WRONG!

The correct way to do this is using a connectivity check algorithm (STUN, ECHO, etc...) based on the UDP Channel that you may use to send/receive the streaming.

SIP Providers, stop doing guesses about User Agents NAT description based on the signaling channel.
This kills the interoperability of your SIP Services.