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.