Do You Need More UC Interoperability? — Transcription
Anne:Welcome everyone. Thanks for joining us today for our brand-new AVST live webinar session - "Do you need more UC interoperability?" I'm Anne Anne rude with AVST marketing. Our presenter this morning is Tom Mennise, our CTL and so, without taking any more delay, I'll go ahead and turn it over to Tom.
Tom:Great. Thank you, and welcome everybody. Appreciate you spending some time with us this morning. Normally our sales engineering staff provides these presentations, and they're all out on the road meeting with our customers and prospective customers, so I get the opportunity to do this today, which is great. As Anne mentioned, we're going to talk about unified communications interoperability, one of the real challenges in meeting your UC deployment objectives. So, with that, let's get started.
Firstly, some market observations when it comes to unified communications. It's one of those terms that it certainly been out there for a while, and you see different definitions for it, but just to level-set this discussion, what is unified communications? In our eyes, it's really the bringing together of different communication method. As the definition would imply, it's unifying those communications, and regardless of location or what device you're using, or what method of communication, unifying those together so two people can communicate effectively, bringing together information and business process as part of it, and to just optimize that whole communication flow.
Really, when you think about it, we don't all buy our communication technology or methods from the same place. So, unified communication really requires a convergence of multiple vendors, multiple techniques together in a unified fashion so that, regardless if you have some old technology and some new technology, and regardless of how many vendors provide that to you, it's really bringing those together so they work as one and provide a consistent experience when you're trying to communicate both internal to your organization as well as external. It's also now one of the things that is very common is taking a look at different delivery models for communication.
Once upon a time, a lot of people were everything was premise-based, but you still had voice services from what used to be the cloud, before it was known as the cloud, a Simtrex-type offering. You had premise. You had a cloud or a service provider-offering, and now you have these hybrid situations where some of your communication technology is at the customer premise, some of it is in the cloud provided by your service provider, or maybe you're your own service provider where you have developed your own private cloud infrastructure, and deploying some or all of your applications that way.
One of the things that we didn't have to deal with much in the past was how do you bring all of that together? How do you bring together a premise and cloud -based solution set so that those are unified as well? Mobility is becoming a bigger and bigger issue as our employees, whether we are providing the mobile devices to the employee, or they are bringing them into the office space and they are their own private tools, mobility is becoming a big requirement within unified communications, to make sure that the mobile devices that our employees are using are supporting the communication methods that are important to us as an organization.
So, in the end, the objective to unified communications is really to improve our employee and or business productivity through enhanced or unified communications. If you look at the evolution of unified communications, it's really made up of a lot of different applications. So you, look at all of these and evaluate your own situation ,and say "how many of these do I have already?"
Everyone has one type of telephony or phone system, voice system; you probably have phone mail automated and I bet you have email of some sort. You may have a contact center, you may not, depending on your size; on down the line, there's a lot of different applications. How many people can raise their hand and say "yep, I've got all of these", "I've got 10 of these", "I've got 8 of these", "I've got 12" ; whatever the number may be, and "I bought them all at the same place at the same time". I can't see your hands raised, but I bet no one is raising your hand right now. It doesn't happen that way.
Number one, these applications tend to be acquired and deployed independently. Some of them go together, maybe when I deploy the contact center solution, I'm also deploying a IVR solution at the same time, or maybe when I deploy a new phone system I'm going to get unified messaging at the same time. Whatever it may be, some of them may be combined, but may of these are separate transactions, so you deploy them independently of each other. You tend to have different vendors that supply them to you.
The key, when it comes to unified communication, is really how do you get all these different communication tools to interoperate and work together and provide a consistent experience to my user community? That, in our eyes, is the key. Because it's multi-vendor, because they're acquired at different times, every time you introduce a new communication component, the key is then how to make sure that communication component can be unified, or interoperates with everything else that I have today, and everything else that I'm going to add in the future.
Here's from a voice perspective, large customers. This is not uncommon. A lot of time you look at this, and say "wow, why didn't they standarize? Why didn't they buy all [??] or all Cysco, or all NEC?" Some customers do that certainly for a single deployments, but as you get into multiple deployments and people grow through acquisition, you don't see a common technology deployment across the entire enterprise and you get this real mixed-vendor type approach. One of the keys is how do you bring all of that together?
So with that as a framework, let's take a look at what AVST's solutions can bring to the table when it comes to unified communications, and specifically how do you unify your communications and get everything to interoperate?
If you look at our core platform, the CX-E platform, one of the things that we did from the very beginning, was took a very agnostic approach to phone system integration or interoperability. Over the years, we've really prided ourselves in being able to integrate with any voice system, phone system that's out there. Once upon a time, that was done with a traditional PBX and key systems, and it tended to be analogue integration and SMBI integration and, maybe you emulated a digital station and acted like just one of hte digital sets off of that, a PPx.
Then came IP-type opportunities, so instead of integrating via traditional method, it was over an IP connection, and you were using SEP or one of the proprietary protocols that were out here. So, over the years, we have developed this very extensive and complete integration library, so we can integrate with over 400 different phone sstems out there, and via a number of different methods. It can be IPH, it can be [??] or one of those protocols, a [??]. Further, you can integrate to more than one voice system off of a single CX-E platform., so that we can integrate up to 10 different phone systems and different branded phone systems off of a single DXE deployment.
Emily:Actually deploying them?
Neil:Very quickly, one of the things that we're seeing in the market is people starting to look at microsoft as a voice provider and specifically what the microsoft link, or what used to be known as the microsoft communications server or ocf, and we've got some interest in understanding within our customer base and prospects how many people are looking at using microsoft link as their voice system or as their telephone system.
Q2:So, we are curious first of all if you are using link and if you could also specify if you actually, many of you may just be using link in OCS for your IM and your presence capabilities and not for tying in with your PBX. So, we're curious on that. let's see here. Okay, looks pretty good so I'm gonna go ahead and launch the results here. What it looks like, interesting actually the majority of you on this session are actually not using link.
About a quarter of you, 24% have link or OCS but no plans to use it but for voice communication and just about 10% say yes, you are using it and you would like to learn about tying it to your existent PBX. So, that's a good lead in for Tom on our next topic that he's gonna cover here.
Tom:So, specific to link, one of the things we're seeing in the market is people deploying link primarily for now link is used as an instant messaging system within an organization or maybe you've federated outside of your organization but it's really primarily used for instant messaging. It's also providing presence associated with that. We use it here internally and I joke that it's become the new dial tone or ring tone that the process is that you look on your Lync client, you see if somebody is available, it shows that they are available, you send them a quick instant message saying 'Hey, do you have five minutes for a quick conversation?'
They say 'Yep', you place a call, and it's all part of a transaction, so, rather than picking up the phone, dialing them, and reaching voicemail or whatever you may do, it's this precall transaction to negociate the 'Yep, we can talk live right now'. And that is a come use right now in addition to typical instant messaging type transactions but as far as a voice call it's that pre call setup type mechanism.
Then, other people are using it for desktop sharing and the like. Some people are using it actually as a voice system where from link user to link user it's a voice call across your IP network and there is no public network involved or no phone system involved. The link client actually becomes a soft phone, if you will. All through link. You can get all that just as a default characteristic of the link deployment. The thing that we've found our customers struggle with is how do you combined link into our existing phone system.
Although there are some direct integrations with the latest release of the PBX's a lot of people have older phone systems that would still like to do that. So what we did at AVST is developed what we call an intelligent gateway that connects microsoft link to your existent PBX.
I just talked about the four integrations we will have and this applies to all of those, so, it really does not matter what your PBX environment is, if you would like to use the link client as a soft phone off of your existing PBX, then AVST can deliver that functionality to you. It's really been delivered to two specific applications. One of the things that the CX-E product does is support of personal assistant capability. It includes a find me follow me application, such that as a user I can define a device or what phone number I want to be reached on.
And with this, you can add link as another end point or another destination. So, say I'm working from home and I want to communicate via link or I'm out of the country and I want to use link as a phone and it's all via the internet and no roaming charges type of thing. I can set up link as one of my devices to be reached, so my find me/follow me rules can be sent to link.
The flip side of that is you can initiate calls from the link clients so that link as a cell phone, I can decide to call somebody outside of my organization and the CXZ intelligent gateway will deliver that call through the PVX integration and out to the PSTN. So it's bidirectional. In essence, what it does is it converts your microsoft link client into a cell phone client off of your PVX, regardless of what your PVX is. So, that's available as part of our product. We're seeing more and more traction around the link product.
From an applications standpoint, one of the things we see is you've got UC interoperability at the bottom layer and that's the foundation of everything we deliver. And we have a number of different applications. UC voice, which is the traditional call processing voicemail, network based faxing, those applications, and many of our customers utilize those. Then UC mobile is an additional set. That's where our unified messaging, personal assistant capability, the mobile applications, speech recognition, that technology and application set comes into play, and typically has a different interop requirement than what UC voice would have.
For example, unified messaging typically would tie into an email system, and mobile ties into your iPhone and your Android sets and on down the line. And then, the third application suite is really the UC business process, where we get into custom applications that can tie our voice capability, call processing capability back into databases and applications that you have deployed in your organization. Maybe it's for notification capabilities. And those have other interop requirements, so how do I tie into my salesforce.com or my oracle database, those types of things. We'll talk about that momentarily.
If you go across these three application sets, voicemail tends to be one of our core deliverables, where most of our customers have our voicemail capability as part of their solution set. We've developed this over the years.
It's extremely full-featured, and scales really well, supports all of the alternate 2Es so if you're coming off of a legacy system, we can actually emulate the user experience of that system, so your users don't have to be retrained. We can network into other voicemail platforms using an Amos or Vpin protocal or maybe the Avia 3210 or message networking type functionality, and it's all provided with unlimited voicemail boxes, so you license the capacity of the simultaneous calls that you want to support, but you can have as many users on the system as you'd like.
One thing that we've seen come into play with the platform when it comes to just UC voice deployments, there's a lot of activity, especially with our larger customers to consolidate what they have, where it used to be with every branch office, they'd have a phone system out there. They'd have our solution out there. They'd have maybe a call center solution out there. Call accounting.
They'd have one of everything, and there's really been a drive to consolidate that, centralize it, put it into a data center. Virtualize the solutions, and then serve them up to the various locations. A key part of that is providing high availability disaster recovery, remote survivability, so that if you're going to consolidate it all, and all of the locations are going to be dependent on that, make sure you have the disaster recovery, high availability components in place to ensure you're going to have that high up time of delivering the application, so this is a core element of the CX-E platform as well.
Moving on to some of the UC mobile applications, specifically unified messaging; here's a big interop component where unified messaging, by its nature, is really bringing things together that were delivered by different vendors at different times, if you will. Typically what we find is that people will either have a customer premise-based email system like Exchange, or Notes, Domino, Groupwise; those types of products will deployed at the customer premise. Or, what we're seeing more and more of now is customers moving that environment out to the cloud. I'm going to stick with Microsoft and use Office 365, which is really exchange the cloud being managed by Microsoft or a Microsoft provider. Or Gmail, so Google mail in the cloud being managed by Google, where your IT resources aren't having to do that.
When you think about unified messaging, regardless of whether it's at the customer premise or it's a service-oriented deployment, you still have interoperability needs. Being able to operate or integrate the voice solution into that email environment is the key. What we've done, same approach as what I described with the phone system ,it's really an agnostic approach, where we don't care what the email system is or where it's housed, we can still provide unified messaging. To that point, one more poll question. Looking for some indication as to whether you're already moved your email into your cloud, or you have plans to move from the customer premise to the cloud, so I'll toss it back over to Anne.
Anne:the question should be displayed there, so as Tom mentioned, whether you've already deployed your email to the cloud, Office 365 or something similar, if you have plans to deploy an the time frame, or maybe you have no plans to move your email to the cloud. So, it looks like we have just over half, so we'll give it another second or two. Okay, we'll go ahead and look at the results. It looks like actually over half have said that they do not have plans to move email to the cloud. So, that 57 % is no cloud email plans, about 16% have either already deployed it or plan to deploy it over the next 12 months, and just over 10% say they would deploy it in the next year or two.
Tom: Okay, great. So, just as a followup to unified messaging, just to make sure we are all on the same page. Unified messaging really is the unification of different message types. Typically, that is voice, email, and fax. Someday maybe video mail will be there if people start leaving video messages or sending video message,s that will be a component. But today, primarily you find is email, voice and fax all consolidated together through these same interface. That interface could your email client, could be a web client, could be over the telephone where you're listening the email in addition to your voice message and you're using speech commands; whatever it may be. It could be your mobile device - very common today to access all your messages.
With our deployment as mentioned, it's very agnostic, so it really doesn't matter what your back end is on the email side or where it is housed. As some of you are moving intro the cloud, we can still provide unified messaging, support multiple email servers. The larger organizations, many of our university customers have different and multiple email servers. Lots of flexibility on do you want to store everything on the email system, so voice, fax, everything goes into the email store. If you want to keep everything separate and integrate out at the client level, lots of different options for that. You want to push this out to your mobile devices, if you want to use voice mail to text capabilities, where the recorded voice messages transcribed in the text and sent to the user so they can read it rather than listening to it, if they aren't in a position to actually listen to the message.
Text-to-speech to convert your email messages into audio, so that someone can listen to them over the phone while they're driving down the road. All of those things are considerations when it comes to unified messaging and everything supported by our platform. On the mobile client side, another key piece the UC mobile, our UC mobile offering . . . more and more people are using smart phones, whether, you know, they are personal devices or they are company provided. What we've done is developed applications for both the Iphone and the android devices. We deliver a number of different applications. These are all delivered by the app stores and integrate into the phone natively. So, they are native applications that behave and act just like any other application that they've downloaded from the various app stores.
What we've done, is that, a lot of people are using a mobile phone for both business and personal communications, but they'd like to keep them separate. What comes natively with the phone from your phone provider, I'm using that for personal business (no pun intended), and then our application is used for your true business or company communication, so that you'd separate them. You can have separate address books if you'd like; separate message logs; missed call logs. All of it is separate, so you know these are personal communications, these are business communications. One of the keys to this, is we don't store any data on the device itself.
So, if the employee loses the date, if they leave the company, there is no company-owned asset that actually leaves with them, or leaves with that phone. From an application standpoint, you've got managing of calls. You've got single number reach, mobile number protection so people that want to use their mobile number, but they don't want to hand it out to people, so that all calls route through the main business phone number.
Transferring of calls from one device to another. Visual voice mail type capabilities, and then user preferences. All of that is supported through this mobile app, that's available as part of our platform. Okay Moving on the last applications segment. It's really the application data base interoperability. This is the UC Business Process Section. We talked about interoperability to your voice deployment, your voice infrastructure. We talked about it to your email groupware-type environment. This is the final piece which is the integrating into your back end data bases.
This could be your financial operations, accounting operations. It could be customer records, so, CRM-type solutions. Whatever it may be, people build out applications that are voice enabled, call processing enabled, tied into those back end data bases. So, what we do is, we provide an open development framework so you can build custom applications, or have us build them for you, that integrate into your back end data and provide access to that through a web service, or through a voice-type portal so that your customers could call in, or your vendors could call in and access information. They can receive notification automatically of events that have occurred within your operations. You can click to call enable your applications.
There are a lot of different possibilities here that tie our platform and what it does, which is, voice, audio, notification, call processing. Those types of functionalities integrate those in or communication enable your back end business processes.
So, to give you one example of this, a lot of customers use an outbound notification capabilities where you can tie our platform into a back-end process that says "I need to notify people and give them custom information, or specific information for them, and I need to, to be automatically initiated." So here's an example of a doctor's office, where they call you for appointment reminders. Well, each call is unique, where I will be reminded of one time appointment, somebody else is going to be reminded of another time that their appointment is.
You may want them to be able to talk to somebody live about the appointment or change their appointment. Those types of things can all be customized through this. So, it's a custom application that ties into data that you provide, but it's using out platforms capabilities to complete and deliver the application.
Other examples, you go across various industries, and information access is a bit thing. Certainly people today are used to going to webpages and pulling up information, but frankly not everyone has access to a computer or a website, and so providing alternatives to that.
Historically, IBR type applications did exactly this, and it was all over the phone access to a company's process and data and information. So you look at the various industries and we have a number of various applications out there, within healthcare to be bill or claims status, within education it could be access to course information, government, it could be, there's local, state, federal government, it's constantly being accessed by their constituents to gain access to information, so this is an ideal technology to do exactly that.
Enterprise, this was originally known as "bank by phone" within the banking industry. Account balance inquiries, those types of things. Anything where you're trying to provide access to information that you hold within your company and you want to provide access to your external customers, prospects and vendors, whatever it may be. Ideal technology to do exactly that. If you look at interoperability, and it comes to unified communications, there's a lot of different components out there.
Certainly on the telephony side, there's all sorts of vendors and people are moving through generational changes of these systems, and how you interoperate changes, depending on if it's a 20-year-old realm system or is a brand new shorter system, or Microsoft link has a phone system. On the email side, again, email's been around for a long time, but we're seeing changes there as it moves from customer out to the cloud. Instant messaging. People are deploying instant messaging more and more, and how can you utilize the present information that's housed by and controlled by that instant messaging server, and use that for other purposes.
Conferencing systems, calendar, mobile devices, databases, all these different things that are employed within companies, how do you bring them together, and one way is to depend on an integration specialist like ABST or an interop specialist to be able to bring these together and utilize the information in your communication infrastructure. We believe we've done a nice job of that with our CXZ platform, which is our hallmark platform.
As I mentioned, delivers three different primary application suites, the UC mobile side, the UC voice side, the UC business process. You can decide what you want to deploy and when, and then underlying all of that is the UC interoperability layers. By themselves, those applications do very little. It's not until you actually integrate or interoperate with the other components that you have in your organization that they really start to take off.
So, as far as takeaway, we believe, the thing we hear over and over again from our customers, things they're worried about is, certainly cost control and enhancing productivity and anyone can say that. They want to avoid single vendor lock-in. So, because there's so many components involved here and they change and vendors focus on some and then change their focus, they really like the "I don't want to depend on just one vendor for everything." I want to have more in my stable of vendor pool to depend on. I want to deploy best of breed.
So, rather than utilize mediocre solutions from somebody that's providing a broad base of applications, I'd rather take the best and brightest from different vendors and bring them together. We see a lot of people migrating from legacy solutions to new UC and (?). But it's not a rip and replace-type thing. People want to do that at their own pace, so there are individual transactions that are taking place and the focus is on INTERROB. We are seeing a lot of link getting deployed and people starting to look at that as a voice solution. So, helping people with that.
Delivering a consistent interface across evolving environment, so, things are changing. And so, you need to make sure that what you deploy really is highly interoperable moving forward. Standards-based, so you're being locked into proprietary-type approaches. And then, the ability to create your own applications. As vendors, we tend to focus on the specifics that we deliver. But if you're going to invest in UC platforms, you really want something that's open that you can develop or have somebody develop custom functionality for you. So, with that, I'll be quiet and turn it back over to Ann to open up for the Q&A section. I really appreciate you spending time with us, today. And hopefully, we can answer some questions here for you.
Anne:All right, thanks, Tom. And just real quickly, before we move to the questions. For those of you who may have missed the first couple of minutes, I want to let you know that we will send you a link to download the slides just after we conclude the webinar. And in addition, we did record this. So, once that recording is available, we will follow up via e-mail as well, so that you can go back and listen to it if you're interested. And then, if you've got your webinar panel minimized, the orange arrow in the upper corner will reveal the question toward the bottom.
We do have lots of questions coming in. And I'll let you know, if we don't get to your question on the live session, please be assured that we will follow up with you offline and a sales engineer will follow up and answer your question. The first question, Tom. "On e-mail, if a customer is transitioning from exchange to Gmail in the Cloud, for example, would we support both of those systems during the transition time"?
Tom:Yes. So, we can support multiple e-mail systems off of the same platform. Depending on how you deployed the solutions, you may get into a situation where, without looking Exchange, we have some custom outlook forms that are available to you. And those require specific message class. So, not to get into too much detail here. But if somebody e-mailed a voice message from Google to Exchange, it may not pop up our form. Because it didn't happen message class, but they'd be able to see it.
They'd be able to play the message, all that kind of thing. So, when you get into a mixed environment, you have some reduced functionality. But if it's a transitional thing, then yes, absolutely. You're going to be able to transition from one to another and support both at the same time.
Anne:Thanks, Tom. There's a question here about the iPhone app. "Does it work on the iPad or are we going to develop a solution for the iPad"?
Tom:So, it does work on the iPad. The iPad itself, natively, isn't a phone. One of the things that the application does is if you've got an incoming call, you can have the app pop up on your device. So, that could be on your iPad or your iPhone. And then, if you want to take the call, it needs to be delivered to a phone. So on an iPad if you had a soft phone running on that iPad then you could deliver it to that. Or maybe you, you take the pop-up on your iPad and deliver it to your home phone. Or whatever it may be. That functionality works but there's got to be a phone associated with the device to, to actually do everything that we do through that application.
Emily:Okay. And then actually a follow on question to the first one which was regarding the multiple email servers. The example of Exchange and also Gmail. Can we send the voice messages to both systems at the same time? So it sounds like if, if the user has an account on both.
Neil:You could. So we-, that'll get in to how the messages are being delivered. But you could set up-, you could have multiple SMTP accounts, where we send it to both places. There's probably multiple ways to accomplish that. But yes, a user could have it sent to two different places if they wanted to.
Emily:Okay. Next question. Is there a limit to the number of different telephony systems that AVST can integrate with for different PBXs?
Neil:Yeah. So I assume that's off of-, the question is based off of a single deployment. So if you, if you have CX-E deployed we have a couple of limits. One is we have a-, something called a call server. And that's what actually houses the, the telephony integration and some of the applications are, are running off of that. For each call server there's a limit of three different integrations. That doesn't mean that-, say that you have five PBXs. And they're all the same.
To us that's a single integration, just five different integration sections or switch sections. But if they're different disparate PBX solutions then we'd be limited to three per call server. And then we can have multiple call servers. So across the call servers you can have up to 10 different integrations. So 10 different branded PBX environments. You could have multiple of, of the same and that wouldn't count across your ten. Hopefully that was understandable.
Emily:Okay. And I'd just like to thank everyone again for taking the time to join us this morning-, or this afternoon. And we'll look forward to seeing you on another Webinar again very soon. Thanks everyone. Have a good day.