Wednesday, October 21, 2009

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


Monday, October 19, 2009

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:

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.

Monday, September 28, 2009

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.