Conversationware

You’d be forgiven for thinking that telephony lives in a vacuum. Considering that a bunch of ‘communications’ companies were in a big room for two days, I haven’t seen any blogging on the subject at all.

Our stand was busy enough that I had no time to go and see what else was of interest - so I was looking around on blog searches….nothing, nada!

Please feel free to point anything out I shouldn’t have missed!

So by most recent standards the show it was pretty good, and Olympia avoided the normal trade show tumbleweed, although Andy did have time to be on the phone occasionally.

Although we have a lot of solutions these days, Fax Over IP has really taken off in the last 12 months so we concentrated on that message - it went down really well for a mixture of channel and end users.

This one might even pay for itself

I was amused at Tom Keating’s headline t.38 fax dead?  but it turned out to be one of those reverse, attention grabbing lines. Bloggers eh?

t.38 or traditional fax are neither dead, nor losing revenue as far as I can see, and I thought I would echo the amount of interest seen in the field. Fax over IP seminar’s, real or virtual are stacked out.

There’s are simple reasons for this

• Fax doesn’t work very well over a VOIP network, kind of important!
• When moving to a VOIP system, analogue extensions just seem so ancient
• The real benefit of a centralised fax server is that it’s easier to failover
• Small pockets of fax machines, at remote offices for example, are more cost effectively replaced through a centralised server (mimicking the voip system benefits)

A few things may interest people here

Few VOIP systems support t.38 natively yet. For example Cisco does, Avaya does, but Mitel doesn’t until later in the year. It’s likely you will need new kit or software when support does arrive.

The important thing about t.38 support is that it’s the VOIP gateway that is actually terminating the fax, and then passing it on to the centralised IP fax server. (there are other ways if necessary)

There are also some wrinkles to iron out. For example some MGCP encrypted VOIP systems can’t transport t.38 as yet.

So, to sum up, Fax Over IP, or t.38 is a coming technology, not a fading one. And given the Return on Investment and ‘green’ qualities that electronic fax can lend to a VOIP project, I can’t see it going anywhere but up the agenda.

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.

This time next year Rodney……..(for Only Fools and Horses fans)

This linked article from Red Herring shows Jajah has linked up with eHarmony dating site - I wonder who made the first move?

Whoever, it’s a great idea, and the service will presumably hide your number from people you’re not sure you want to know! I picked this snippet up from Alec of Iotum who also looks to treat voice only as a component part of a wider application.

The article, and Jajah’s website shows their burgeoning integrations list, and I feel this will be absolutely key to winning mindshare in the voice application market…even the hosted one.

In fact, voice right now is very reminiscent of the early fax market.

The market in the early 90’s seemed to be dominated by Unix based proprietary systems - check out this quote from Network Computing in the 90’s

Fax servers today are more or less tied to the software delivered with them, at least on the server side. Some fax servers support the Communications Applications Specification (CAS) and can therefore work with a desktop application that supports CAS. So to an extent, you can plug in the desktop client of choice, but you may end up losing some of the unique abilities of the server (such as sharing common phone books or accounting).

(more…)

This post is incomplete, but then so is the industry

I’ve mentioned before that the key to understanding Unified Communications (all of it) is the software interfaces presented to the user. (You may notice I don’t mention voip at all in the following, it’s about users).

Unless the user is going to adopt functionality, there is almost no point deploying it…..and by definition the more interfaces there are, the more difficult adoption will be (how many training course will users go on).

Once the required interfaces are defined, it’s so much easier to put the technologies in the right place, or in the right box, so to speak, and so I have been framing business requirements around the GUI.

The reason I’m bothering here is that I have met with customers who have in front of them very interesting new products - but they overlap so much, and so how does one decide?

It can be as tricky as hell, as current comms software technology on offer includes

Messaging

• Email
• Voicemail
• Fax
• Text Messaging

Real Time Conversation interface,

• Instant Messaging - are you at your desktop
• Telephony - are you on the phone
• Conferencing, Audio dial in, dial out, desktop sharing, webinars
• Video conferencing, are you at your desktop

You can see overlaps wherever you look with UC - but there will be ‘at least’ two interfaces for users - as the ‘button’ requirements are different for messaging, to that of real time.

Messaging buttons; - Address, Send, receive, store, mark as urgent, copy, forward, and so forth

Real Time buttons; - Receive contact, Make Contact, whether IM, call, or video, include someone else in the conversation, transfer, desktop share, present, record, and so forth

• Messaging interfaces are reasonably well defined
• Real Time Conversation interfaces are in their infancy
• Personal Contact Handling isn’t well defined

However, for framing Unified Communication discussions and decisions, each user will probably have at least the first two initial interfaces for personal productivity.

A third interface should exist, but doesn’t yet (?)

Personal contact handling

• This doesn’t yet exist as a recognised ‘desktop based user interface’ category - although network based Grand Central is a good start in showing what will be possible
• Call routing and handling, where should calls go, onto which device, at what time
• Planning - willingness to engage, calendar integration, - Iotum is interesting
• Call processing, what happens to the caller if you can’t take the call
• More loosely defined is a meta directory, routing and capture application such as that delivered by Corebridge - because contact information pervades around all communications solutions, (and existing applications).

It isn’t clear where functionality to control personal contact handling will be interfaced by the user, - most of the above is handled at premises based system admin level currently - but it makes sense if all features to determine the inbound call routing for today, all end up in one interface, (if not provided by a single backend system) to be controlled by the user instead of Admin.

This interface could yet still be provided by a hosted system provider, overlaying and complementing existing site number and mobile number implementations - instead of replacing them completely.

The final interface, enabling existing applications with (the same) communications

As well as providing the primary interface for specific channel technology (show me all my received faxes, calls, emails) All the technology channels above ‘may be’ suitable to ‘enable’ an existing user interface, by line of business - Email a Contact, Fax a contact, Call a contact, record a contact, Text a contact

By way of a small example, although fax is a single technology channel above and sounds simple enough - fax integration can get interesting when requirements appear on the horizon to integrate into Exchange Outlook, or Lotus Notes, then to the telephone system (TDM or IP), then to unified messaging (forward the fax to a local machine) then SAP or Oracle line of business applications, then back end integration to hard copy Multi Function Devices and onwards archiving to the industry flavour EDM.

Nobody said it was simple.

At this point, Microsoft Sharepoint usually comes up in the conversation as a replacement interface to all the existing applications, so UC takes on another interface….and so it goes on, much to the user’s consternation.

There’s a play on words about ‘users’ being addicted to existing interfaces, but that would be cheap.

How to choose

Enabling lots of interfaces with a technology flavour tends to point towards best of breed technologies instead of an all-in-one UC solution.

Generalising: wide ranging applications just don’t go very deep in my experience, and ultimately they don’t generate enough ROI, and therefore sales, to justify the development resource to integrate into every interface (converge) that may be required in every industry.

All in one solutions, may be fine in small organisations where the user requirements are very focussed and not wide ranging.

In larger organisations with wider ranges of activites, each messaging ,or real time conversation, ‘technology’ should support the most possible interfaces you can think of, (and multiple interfaces concurrently).

This almost defines a best of breed requirement for each technology - particularly when in a sector that is in acquistion mode - and if you are adopting UC, it won’t be long before you’re in a sector likely to be acquisition minded according to some sources -technology adopting sectors see most acqusition.

So when you acquire a major competitor next month and have to incorporate whatever they are doing into what you’re already doing, you want multi-interface communication products.

It’s plain that in these unforseen circumstances, functionality needs to be priced in a modular fashion, according to the interfaces required and the inherent value of doing so (each interface is it’s own individual case for each technology).

So, am I proposing that in order to have fewer user interfaces, there is a need for more technology boxes and management?

It’s debatable I suppose, but probably.

I’ve seen non specialist technology suppliers integrating essentially as ‘lip service’ to get the original deal, and then support evaporates over the period, especially when the next app needs enabling, and you have to start looking to replace again.

I’m lucky enough to see the best of breed technology I supply stick over a very much longer period.

If I’ve missed anything then it’s likely to be mobile - but that’s a longer conversation.

It’s been a long day, but is there anything else I haven’t thought about?