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.

Movies Bot and Bots website

movies@xmppguru.appspotchat.com

If sometimes you are at a video rent store, or in a torrent site searching for something to watch, and you often run out of convict opinion this is your Bot. Just send a message containing the name of the movie, and it will reply with a recommendation. 

I'm sure the Movies Bot can save you some money and time regarding "trash" movies, which by the way are big majority nowadays specially in Hollywood.

Of course you won't always agree about the opinion, but I'm pretty sure it will give you wise and precise alerts before renting/downloading really BAD movies!

Just give it a try and let us know the reliability of the answers.

NEWS!!!

Now you can follow the xmppguru and its extensions, go to http://xmppguru.appspot.com and check out in realtime latest questions and answers from other users.

quotes@xmppguru.appspotchat.com - a Self-Help Bot (or Not)

quotes@xmppguru.appspotchat.com

Yet Another XMPP Bot! This time it is meant for nice quotes that should increase your "anymus" at work, in a boring day or in both at the same time as usual. After checking that more than 25% of all messages to xmppguru@appspot.com where about personal problems and assistance requests, I decided to build something to help those poor XMPP users.
So basically the recommended usage is:

1. Swear to the Bot! Use bad words freely. He always understand you... (This is a MUST, if you don't say anything he won't help you)
2. Get a nice quote back that eventually will help you with motivation or pushes.

You can use the xmppguru extension by simple adding it to your GTalk's / Jabber Contacts: quotes@xmppguru.appspotchat.com

Examples of general usage
To receive a quote, simple express your feeling.

Chat Message: I hate this rainy day!!! Screw it!
quotes@xmppguru.appspot.com: "Sometimes water is better than snow..." - Someone from somewhere

Chat Message: what the f*** you are not helping shi*** bot!
zaptin@xmppguru.appspot.com: "" - "Honest disagreement is often a good sign of progress." - Gandhi

It is not scientifically proved, but it might help. At least, in the worst case, will be an always online friend that is always willing to hear your complains. Always there in your roster.

URL Shortener XMPP Bot

zaptin@xmppguru.appspotchat.com

XMPP Provides easy and clean ways to build XMPP Bots, as I showed on the previous post, we can use Google AppEngine to create 24h online, zero-maintenance Bots. Yes, I don't need to host this. Google is doing the job for now, for free, let it be.

You can use the xmppguru extension to Short URL simply add it to your GTalk's / Jabber Contacts: zaptin@xmppguru.appspotchat.com

Examples of general usage
To request a Short Version of your URL just send a message containing the URL.

Chat Message: http://pixagle.appspot.com
zaptin@xmppguru.appspot.com: http://zapt.in/D5 -> http://pixagle.appspot.com

Chat Message: xmppjingle.org
zaptin@xmppguru.appspot.com: http://zapt.in/D1 -> http://xmppjingle.org

This is quite handy, avoiding all the hassle to visit one of the other URL Shorteners just to have a smaller URL.

XMPP Bots - XMPPGuru

xmppguru@appspot.com

XMPP Provides easy and clean ways to build XMPP Bots, as I showed on the previous post, we can use Google AppEngine to create 24h online, zero-maintenance Bots.


One interesting Bot is a Guru One, the main objective of this Bot is to clarify topics, answer general knowledge questions and retrieve hints for general opinion.
You can add it to your GTalk's / Jabber Contacts: xmppguru@appspot.com


Examples of general knowledge:
Question: What is Aerosmith?
xmppguru: Aerosmith is an American hard rock band, sometimes referred to as "The Bad Boys from Boston" and "America's Greatest Rock and Roll Band".

Question: What is an atomic bomb?
xmppguru: nuclear weapon: an explosive device whose destructive power is due to the uncontrollable release of energy from the fission of heavy nuclei, usually uranium-235 or plutonium-239, by neutrons sustaining a rapid chain reaction

Question:  Who invented the harpoon?
xmppguru: Endangered Species question: Who invented the harpoon cannon? Sven (or Svend) Foyn (1809-1894) was a whaler born in Tønsberg in southeast Norway. In 1856, he invented the bow ... 

Examples of general opinion:

Question: What is a good song?

xmppguru: What is a good song to "give" someone who you are …

Question: Do you trust god?

xmppguru: The Bible tells us to have faith: (Hebrews 11:6 NIV) And without faith it is impossible to please God, because anyone who comes to him must believe that he exists and that he ...

The Bot is not meant to have conscience neither deep lexical interpretation, the goal is to answer your question when possible, something directly with a straight answer, but something also vague hints.

For unknown answers the principe is the same of Horoscope, but in a scientific way. 

the best way of discovering how it works, purpose and functionality is by testing it.

Sometimes you will be surprised even asking by your full name. In the same way you will be surprised by crappy answers. Enjoy!

Google App Engine XMPP Services Example

Google App Engine released the XMPP Services a while ago. The service started very basic and bad, but since then, it is improving a lot and have potential to be really worthy to build XMPP Services over it.
Unfortunately currently you might only be able to write bots. Which is not that bad specially for developers that are starting with XMPP and App Engine.

The documentation is not that good so far, but it was enough to create an EchoBot Demo App, you can download the full source here.
To use it, just explode the folder, make sure you have Google App Engine SDK configured, set your application ID, and deploy.
I strongly recommend to use Eclipse AppEngine Plugin for those tasks.

Quick Tutorial

Receiving Messages are handled by your application like an HTTP Post Request:

@SuppressWarnings("serial")

public class XmppbotServlet extends HttpServlet {

public void doPost(HttpServletRequest req, HttpServletResponse res)

throws IOException {

Parsing Received Messages is piece of cake. AppEngine API is handy in that sense:

XMPPService xmpp = XMPPServiceFactory.getXMPPService();

        Message message = xmpp.parseMessage(req);

Creating a Response Message is also very simple:

JID fromJid = message.getFromJid();

String body = message.getBody();

// Create an Echo Message

Message response = new MessageBuilder().withMessageType(

message.getMessageType()).withBody(body)

.withRecipientJids(fromJid).build();

Now we send it back, without any specialist XMPP Knowledge required.

boolean messageSent = false;

SendResponse status = xmpp.sendMessage(response);

messageSent = (status.getStatusMap().get(fromJid) == SendResponse.Status.SUCCESS);

if (!messageSent) {

// An Error Occurred

}

Now you can create an XMPP Bot with just a few line of simple Java code.

Remarks:

• Your Bot will auto accept every XMPP contact add request, which is quite handy too. To test your Bot, just open your XMPP Account in your preferred Client. And add the contact: YourAppName@appspotchat.com
• It will auto-accept your request, and if your service is running, it will be shown as available.
• You can also use aliases like: Whatever@YourAppName.appspotchat.com

Erlang Version of Jingle Nodes Services is Working!

We are moving very fast with the Erlang version of the Jingle Nodes Services API, after 2 weeks of finishing the Pure Java Version, with great help from contributors, we have a working Erlang Version.
I invite you to check the code at: Jingle Nodes Source
It is based on the excellent exmpp library which besides being rich featured, is also pretty straight forward to use and reliable.

The current version can provide fully working relay channels, but still lacking some features:

• Detect Inactive Channels
• Purge Inactive Channels
• Tracker Services Provider

And indeed we have some bugs to be catch.

Contributions are really welcome!


How to Contribute?
Check the current opened issues: Jingle Node Issues
Send me an email with your intentions or if you wanna go one step ahead, patches are also accepted.

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!

Media don't stop trying to criminalize VoIP

It seems that media don't stop trying to criminalize VoIP. The most manipulated newspaper of the world,  New York Times,  tried again to make using VoIP looks like a crime or a terrorist behavior.

We from the OpenSource and Open Communications communities want to expose our feelings with a short sentence: "Shut Up!".

We are completely tired of your excuses for market manipulation in favor of Carriers Monopoly.

Ignored Facts:

• Basically you can by a prepaid SIM Card without ANY identification and place calls worldwide for  less then 10 Dollars!
• Mobile and Landline Calls can be encrypted with simple software installed in your device.

The only reason that would make criminals use VoIP providers over pre-paid mobile is the price!

If they are right, lets enumerate all the elements related to a crime:

• Criminals usually eat fast-food,  as they don't have time to cook at home. Making MC Donald's the food supplier for criminals.
• Criminals uses Ford and GM Cars for Bomb Cars. Ford and GM is manufacturing bombs with 4 wheels.
• Criminals use sunglasses to disguise themselves, making RayBan a "camouflage" provider.
• Criminals uses Windows, as they usually use Cyber Cafes computers equipped with this "criminal friendly" Operational System.
• Criminals buys ammunition and weapons from the same manufactures that provides them to the police and military. WAIT THIS ONE IS NOT A JOKE! 

Where are the attacks to weapon and ammo manufactures in the News?

Jingle Nodes in Practice - Sea Beyond

Jingle Nodes will have a experimenting session and a presentation on Sea Beyond, which is a new technical event that explores the future of real-time communication technology. It is organized by ProcessOne, an authority in XMPP and real-time communication software.


During the development sandbox portion of the event, we will have coding sessions of:

• Adding Jingle Nodes Services to an ejabberd server
• Placing Jingle Calls using the created service

For the presentation session, I will be showing what is XMPP Jingle and how it is dropping the Voice Over IP complexity, making XMPP Multi-Media Sessions a reality.


The first Sea Beyond event will take place on December 17, 2009 in Paris, France, from 9:30. The formal program will conclude at 19:00, but will be followed by an opportunity to share a drink and talk with other guests and speakers.

Yet About Your Freedom

The hype of having everything through mashup services, has a big impact in your freedom. Which most of the time is overwhelmed by Internet mass.

Using the "great" argument of not having to setup or create an account, sounds very nice in a first analysis, as it might seen that you are not getting another service to be attached to.
Well, it turns out that this is not true, first because you are probably exposing the information and account settings from the previous service to the new server, the only difference is that you don't need to do that manually.
But what really makes it really worst, is the attachment factor, that is created on interdependent services like applications inside facebook, orkut, twitter etc...
Once you are using a service that depends and requires other, and this service is really important for you, it attaches you extending you level of dependency through the overhead of being stuck sometimes with services that you no longer need, or never needed.

Think before getting attached to interdependent services. Make also sure the level of account exposure is really defined in a proper and clear way, as most of these integrations are not clear at all about account exposure among different services.

XMPP can support your freedom by exposing all these services through a protocol, which does the integration in a open and defined method, making you able to choose and define dependencies and exposure of your data.
In that sense you might even start your services through Google Wave, and later decide to stop and provide through your own XMPP network. Or even having Intranet services integrated in a safe and limited network.

Powering your freedom!

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.

Java and Jingle Nodes

For a couple of months, I was wondering if Java would be suitable to provide relay services, in case of a Java Jingle Client wanted to enable it.

Of course Java is perfectly suitable for using a Relay Service, no doubt about the trivial statement. But is Java suitable to be used on providing it?

Researching on Internet I found nothing but rumors and assumptions. So I decided to try it myself. I agreed with a Jingle Node Project Contributor to provide a Java Relay Channel Class just like we have the C++ version using Boost. And I would provide the UnitTest Cases in order to measure added latency. This weekend with the code in our hands we ran the tests.

All the tests were conducted using loopback interface in order to prevent real network to influence in the results.

You can find the Test Case in Jingle Nodes Repository:

RelayChannelTest.java

Results running 10 simultaneous channels processing and relaying 30 packets, the overall average values after 100 tests, for Latency was:

• Max: 52ms
• Min: 7ms
• Avg: 10.0ms

Surprisingly the results are very satisfactory for Client Side Relaying. And I have to admit that the Java Code is by far more elegant and simple.

This means that SIP Communicator is not only a good candidate for Jingle Nodes usage, but also a great candidate to also provide Jingle Nodes relaying features.

For comparison criteria I created an extra test case based on a single Relay Channel using a C++ and a Java Channel measuring the added latency by using a Relay, instead of direct traffic. The results were the following:

C++/Boost-ASIO Latency:

Max: 16ms, Min: 2ms, Avg: 3.0ms

Java NIO Latency:

Max: 90ms, Min: 2ms, Avg: 5.0ms

I strongly encourage Java and C++ Developers to do a try out and spicy the discussion.

Skype submission of SILK Speech Code to IETF

SILK is a speech codec for real-time, packet-based voice communications.  Targeting a diverse range of operating environments, SILK provides scalability in several dimensions.  Four different sampling frequencies are supported for encoding the audio input signal. Adaptation to network characteristics is provided through control of bitrate, packet rate, packet loss resilience and use of discontinuous transmission (DTX).  And several different complexity levels let SILK take advantage of available processing power without relying on it.  Each of these properties can be adjusted during operation of the codec on a frame-by-frame basis.
This is description of SILK in its IETF draft, which looks promising. Although that doesn't change much the closed behavior of Skype. Their main intention behind it is actually start being effectively used inside companies and being available in a wider range of supported devices.  
It is very early stage to say if Skype is in fact moving towards open standards. Besides IMHO, that is really not big deal, as being open won't bring that many benefits to the open standards and open source community. The biggest openness step Skype still needs to take is about the cryptography as the P2P topology still close but is actually a simpler solution than humans might think. Jingle Nodes is aiming for same results and honestly I truly believe we will have similar approach in a simpler, safer and more balanced way by July 2010 when the first prototype phase shall be finished.


Congratulations Skype, you are now one step away from the dark closed side.

Jingle Roundup - Accomplished So Far

XMPP completed 10 years in 2009 achieving dazzling results, which consolidates Jingle ground in terms of the main requirement.
But what Jingle by itself accomplished so far? What lies in Jingle's Reality Horizon? What is the biggest negligence ?

Lets enumerate the accomplishment followed by further explanations why it succeed:


Google Talk is using Jingle from its beginning. Absolute successful decision in scalability and simplicity aspects:

• There was no better solution for Google Talk Voice Capabilities then using Jingle as it makes use of the already consolidated XMPP Protocol and Transport. Which combined with ICE capabilities (which are indeed more suitable for Jingle than to SIP), allowed Google to have a mass service deployed with optimal reliability, minimal resources and tiny complexity.
• The easy interoperability with Google Mail was certainly another great example of Jingle consolidation in Google's Real Time Internet Business and Services.

"Imagine deploying in a short period a service for millions of users, with quality and reliability, without P2P support and using a secondary protocol stack/transport also requiring extra set of Servers and Services?
Google knew from the beginning that having SIP Stack running together with an XMPP Stack was indeed an overhead and unpractical for future browser and mobile based applications." - Personal Quote

Nimbuzz started their evolution to Jingle in December 2008, due trivial reasons. As mainly a mobile application, having dual stack clients was completely unpractical:

• Battery consumption is too high to maintain several opened sockets and threads.
• Multi Platform Support requires minimalistic solutions in order to keep up to date with Manufactures Releases. Usually several phone models are released every month. Embedding a SIP Stack is way more complex that extending an existing XMPP implementation to support Jingle. Development cycles should be minimized and Jingle proved so far to be the simplest and most efficient way to provide Internet Calling Services.
• As a mobility enabler service, it is very likely that the Internet connectivity will be a wireless connection(3G, public WIFI Hotspots, etc...). Meaning that packet loss and NAT are almost constants. Using SIP via UDP requires intense KeepAlive and Packet retries is unpractical for bandwidth and battery consumption.
• Nimbuzz application proved that SIP is interoperable via XMPP Gateway, meaning that legacy integration is doable and can enable Jingle Only Clients to support SIP Registration and Both Ways Calling. This wasn't achieved so far for SIP Server having a Jingle gateway like asterisk. As it only supports one way calling and no registration.

When talking about features build using Jingle, Coccinella has by far the biggest set of it. And as the most successful user of Jingle Extensibility this client has a lot to tell:

• Communicate with Whiteboard, sketch to explain your words. Collaborate on diagrams. Enter mathematical formulas like on paper. Draw together for fun. You decide how you visually communicate.
• Communicate with Voice, handsfree communication for people who love multitasking. Discuss while working together in the whiteboard. Make a call while working on a document. It is all possible.

So in summary, what Jingle really accomplished so far?

• Jingle is a scalable solution with outstanding and graceful support for P2P. Google Talk proved it.
• Jingle makes much more sense in mobile platform than SIP or legacy protocols. Nimbuzz demonstrated it.
• Jingle extensibility is not only theory, in practice is much easier to have collaborative multimedia sessions over Jingle than in legacy protocols. Specially due the possibility to have that done via P2P. Coccinella assured it.
• Simplicity and accuracy, in the sense of implementations. Most Jingle client and services are built with much less complexity than ANY other protocol. All clients proved it.

Current Specifications:
XEP-0166: Jingle

XEP-0167: Jingle RTP Sessions] (formerly: Jingle Audio Content Description Format)
XEP-0176: Jingle ICE Transport

XEP-0177: Jingle Raw UDP Transport
XEP-0179: Jingle IAX Transport Method
XEP-0181: Jingle DTMF
XEP-0234: Jingle File Transfer
XEP-0251: Jingle Session Transfer
XEP-0262: Use of ZRTP in Jingle RTP Sessions

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.

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.

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!

Adobe goes P2P - XMPP and FMS

After Google requirement of having a P2P method to provide Voice and Video on GMail, Adobe finally put some effort and released a very decent support for P2P on Flash Player 10.
It is called Stratus and you can also you it as we do in UDP-ICE, we can have several alternative and fall-back methods, including RTMP as a last resort.

Adobe was probably holding this at all costs as they were afraid on the reduction of amount of FMS license sales. But it turns out that at some point they needed to open it, so they could get bigger market share, as not everybody can afford 100% of Audio/Video proxied on their networks.
This also means that every company now can have their own Voip Services and also full featured Video Conference Platforms running internally using only an ejabberd and FMS on server side and browser based application on client side.

I tested myself the UDP based traffic, and the quality as expect actually much better with compared with the Slow and Lagged RTMP TCP based solution, specially in long distance and high latency networks.



Check it out at:
http://labs.adobe.com/technologies/stratus/

Looks like now we have more consistent reasons to have kind of Flash RTMFP Transport in Jingle.
You can also see a very cool tutorial on this link (Flash P2P Tutorial).

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!

Jingle Nodes Preview

I've been working on Jingle Nodes XEP from the past 3 months. But as I usually do, I implement it beforehand so I can make sure I don't release any sci-fi specification.
So far the results are satisfactory and sounds promising even though the implementation is at very early stage.
I will post below some nice features to be covered and a RTP Diagram showing some use cases:

Main Goal
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.

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

Diagram


Jingle Client Developers with interest in helping creating prototype or being early adopters are welcome. Leave a comment and you will be contacted.

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.

Friday's Top 5 - Must Die Applications

Big companies are always trying to overuse their versions, dragging them to the limit of "durability" seeking for extra profit. But just like real waste, this is not healthy for software ecosystem.
We all are annoyed by software waste, specially that ones that drag us in order to keep backward compatibility.
Something that big companies also don't tell is that backward compatibility is always responsible for at least 25% of overall costs of a new version. So now guess who pays for that? YOU!
So this Friday's Top 5 is dedicated to all crap waste software and technology that stays among us.

5. RealNetworks Real Player
"In order for your browser to display the following paragraph this site must download new software; please wait. Sorry, the requested codec was not found. Please upgrade your system."
I still don't believe when some people say that they saw a web site using it. The lowest usability, compatibility and flexibility you can achieve in a media player.
Besides the original format never took off specially due special requirements and slowness.

4. Norton Uninstall Tools
Why would you want an application to uninstall another? I understand that on Windows 95 Mud Times, but now with a huge set of different softwares and different installation procedures and mainly decent ones with correct unistallation, why would you use Norton Unistall?
And more, we are almost in 2010, I can't believe you still using operating systems that don't provide at least a regular package and installation manager.
(If you are an user, starting changing your OS to something good(Ubuntu, MacOs, Debian, etc...) before going to such solutions.) But this one is unused that don't even pollute our software environment.

3. Windows Vista
Red, Pink or Brown? Red!
Windows vista is the most non-baked OS that was shipped out this decade.
Containing lots of ridiculous newbie issues, regarding graphic cards, permissions, security, usability, stability and specially performance.
What about compatibility? That was quite a disaster on very first versions. The IT economic crisis might have some relation with this...hehehe
Well, I don't have to describe one of the biggest reason to start using Linux ever.

2. IE6
Better known as "Microsoft Bug Collection", Internet Explorer 6 still being used for a lot of unresponsive people all over the world. And also causing a lot of work to Web Developers in order to achieve compatibility with one of the worst piece of software ever dragged.
It is said that browser compatibility consumes at least 30% of development time and effort in a Web application, and it gets even worst when it comes to Web 2.0 applications.
IE6 is considered the scariest nightmare for the Web Developers, Users and whoever gets closer to it.

1. IPV4
The Number 1 Enemy of: Voip, Security, Scalability, Flexibility, P2P etc...
Considered obsolete since 1995 with the creation of RFC1752, IPV4 is being dragged causing a lot of side effects including hundreds of thousands of companies, software and even protocols in order to solve its problems and limitations.
A great example is ICE specification for P2P Connection, contains more than 70% of dedicated content, that didn't even need to exists if IPV4 had fade out already.
Besides IPV4 being a obsolete old guy, we own it lots of respect for being one of the biggest drivers for Internet the way it is nowadays.
We love and hate you IPV4!

FISL10 Presentations

On June 2009, I was invited for two talks on FISL10 in Brazil.
The first one was about XMPP Freedom and its master plan for world domination.
The second one was a hands on session implementing a Jingle Client in 40 Minutes using MiniJingle.

Attending to wishes I'm dropping them here as Drop.IO which is in my opinion one of the coolest and newest tools on the web regarding file sharing and collaboration. Cheers and Congrats to Drop.IO XMPP Team!

XMPP and Mobile Freedom - Download
Jingle CookBook - Download

Google Voice - So... What New?

Google Announced officially the release of Google Voice.
Besides all market posts and mass comments, the set of new or innovative Voice Features so far are empty. They are just trying to move backwards in time when talking about obsolete and non simple features.
I honestly was expecting much more than a service binded to a real mobile number attached to a formal operator.
In a time that everybody is questioning the meaning of a phone number in the "post email ERA", Google came and released a service based on operator number.
When it might be a short term boom, but as other examples, this might achieve some success not for an innovative concept, but based on Google fame. Google fans probably will use it just to be recognized as early-adopters.
Where is the Interoperability? The Extensibility? The Open Service API? It seems like some basic principles of new Internet where forgotten somewhere under operators shoes.

In short words: "Google Voice does basically what your phone and your operator together always did."

If you are really looking for something that your phone never did before, try Nimbuzz Mobile and feel the real sensation of doing something that your phone never have done before.

Nimbuzz will show you that a "phone number" is the last thing in the world that you need in a full communicator solution.

Nimbuzz uses XMPP and Jingle in order to provide the biggest and feature rich mobile platform ever.

My Fridge XMPP Client

No, it is not a Jetsons Episode! A few weeks ago I spoke with a guy from an appliance Industry, and guess what?
XMPP is being tested as the solution for domestic devices interactivity.
Meaning that in some years you will probably check in real time the presence of milk and ice cream in your fridge directly from your phone, wherever you are! (Via Nimbuzz?)
Interesting things you might be able to do:
* Monitor you food consumption at the end of the month.
* Check whats missing at the supermarket. Goodbye to shopping lists.
* Check if you forgot your oven on, and be able to turn it off remotely.
* Speed up the cooling of your beer before you get home.
* Get updated in real time and receive pictures in case someone break into your house. Directly in your phone.



I cannot tell the company name, but they promised to have something in the Brazilian market by 2011 as pilot.

Check some Jetsons and Inspector Gadget episodes for more ideas.

IM Freedom? Not yet...

Back in 80's electronic Mail, used to work only inside same network and protocols.
The reason was that the electronic Mail first appeared as a feature of proprietary communication platforms. Which usually is combined with market domination attempts.
In other words company A, didn't want to support company B, as they wanted the customers(medium/large corporations back there), to keep buying from the same vendor. Which used to guarantee long term agreements and easier support, as they were required to know only about their own solutions.
After some time the unavoidable happened, some integration companies started appearing. And after another period, some companies started using SMTP as a ready-to-use and plug'n'play platforms with out-of-the box interoperability with other networks, companies and vendors.
With TCP Protocol, we also had a time when Microsoft tried to force everybody into a crappy and proprietary protocol called InetBios. Which also caused same nasty effects before fading out.
The pattern always repeated:
1) Control Tryout;
2) Gateways;
3) Migration to a common and inter-operable solution.

It seems like we don't notice it, but, we are in the exactly epicentric(fase 2) point of the IM Monopoly tryout. The only difference is that it is lasting too long, as we have a mass of ignorant people that just accepts whatever the mass market push into their computer.
This is one of the most cruel monopoly ever! Proprietary IM networks REQUIRES you to have an account on their service in order to allow you to communicate to your friends!
In other words: "They make you drop your freedom of choice in order to keep in touch with your already converted friends!"
Stop this now! Start using federated or aggregation like nimbuzz.com and fight for your freedom putting pressure in order to speed up their surrender!

Never give up your Freedom!

Start demanding the same freedom that you have in or email service, phone, etc...!

XMPP BOTs

A very cool and unexplored feature of XMPP is the easy way to build and deploy automated BOTs.
This is something that is not that easy to do on proprietary networks like Skype, MSN, Yahoo etc...
I will soon start to post here some XMPP BOTs including sources in order to build a collection.

Another great factor is that XMPP BOTs are totally about interoperability meaning that if you run in a XMPP Server with interoperability enable, you can have this BOT in your contact list even if you are not connected through that server. This is totally awesome!

If you have any BOT stable and interesting enough to worth a post, please send me the code and it might be added to the collection.

Let's start building another powerful and exclusive weapon against proprietary networks!

Nimbuzz, Jingle and XMPP at FISL10

I will be at FISL10 this year talking about XMPP mobile freedom, also presenting Nimbuzz as an use case.
I will also talk about Jingle and how to implement a client in minutes using Smack, Minijingle API and PJMedia.

Follow my twitter for updates: http://twitter.com/xmppjingle

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?"

Jingle Logo Proposal

I needed to create a project logo for one of my projects: minijingle.
When fooling around with XMPP logo, I came up with a proposal for Jingle Protocol logo instead.

The reasons that I like it is because it makes reference to XMPP Logo, with the J of Jingle and also to a musical note, meaning the "media" side of the protocol.



This is just the first proposal, let's see what the XMPP and Jingle fans think about it...

I will post the vectorial format here later, so we can have community contributions. (But don't forget to mention the Author! Open Source doesn't mean anonymity)