[Sagi Subocki is director of product management in the Technology Business Unit (TBU), and is responsible, among other things, for our Advanced Services Framework (ASF). I asked him to introduce the product here, as I believe presence is a key component in any visual communications deployement]

Do you remember the days when, if you wanted to connect to the Internet, you had to go to the computer, dial-up and connect?  These days we’re always connected, using our computers, smartphones, tablets, and connected from everywhere, using Wi-Fi, 3G and more. And the more we are connected, the more it is important to know where we are and what is our status in terms of availability. In other words, we are where our presence info says we are.

Presence is truly a great feature. With presence the call initiator can poll the current state of the callee, and – based on that – choose the appropriate means of communication that is most efficient or suitable. One could say, and I heard it a lot of times and from a lot of people, that “Presence is the new dial tone!”.

And yet if you look around most presence solutions today are complete out-of-the-box solutions. This means that as important as they are, they are the “property” of their creators, and if you want to use them, you need to use the entire solution, end-to-end. Usually they are also closed environments, operating in silos, with no natural and intuitive way to interoperate with similar environments. As a result there are several different standards for presence-based services: SIMPLE OMA for IMS and RCS compliant networks (usually for telcos), XMPP for Internet based services such as Google Talk, etc.

And the problem is not just that all these different protocols are used to convey presence in the systems we use, but that there are systems out there that decided to adopt a few of them at the same time (for instance, use SIP for VoIP but XMPP for presence), while others have decided to go for things like SIMPLE OMA and the full blown RCS model. Well, you get the point – supporting different service providers and networks require supporting different presence protocols.

So How Do You Make Presence Work For Your Application?

Now let’s assume you are building some kind of an application, and would like to add presence to it. You know – maintain a “buddy list”, maybe bring in the corporate address book, update presence information, offer instant messaging, provide file transfer capabilities, etc. What you’re facing is a real challenge: you have to follow many standards, you have to test it all interoperates, there’s a level of ease-of-use that has to be maintained and… you have to take care of it all.

Well, why worry with presence when you can get all of that out-of-the-box?  After all, this is exactly why we’ve built our Advanced Service Framework (ASF). It provides a high-level interface for application developers with an integrated address book, hiding the standard complexities and supporting a variety of presence-based services – RCS, XDM, MSRP, SIP, XMPP and LDAP. This allows developers to develop a fully interoperable, presence-based serve quickly and with ease.

You can think of it as a presence-based address book that you can use for your application, where ASF maintains that address book for you(in fact, it can also integrate into existing address book systems), and adding on top of it a layer of presence.

The beauty of the ASF solution is in the fact that the API itself isn’t specific to any presence protocol – it allows using the different protocols out there, and doing that simultaneously. This allows developers to connect their product to XMPP and SIMPLE based presence servers at the same time, which is very important in today’s landscape of various services. And it runs on any platform – be it desktop, embedded or mobile.

And that’s basically the story behind it all. It just makes presence run perfectly in your application. And this lets you focus on your core value, leaving presence “technicalities” to us. As presence is becoming a key component in any form of communications, you should really not settle for less than perfect.