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.