A History Lesson

In the beginning, there was Internet Relay Chat (IRC). Early on, IRC was enhanced with private messages (PMs). Following this, Instant Messaging (IM) services were born. People were talking to one another instantly and for free online via their computer. Everything was grand. But the underlying basis of each of these technologies was that the recipient of a message was actually online at the moment that the message was sent. Many IM services still do not support offline messaging (or, storing received messages for a user on a central server until they sign on). Now that we expect our technology to follow us everywhere all of the time, sending messages to our pals while they’re not particularly “online” has become a higher priority.

Wait a Second… Why not just use Text Messaging (SMS)?

There are a plethora of arguments for and against text messaging, but right now what it comes down to is preference¹. When it comes down to it, text messages and IMs are fundamentally the same: short messages sent from one person to another. In my mind, text messages ought to be made redundant by things like mobile IM applications since the underlying technology there is inherently more powerful, scalable and flexible.²

The Holy Grail

Alice and Bob both have IM accounts with the fictitious IM service Shoot. Alice pops on her computer to send a message to Bob, but Bob isn’t at his computer. Not to worry; Bob has installed an IM client on his phone and can receive Shoot messages anywhere. Alice sends a message to Bob via Shoot, who receives said message on his phone. Bob’s phone beeps, vibrates and generally interrupts his concentration until he has replied to Alice’s message. Alice can rest assured that Bob got the message, and Bob now knows that he has to pick up Charlie from soccer practice. Lovely.

Not So Fast…

The underlying assumption in the scenario above is that Bob can receive a message over the internet via Shoot anytime because he’s always “online” through his phone’s data connection. Sure, it would be simple to assume that Bob’s phone has a persistent connection to the Shoot servers, but that would be horrible (and unfeasible) from several technical standpoints. Definitely one of the more pressing technical concerns involved is battery life. Unfortunately, keeping an internet connection alive between a phone and an arbitrary server is a bit of a power drain for mobile devices, not to mention the networks they use. But even if we had magical everlasting Willy Wonka batteries, the reality of the matter is that the omnipresence of cellular service just can’t be counted on.

But how, then, do we receive phone calls, you might ask. Doesn’t that require a persistent connection of some sort? Well, yes, it does. But that type of connection is fundamentally different than an internet connection. It’s a direct³ connection to our cellular carrier using a connectivity mechanism crafted especially for making and receiving phone calls and very short data items. They aren’t based on the same type of connections that internet traffic is.

This is where iPhone push notifications come in to the picture. Instead of keeping a connection open to each of our services (Shoot presumably being just one of many), we instead use the existing persistent connection that we keep with our carrier (or one just like it) to bother notify us when something of interest has happened. That way, when Shoot processes a message from Alice for Bob, it forwards the message on to Bob’s carrier, who lets Bob know that there’s a new message. Of course, it’s all a bit more complicated than that, but the basic gist is there.

Now that we have push notifications, what’s the issue? Basically, Shoot doesn’t know how to talk to Bob’s carrier. In fact, all Shoot knows how to do is talk to programs that speak its proprietary (or at least specialized) Shoot protocol or language. Likewise, Bob’s carrier speaks its own specialized language. This means that there needs to be some bilingual middleman somewhere to act both (a) as a Shoot client speaking the appropriate language to the Shoot servers and (b) as a client of Bob’s carrier, sending the appropriate message in its respective language. Oh, and operating such a middleman service costs money. In some cases, big money: more connections, or longer connections, equals higher cost.

So How Does Beejive Do It?

Beejive, like any third-party IM client for the iPhone, relies on a middleman service to relay messages from the various IM services it supports to the phones that are connected to it. This service sits on an internet-connected server somewhere and maintains at least one persistent connection to each IM service for each user that’s “online”. As far as the IM service provider (in our case, Shoot) knows, this middleman is actually an extension of Bob: it looks, feels, tastes and smells just like Bob’s desktop IM client. Beejive has to cover the cost of said service and is presumably doing so by charging a purchase fee for their IM application.

Discussions about one-time-fees versus subscription-model for services aside, Beejive has decided to lower their costs a bit by limiting the amount of time during which its relay service is active for a particular user. At time of writing, this limit is currently user configurable up to a maximum of 24 hours after you last use the Beejive IM application. In short, this means that Beejive IM will log you out after 24 hours disuse. For losers like me who don’t necessarily receive an IM while away from their computer once a day at least, this is a pain. More than just a pain, though, the prospect of being automatically disconnected from a communications service seems stupendously silly to me. Imagine having your phone disconnected unless you make a call every day!

Is There An End To This Madness?

The key issue here — the real reason that we require a middleman at all — is that IM service protocols and standards really haven’t changed a whole lot in the last decade. Sure, we’ve had developments here and there but even still the most popular IM service providers rely on proprietary technology to get their job done. Today’s IM services don’t readily support the type of extensibility that would be required in order to implement middleman-free (or at least middleman-minimizing) mobile instant messaging.⁴ As usual, it boils down to a standards and agreements issue. Until IM service providers pony up with updates to their protocols and services that everyone — ranging from service providers to carriers and clients — can agree upon, we’ll have to continue to use these middleman services, transparent as they may be.

1. Preference for or against text messaging may or may not have anything to do with cost.
2. A bold claim, but this is definitely feasible and even likely. As IM services coupled with social networks become more popular, text messaging usage will inevitably decline. The flexibility afforded by placing more technology in the hands of the community rather than in the hands of cellular carriers will easily trump the straightforwardness of managed technologies like text messaging.
3. Except while roaming, of course, in which case the connection isn’t quite direct.
4. Not necessarily true, but this type of mobile instant messaging hasn’t become standardized or widely implemented yet.

Here’s how to get Fring to work with SkypeOut: prepend the call number a + followed by the country code of the recipient of the call. For example, when calling a phone in the U.S. add +1; (800) 867-5309 then becomes +18008675309. To get the +, I simply press and hold the 0 key on the dial pad in Fring.

I’m not sure that this was always required, as I could have sworn that Fring used to ‘just work’ most of the time, but maybe I’m mistaken. Either way, I’m glad to have it working again!

Now with the 3G iPhone, I cannot travel my morning/evening commute route without dropping my calls, sometimes more than once during the 15 minute commute. Checking the ATT coverage map shows that the location that I drop my calls is an area that has no 3G coverage, which is surrounded by an area of full 3G coverage. In other words, I drop calls when I travel from a 3G coverage area into an area of no 3G coverage. The problem is that the iPhone refuses to hand off the call from 3G to GSM. When the phone does switch to GSM the signal is very good, but the call has already been dropped.

This is one of the issues that I’m having, certainly, amongst others. Many have suggested that the solution is to simply turn off 3G, to which the general response — was annoyance. Though this solution does indeed work, it’s definitely not one I’m terribly thrilled about. One aggravated customer responds:

So we’re paying an extra $15 a month extra compared to the older plan and can barely use it without glitches… and you recommend shutting of 3G to make calls?

I can’t agree more, having ‘upgraded’ from a fairly well-functioning first-generation iPhone to this. Some people reported that they were able to alleviate the issues by simply restarting the phone but unfortunately this had no effect for me. It appears, however, that there’s light at the end of the tunnel! The original poster eventually took his phone back to Apple store and was given a replacement.

On my way home I decided to test the new phone, so I started a phone call while in 3G service and then drove home via the same route that I normally commute (which previously had always included 2-3 dropped calls during the 15 min commute). I was shocked that I did not drop the call the entire way home! Since then I have traveled the same route several times while on calls and still have not dropped a call. I have even watched my phone switch over to GSM while on a call!

That definitely sounds promising, so I’ll have to give it a shot. I’ll be going to the Apple store later tonight, and will post back here in a few days with the results.