WirelessMoves

Recently, I've been musing in this post about a self hosted alternative to Skype for communication between family members using Asterisk on a Raspbery Pi and the Ekiga SIP client. With the recent discovery that Microsoft is actually listening into Skype text conversations that need has grown even stronger. Then I've read that the upcoming Firefox 22 will have the full WebRTC API implemented and activated. So far my knowledge about WebRTC has been rather limited, I just knew it had something to do with web browser based peer to peer communication but not much else. Time to fill the gaps:

The Wikipedia entry on WebRTC is actually quite brief and pretty much reflected what I already know: There's almost nothing about how it works. The FAQ over at webrtc.org is quite enlightening however. Here are some key facts that will help you to better understand WebRTC if you know about how VoIP works with SIP:

According to the FAQ, WebRTC can be thought of as a web browser based JavaScript API to SIP (Session Initiation Protocol) functionality. In other words, WebRTC contains a full implementation of a SIP stack that JavaScript programs in the browser can use to establish a communication session. While the communication session is peer-to-peer a centralized SIP server is still needed to initially connect the two endpoints. So instead of a native SIP client that has to be installed once, the JavaScript program in the web browser that is loaded from a (web) server that also hosts a SIP server becomes the client. WebRTC can do more than just abstract the SIP API. However, if you're familiar with SIP then this is the way to start thinking about WebRTC.

According to the FAQ and this blog post, WebRTC can be thought of as a web browser based
JavaScript API for two things:

• To access camera and microphone
• To connect to another peer (i.e. to the destination user)

What is not defined is how the other peer is discrovered initially and how audio and video codecs are negotiated. Traditionally this is done with a number of different protocols, SIP being one of them. In other words, the SIP protocol and communication with a SIP server is not part of WebRTC and has to be implemented by the web app on its own (for details see the blog post linked above). What is defined however is the use of the Session Description Protocol (SDP) to describe the audio and video codecs available on each end.

What I am wondering at this point is how two JavaScript applications running on different devices can communicate with each other directly, as I always thought JavaScript enforces the rule that the program is only allowed to establish connections back to the site from which the script was loaded. Obviously that can't be the case here anymore.

The FAQ also mentions a number of other interesting facts: WebRTC implements STUN (Session Traversal Utilities for NAT) to establish a peer-to peer session through Network Address Translation gateways, a must in today's IPv4 environment. Also, echo cancellation techniques are mentioned as well as the codecs used that look pretty neat, bandwidth efficient and wideband and HD video enabled. As all functionality is part of the web browser there's hope that performance will not suffer as much as if all code was written in JavaScript.

So one the simplest use case would be to replace native SIP clients with a browser based WebRTC client that implements its own SIP stack. WebRTC clients can even communicate with native SIP clients over a proxy server if both support a common audio and video subset. This seems to be the case with WebRTC supporting the G.711 and G.722 audio codecs that are widely used in the SIP world today.

This obviously fits into Google's overall (Chrome) strategy to have everything running via a centralized server in the network and in the web browser on user devices. While this is not exactly what I have in mind due to my preference of hosting my own web services at home the architecture is open so nothing would prevent me from running my own SIP server at home with an open sourced WebRTC client and proxy. Having the client run in the browser also means that the client software can be deployed without any hassles. The use case implemented by Ericsson over here gives an insight of what's possible with "just in time" deployed communication clients. At this point, WebRTC breaks with today's technology to offer new and interesting possibilities to explore.

For further insight, have a look here on SIP servlets and here for a HTML5 SIP client (+proxy) implementation with WebRTC.

When I am at home I'd sometimes really like to use the 25 Mbit/s of my VDSL line to its full extent. That's easier said than done as my VDSL router is in the hallway while my PC is in another room. Laying a cable is not an option so I am relying on Wi-Fi. As my notebook does not reliably work with the VDSL router's built in 802.11n Wi-Fi since I upgraded the router's software I use the 802.1g Wi-Fi built into my somewhat old WRT54-GS Wi-Fi router I use a VPN gateway. That limits my transmission speeds to about 18-20 Mbit/s in practice. In other words I am falling around 5-7 Mbit/s short of what's possible with my VDSL line. Not ideal.

So I decided to do something about it and bought two 500 Mbit/s Powerline adapters. I had high hopes for the solution as the linear distance between the VDSL router and the PC is 10 meters at most. Also, most reviews on a number of web sites were very positive. Unfortunately, it seems that the the power socket in the hallway and the power socket close to my desk might be on different phases or there's something else in the way as my throughput was a meager 2 Mbit/s. Not quite the hundreds of Mbit/s I was hoping for…

I then connected the power line adapter in the bedroom and the kitchen and again I only got 2 Mbit/s each time. In the bathroom I got 7 Mbit/s. Only when I connected the the two Powerline adapters to sockets in the same room did I get the full 25 Mbit/s bandwidth of my VDSL line. The diagnosis program shipped on a CD with the adapters indicated that the line speed was 300 Mbit/s but I didn't give it a try as having the adapters in the same room is a nice exercise but worthless in practice.

I live in an apartment building in Cologne that was built in the 1980's so I don't think my power cabling is out of the ordinary. Quite a disappointing result. Looks like I have to think again about a better Wi-Fi option, Powerline's definitely not the answer for me despite seeming to be a good solution for many others.

So far I've been using my RasPi for virtual applications such as hosting my own cloud services. But the Pi can do much more and I've been thinking about using one to control something in the real world beyond my music streaming setup with Squeezeplug. Interfacing with the real world requires inputs and outputs, of which the Pi has plenty. Driving motors and reading sensor input requires some special hardware though and there are a couple of add-on boards available for the purpose. Thanks to a tip of a friend I just found the add-on I really want to have for that purpose:

The BrickPi: LEGO® Bricks with a Raspberry Pi Brain

The BrickPi is a board and a casing for the Pi to integrate into Lego Mindstorms. I can already imagine building a couple of robots to do some fun stuff, like a robot on wheels with a web cam on top that I can send through my house to see what's going on when I am not at home. No problem with a Wi-Fi enabled Raspi on the robot that controls the wheels. Incidentally, the Raspberry foundation has just announced the availability of a small camera add-on module. Ultimately, though, what I have in mind with it is to give it to my nephews and nice as a computing and construction learning tool.

Note that the BrickPi is not a finished product yet, it's a kickstarter project and in case the people behind the project don't deliver your money's gone. Well, they have my 55 dollars now.  With 648 backers at the time of writing, $37.600 in funding and a company behind the project that has been working on similar products before I think chances are quite high that they deliver on their promise.

The delivery date is foreseen for August. Time enough to dream of further things to do with it for myself and how to pitch it to my nephews and nice as a Christmas present.

Since I discovered how I could use cloud services such as file sharing as well as calendar and address book synchronization with ownCloud and a Raspberry Pi from my own home without having my data stored I keep having revolutionary experiences with this low cost, low power hardware that runs Linux. My latest own-use discovery is SqueezePlug.

I've been looking for a web radio solution for quite a while now. While I have an off the shelf web radio with a display in the kitchen I wanted to have a somewhat more embedded and hackable version for the living room that connects to my Hi-Fi set and can be controlled from my PC and mobile phone. There are quite a number of proprietary solutions out there but they come at a relatively high price and remote controlling the devices always seems to go via a cloud service outside my home. Particularly the later part is not my cup of tea.

Then I stumbled over SqueezePlug which is Logitech's Media Server (LMS) and a Streaming Client both running on a Raspberry Pi. With a nice looking and easy to use web interface, I can now remotely control my stereo set over Wi-Fi without the need of an external web service. For additional sofa comfort, there's 'Squeezer', an Android App to switch channels and to control the volume. The source can be found here and is available in the Google Play store here.

At a power cost of around 6 euros a year for the Raspi (!) I can even keep it running 24/7 to compensate for the somewhat long delay before the LMS is available after power-on. So for 40 Euros for the Pi, 10 euros for a nice casing and 10 euros for a USB sound adapter I have a full fledged and remote controllable web radio in the living room. Perfect!

P.S.: You might wonder why an external sound adapter was necessary!? For some strange reason the Raspi's analog line out that works o.k. with other software produced some strange crackling sounds when using with the SqueezePlug software. No problem over HDMI or over an external USB sound card. I tried two different ones and both were recognized by the Raspian Linux OS without the need for installing anything.

On my desktop PC I proud myself with only having to reboot perhaps once a week. While I consider this as a sign of operating system stability I recently noticed that I could not remember when I last rebooted my Android based smartphone. Even though I use a lot of apps such as the web browser, Google maps for navigation, the Kindle App and FB-Reader for ebooks, K-9 for email, the weather app, train table lookup app, etc. etc. it took over 1000 hours to finally come to a point when a reboot was necessary. That's over 40 days the OS was running non-stop. A new personal record as my previous phones usually rebooted in some sort of self-defense mechanism every now and then.

It doesn't happen often but it does happen: Just when you are on the other side of the world, your cloud services at home hangs up. The DSL router looses sync, the VPN gateway has decided to go belly up or one of the servers stops cooperating. So what can be done? If one could only perform a reset…

In the past I've used a power socket with a timer to cut power once during the night to reset everything. Crude but effective with the slight disadvantage that in the worst case I have to wait till the next morning for my services to come back. Another slight disadvantage is that late at night local time is not necessarily a convenient time in another timezone for the VPN service to go down for a couple of minutes during local daytime. So I was looking for a more sophisticated solution and have found a cool "out of band" way to reset my network at home, a GSM Power Socket.

In Germany the GSM power socket is sold under the brand name of "GSM-One", for example via Amazon for 89 euros. To switch power on or off a simple SMS with a command code inside is used. The power socket then returns a status message to confirm the command. Very cool. Even cooler is the the SMS alert message when a power outage occurs and an SMS status report once power returns. Very nice, this puts me back in the drivers seat again no matter where I am.

In other countries, the device is sold under different brand names. In the UK for example it Sells as "Lindy GSM Power socket" for a shocking 142 UK pounds. For those not familiar with currency exchange rates between pound and euro, it's around 1.1 at the moment. Quite a hefty surcharge to order it in the UK…

The previous post on the Raspberry Pi as a GSM gateway has made me think of what other uses such a setup could have. A bit of a thorn in my privacy and open source loving heart is Skype. Closed source and controlled by Microsoft is about as far away from privacy and open source as one could imagine. But it works and I use it quite often and especially with its video calling option I didn't see real alternatives. That is until now…

Perhaps the following setup should do the trick:

• A Raspberry Pi hosted at home
• Asterisk on the Pi, 25 Mbit/s down and 5 Mbit/s offers ample capacity for voice calls
• Ekiga for SIP telephony between two PCs. According to the Ekiga page, HD voice and HD video streaming are supported.

So on paper this looks pretty cool as it would cover my application of making video calls between two PCs, one usually in my home network and the other somewhere on the Internet. With the SIP telephony server running in my own network and the voice and video stream running peer to peer it's about as private and open source as it gets. But how well does it work in practice? There are lots of unknowns beginning on the PCs and how well Ekiga runs on them down to the network layer and how Ekiga can handle the NATs in between. With a spare RasPi available I wonder how long I can resist giving it a try!? 🙂

I've been running my ownCloud server on a Raspberry Pi for quite some time now and to say I am enthusiastic about it is rather an understatement. The Raspberry's versatility is incredible and I've recently come across another application that could come in quite handy in the future: Running Asterisk PBX on a RasPi and using it as a GSM Gateway.

Here's a post over at the Carrier-Connect blog that describes such a setup to forward calls over IP for a person's mobile number of country A to the person's mobile number of country B with the help of two Raspberry Pis and two 3G/GSM data sticks that are also circuit switched voice capable. And to make the Asterisk setup as painless as possible there's even ready to go Raspberry Debian (Raspbian) image and documentation available here. Amazing!

From what one reads on the web, OwnCloud seems to have become quite popular. While I have two small Owncloud servers of my own at home I had yet to see someone else use it, too. And to my surprise it happend faster than I thought.

When I recently passed by the desk of one of my co-workers I noticed the familiar ownCloud design in his web browser. It turned out that it was the ownCloud of a company that wanted to share a number of documents with him without using a public storage provider.

Very nice so now I know for a fact now I am not alone. While Dropbox or similar services would have spared the company the effort to set up their own server it looks like privacy and confidentiality were ranked higher than convenience.

How nice!

Here's a link to an interesting post over at Telegeography titled "International bandwidth demand is centralizing". The figure at the top of the post nicely visualizes the two key messages:

Not surprisingly lit (used) capacity of undersea cables continues to increased at a staggering pace, around 50% year over year. Between Europe and the US, for example, capacity of around 12 Tbit/s was added in the past 5 years. Terabits…

The second point of the figure is that unlike in previous years, bandwidth additions have been pretty much equal across the globe and are no longer focused just between Europe and the US. I would have thought differently with the majority of cloud and video streaming services being operated by US companies. But perhaps not so surprising at all with companies such as Akamai making sure content is not streamed across undersea cables but from a server as close to the user as possible.