Conversationware

Perhaps this is old news already

A sale has been on the cards since they went completely indirect and the manufacture was outsourced (if memory serves).

I remember when the big UK PBX’s in the old days consisted of

• Siemens ISDX
• Mitel SX2000
• Nortel Meridian Option 11
• Alcatel 4400
• Lucent Definity
• Ericsson MD110

A bit crowded when certain other companies joined the fray I suppose.

Obviously there are no announcements from Aastra about futures yet, as this won’t be concluded until April 2008.

The MD110 had a superb installed base in the UK. Back in the day they had a very innovative and reliable distributed solution. It was kind of the Ford Granada of the comms world.  

I’m sure this won’t happen soon, and I feel a bit like an ambulance chaser - but if MD110 customers were to consider change, they should keep hold of their Unified Messaging Onebox system, as it is an AVST CallXpress system in disguise - and that fits onto any IPT PBX. (drop me a note).

I’m telling myself that it’s just being helpful really

There’s far too much of it about and I’ve just read some more here. Sorry Art, I have to call it like I see it

The clue is in the first paragraph, where it says;

“What was most interesting about this piece was that it quoted several different definitions of UC promoted by leading industry technology developers and analysts”

We can’t let people off with describing the technology just how they would like to see it at some far off distant point can we? Those leading developers and the pet analysts, with their own interests at heart, are currently spinning off each other into a dustcloud that nobody can see into.

I really don’t have a problem with people who disagree about a definition -if they would only come up with a definition that people can understand. Yes it can be complex, which is why a clear explanation is required….apply more rigor. If people can’t understand what you’re saying, stop talking.

Personally, I don’t think the following should be mixed up.

• Unified Messaging
• Real Time Communications (The real Unified Communications can stand up)
• Fixed Mobile Convergence
• Communications enabled business processes.

That’s because Unified Communications is about the person, the user - people communicate, companies don’t.

So, what exactly is being unified for the user? - Answer: GUI client software.

The whole point is that instead of installing ten types of client software and teaching the user to work each one, for the telephone, instant messaging, conferencing, video conferencing, web conferencing, for example - a user just has one interface and a single address book for the lot. Multimodal. By combining client software, we make it easier for the user to use - and therefore to understand.

You wouldn’t/couldn’t have a single interface for messaging and real time communications because they would have different buttons. I also can’t see people using GUI software on a mobile device, pie in the sky…but perhaps that’s just personal opinion.

UC will generate sales - but only when they show it fully working to the end users.

/end rant.

If anyone else wants to agree or disagree, feel free to join in.

Something is wrong with Presence.

I harp on about this technology, and I keep looking around to see whether I can be proved wrong.

So, I was grateful to Mike Gotta (again) for pointing to this audio interview (48MB, 50 Min) with one of the founding fathers of Presence, Peter St-Andre with Lee Dryburgh, who happens to be organising a Unified Communications event in the spring, Ecomm2008

I do like being proved wrong, although friends and family may disagree, but my problem with Presence is still that it doesn’t seem scalable beyond immediate and close relationships.

Although very entertaining, and well worth the (your) time, I’m not sure the interview answered all my questions.

Ok, here’s the beef.

The more people I know, the more likely I am to be interrupted at someone elses convenience. 

On the basis that I don’t want to micro-manage my availability between constantly changing relationships with all the people I know, I just can’t make it work.

I initially equated Presence with ‘Busy Lamp Field’.

This was a quaint term used to describe the lights on a key telephone system handset, that lit when someone lifted their phone handset. As an early key system evangelist I thought this ‘Presence’ was going to be great.

Of course, the supposition turned out to be wrong. Despite people desperately wanting it to work (including me). Busy Lamp Fields are possibly why ‘phone’ people are very keen on this tech, but BLF and IM are not the same!

Whilst a ‘lit lamp’ told someone I was on the phone, and helped them know ‘not to try calling me’ (note, try) - when the lamp wasn’t lit, it DID NOT mean I was definitely at my desk and available to talk.

Whereas, the blinking IM message says that until you reply, you’re being ignorant. The refusal to communicate is in broad daylight.

Thus, there is an emotional blackmail being set, and to my mind that is exactly why people don’t buy into it.

It almost pains me to say it, but telephone presence is more useful to the recipient than desk based presence, in that there is no obligation to interact.

Another problem exists and it is this.

As a real time communication, there are also less facilities than asynchronous communication. This question of synchronous vs asynchronous came up in the podcast also, but indirectly.

So, the time to compose a considered and consultative response just isn’t there in real time conversation.

You can’t forward an IM for consideration by someone to contribute (with any certainty someone is going to be there right now!)

And, unlike other web based communication, the conversation isn’t discoverable (indexed) and won’t contribute to the knowledge base of the rest of the community. 

I find it interesting that the chap who first got me thinking on the Presence subject, Alec Saunders, has his company, Iotum, pioneering another communications medium - the multiparty conference call. 

Interesting because the conference call, whosoever has one, is booked in advance, and has a subject. It is a viable alternative to Presence . The permission factor is key for me. I’m not yet sure whether this has a significance on Alec’s thoughts on his New Presence…dot dot dot.

So, let’s have an invite…and acceptance….to talk about a subject….at a particular time, or joint circumstance.

If we have agreed to talk on a subject, and we’ve both concurrently indicated we’re in free mode, THEN let the availability be shown. It’s better than trying to reclassify everyone I know.

In my view, Presence missed a step, the equivalent of the ringing phone invitation.

Any telephone system salesperson will say their new sparkly VOIP platform supports unified messaging.

I bet it doesn’t support everything you might want though. The devil is in the detail.

Huh?

In reality, this is only because the word itself hasn’t been defined very well. So, what is being unified, where, and for whom?

If this subject is at all interesting to you, then you should know there are 4 types of user desktop accessible voice messaging.

A. Server based unified messaging

This very best unified messaging system sends voice and fax messages to the email server for storage and access.

The UM system will then usually also have a plugin installed at the email client for GUI setup and playback.*

This setup means that all messages then benefit from the ALL of the resilience and access methods that have already been paid for on the email system. (If you haven’t got resilience for your email system then message me abut Neverfail!)

1. The users see no difference between message types
2. Web Access is supported in the existing client OWA, iNotes
3. Notifications and rules are the same for all messages
4. Thin client is seamlessly supported
5. User voicemail set up is also GUI based via the email client plugin
6. Text to speech over the telephone is easy, but this should be available in all 5 scenarios listed here

NB: This does NOT mean install UM on the email server. I have seen this cause restrictions on functionality, reliability, change management overheads, and ongoing cost of ownership (and support…resellers take note). 

* Notes sites could use DUCS (Domino Unified Communications) for the clients, but this can be more expensive than a whole UM system on it’s own, so wouldn’t recommend it.

Most important of all, there is only ever ONE copy of the message for the user to worry about

B: Client based unified messaging (integrated)

This takes advantage of the ability of Email Client software, like Outlook, to access messages stored in different places.

Voice messages remain on the voicemail server, and are presented in a second ‘inbox’ to the user, meaning that access is graphical and bit easier, but not fully ‘unified’. The email client is ‘looking’ in two places for messages.

1. Voice messages are NOT available by web access to email
2. Resilience and backup for voice messages has to be considered separately
3. Voice messaging and email message are not totally interactive
4. Messages saved, or deleted, by the telephone are not resident in email ‘deleted’ folder, and therefore not retained.
5. Many systems can’t provide telephone access to email in this setup

C: ‘Simple’ ‘unified’ messaging

Most common amongst smaller telephone systems, the offer is to send voicemails to email.

Unfortunately, this option looks very similar on the UM brochure, with a voicemail in Outlook inbox.

In reality it is not at all useful for the user (the whole point of UM is to make life easier for the users).

1. The first choice is usually whether to ‘forward’ a voice message - which actually means ‘copy’. The trouble with ‘copy’ is that the user then has to manage two copies of the message, this is fraught.
2. The other option, which is to ‘move’ the message over to email, then means the message is no longer available via the telephone.

Not a good choice to have to make 

D: Browser based access

This isn’t ‘unified’ messaging at all, but it does provide a solution for those users who shouldn’t have voice messages embedded into email.

A lot of finance companies, for whatever reason, are worried that voice messages might be included in legal ‘discovery’. Interesting, because most legal companies I know are insistent that voice messages should be included in the email store.

Browser based access to the Voicemail server still provides a GUI front end for messages and mailbox configuration, but keeps the voice message separate from email, and, if streamed, can prevent a message being saved to desktop and then forwarded without record.

E: Voicemail Only

You may want some of the above for a proportion of users, but if you have users without email, they may want only a voicemail box. This should be possible without incurring any licence costs.

F: So What You Want is………

A system that can provide all 5 different types of messaging, concurrently, on the same system, to different sets of users with different needs.

You just don’t know what you’ll need next week, or next year after the acquisition.

You may also want the following

• Any PBX switch support - VOIP or not
• Multiple PBX support on the same box for migration
• Unlimited Auto Attendant Menus
• Personal Attendant Menus
• SMS notificiation
• Mobile device support (single mailbox, multiple devices)
• Mobile auto logon
• Speech Integration, Directory, Settings and Groupware Calendar and Contacts
• Fax integration
• Thin client support (Citrix, Windows)
• Old Voicemail key emulation (Octel, Audix etc)
• Networking
• Failover
• User Management
• Scalable
• Modular

Did I miss anything?

Oh, by the way, Unified Communications is completely separate - that uses different client software and application servers.

Message me if you need further info about a good service led distributor.

I’ve been having fun.

I got the idea of a diagram from David Armano - his blogging story is here, worth a quick read. He always seems to have a diagram or two to communicate his ideas and I’ve been impressed. I thought I’d have a go at that…only I can’t draw very well.

So, the mindmap below was created at http://bubbl.us - a free hosted service for mindmaps. A very simple to use and quite exquisite user interface. It took only a few minutes to work out how to use.

I love mindmap interfaces anyway, being the most gratifying way to communicate difficult concepts visually without any visual design talent (believe me).

The MOST special part of this map though is that it is ‘embedded’ on the page. It is read only, but, you can click, drag and zoom in and out on the page. Give it a go…I’ve been messing with it all evening.

No matter that I haven’t finished the map, I can update the web application, and it will update on the page, and anywhere else I’ve shared it, with no further effort.

One snag, the solution is being re-written right now, and we’ll have to wait for the problem free embedding version for you Firefox viewers. I’ve added the diagram (exported naturally) below for a full view.

If you can’t see it properly, click this image

The next step is for me to see what it looks like in a Reader.

The idea behind this mindmap is to group technologies together to see what patterns emerge and to remind how things might fit together.

Companies are going to find it harder than ever to prioritise where they spend their communications budget.

Unified Messaging groups together message types now merging into one client (although not a single application). Unified Communications are merging into another - if that’s your definition too - it’s not everyone’s.

The more established technologies have more facets, it seems to indicate there’s more to come from the asynchronous and newer techs. I also think that asynchronous technologies will merge into a single interface….stands to reason.

I suppose in the end, you have to decide what you want to communicate, who to, and how. This diagram merely shows the how.

I know I have to add micro-blogging, but feel free to chip in, or let me know where I’ve got it wrong.

One of the big benefits to installing a VOIP telephone system is that you can build in resilience. The ability to provide service in case of failure or disaster is behind most decisions.

However, might you want to transmit a fax between sites?

Or, to put it a different way, might you may want to transmit an analogue modem signal, either 9.kbps - 14.4kbps, or 33.6kbps ,over an 8.0kbps channel?

Uh oh.

You ought to know compression and encryption are just no good when it comes to an analogue modem signal, and inbound fax across the IP network just doesn’t work consistently in any manner.

SO, what to do?

Well, what normally happens at this point is that ‘fax’ is handled locally per site. With logic, and funds, dictating the use of a ‘fax server’ instead of manual and paper based faxing, this can often ‘logically’ lead to the installation of multiple fax servers, with incumbent multiple bits of tin, multiple software licences, mutliple fax interconnect kit with distributed user databases and pockets of important documents on each of your sites.

Immediately going back to the reason for implementing VOIP - you care a great deal about resilience and redundancy - this now becomes an issue for your very important documents (PO’s, orders, contracts etc) which reside on multiple servers.

Do you fancy supplying redundancy for 6 fax servers across all of yours sites - isn’t that 12 servers alltogether? Not forgetting that six fax servers are utilising client software that is looking at 6 different server IP addresses. Good grief.

Let’s separate this out. Outbound fax is simple to deploy, because you can generate documents to be sent out from a central location. The modem signal only comes after the documents arrive at the fax server.

So, inbound fax is the only real question here.

A lot of VOIP gateways are now available that support the local termination of an inbound fax, ie. pretend to be the fax machine.

They will do one of two things

1. - SMTP into email accounts.

Easy, but if you want to ever find documents again in the future, then this is not ideal

2. - transmit the document to a central fax server resource using T.38 protocol

Why T.38? This is to preserve the real time nature of faxing, so to eliminate the analogue signal, but still provide all of the acknowledgements that sending fax machines expect.

This is far better than any store and forward approach.

T.38 Gateways can be the VOIP manufacturer’s, or you can deploy separate gateways if you care to.

The bottom line is that with one server you can now take advantage of all that SAN hardware you swore would come in useful one day. Install your single faxing database on that and you have resilient nirvana.

First, frame the problem.

Whatever your definition of Unified Communications, (this link is my own ‘What is unified Communications’ approach), there is an inescapable conclusion that in order to make software based communications work good, you have to find, and then telephone enable (all) your contacts.

Only one problem, and that is, the possible inbound and outbound contact details you might need are literally all over the shop.

• Customer Relationship Management systems
• Accounts software
• Outlook or Notes personal address book
• Global address book
• Your mobile phone
• Paperwork
• Web
• A colleagues’ version of the above

Of course, these contacts increase exponentially with the number of social software platforms that you’re using such as linkedin and facebook.

(more…)

It seems that businesses don’t really know what UC is, or how to justify it yet. Apparently voip vendors agree what UC is - although I haven’t seen them explain it in too many places myself!

Interesting article from an interview with Irwin Lazar from Nemertes research

I have been asking some VOIP experts why companies should bother with VOIP at all, given the complexities, cost and security concerns (you don’t need voip for unified communications). Martyn Davies at Dialogic bothered to answer

Here’s his view. Telco Innovation is the answer. So, I’m still not sure about VOIP for business.

VOIP services and softphones are often ‘too difficult’ for me to comprehend, so I’m pleased Intel has patented the softphone and I’m unlikely to see too many more of these around. I share a lot of the sentiment in this quote -

“I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. - Bjarne Stroustrup, the inventor of C++

I’m far better off with software interfaces that don’t need any instructions - like my ipod. I hope the interface Intel come up with is a good one.