The 'Religious' War Brewing in Unified Communications Security

I am surrounded by zealots. No, I am not talking about organized religion. I am talking about tech zealots. You know the type: Mac vs. Windows.  Firefox vs. Chrome.  Android vs. iPhone.

My latest struggle: those who proselytize where your Session Border Controller (SBC),  the heart of any company’s Unified Communications security setup, should go. Does it belong on the network edge or within the DMZ behind an enterprise firewall? You might think that this would be a fairly straightforward decision, but I’ve found that the “experts” fall into two opposing camps.

Camp One – Sitting on the network edge

The argument employed by these folks is that an SBC is a standalone security device.  It was designed to keep the bad guys out and let the good guys in.  An SBC is a Back-to-Back User Agent that does a deep packet inspection of every SIP packet that enters or leaves an enterprise’s network.  It can detect and reject badly formed or suspicious SIP messages.  It can stop denial of service (DOS) and distributed denial of service (DDOS) attacks.  It can detect bad login attempts and block hackers.  An SBC maintains a blacklist of malicious IP addresses and prevents rogue users from accessing your communications system.

In other words, an SBC is a SIP firewall.  It does not need a traditional data firewall to pre-process packets before it sees them.

How the SIP messages get to the SBC depends on the network topology.  If the SIP packets arrive on a dedicated WAN connection then you simply send everything straight to the SBC.  However, if SIP packets share the same WAN connection as other data packets (e.g. HTTP) then some sort of VLAN separation is necessary.  One VLAN would be dedicated to SIP and the SBC and the other VLAN would be used by the data firewall.

Camp Two – Behind an enterprise firewall

In this case, SIP traffic hits the data firewall before being passed to the SBC.  It’s important that any and all SIP processing be disabled within the firewall.  By this I mean that all “SIP detection,” “SIP inspection,” and “SIP ALG” must be turned off.  Anything that arrives on ports 5060 (SIP) or 5061 (TLS) will be sent directly to the SBC for processing.  The SBC will direct the firewall to send all subsequent RTP and SRTP traffic to the SBC.

Once the SIP traffic has been handed off to the SBC, all the “Camp One” benefits are realized.  A data firewall does not inhibit an SBC from performing its role as a security agent.

There are multiple arguments employed by the Camp Two people to state their case.

First, most modern enterprises already employ a DMZ flanked by internal and external firewalls.  A session border controller should fit into a standard security architecture and not be treated as an anomaly.

Second, security should be applied in layers and SBC features are just another layer in a comprehensive and cohesive security process.

Lastly, as enterprises move from basic SIP trunks to remote SIP users, protocols beyond SIP become necessary.  The data firewall will handle the non-SIP protocols and the SBC will deal with the SIP aspects.  The remote user sends all its packets to a single IP address and the firewall acts as the traffic cop.

My thoughts

I understand the arguments on both sides and appreciate their thoughts and concerns.  To me it comes down this:

  • If an enterprise’s policy is to send everything through the DMZ and corporate firewall(s), then do so.  Firewalls and SBCs can be configured to play together nicely.
  • If you are using remote users that require more than SIP to function properly, put the SBC behind the firewall.  Let each security element deal with what it knows how to deal with.
  • If you are only looking at SIP trunks and have no strict DMZ policy, put the SBC where it makes sense.  Separated SIP and non-SIP data circuits make it easy to decouple an SBC from the data firewall.   A single data circuit requires you to either implement VLAN separation or configure the SBC and firewall to work together.  Pick the configuration that works best for you.

Let Us Pray

As I said in the beginning, some of this is religious, but there are also practical reasons as to why you would go one way or the other.  Like most things in life, don’t approach this blindly.  Think about what you are trying to accomplish, adhere to existing policies, and make an intelligent choice.

Can I get a witness?

* * *

This article originally appeared on Andrew Prokop’s unified communications blog, and is reprinted with permission.

Related Articles:

Q&A: Arrow S3 on History, Pedigree and Innovation

Earlier this month, I attended the Wisconsin Avaya Users Group State Conference, where I had the chance to sit down with Arrow S3 executive David Lover, to talk about his history with the company (which is a major Avaya partner), what they’re focused on right now and their 5-year vision.

Fletch: Hey, it’s Fletch with the Avaya Podcast Network. Welcome to Tech Talk. We’re here at the Wisconsin Avaya Users Group, and we’re sitting down with vice president at Arrow S3, David Lover. How are you?

David Lover, Arrow S3

David Lover: I’m good, man. It’s been a while. I think the last time I saw you it was about this cold.

Fletch: It was about this cold up in your neck of the woods.

David Lover: Yeah, absolutely.

Fletch: Apparently, your company doesn’t work in the heat, at all.

David Lover: I don’t know what it is, but I always find people want me to come visit them in the extremes of temperatures. I’m in the Northern states in the winter and the Southern states in the summer. I’m like, we’ve got this backwards.

Fletch: Yeah, you definitely do. Arrow S3 is a reseller, technically, but you guys are a lot more than that, David. You’re really an integrated solutions partner.

David Lover: Big time.

Fletch: You guys, I think of it this way. You guys look at delivering value out to the distributors and to customers using our DevConnect partners, but if it doesn’t exist, you’ll build it.

David Lover: Yeah. You find very quickly that there isn’t one vendor that delivers end-to-end solutions. We find that–your first thing is, as a reseller, and that’s one of the things that I work on quite a bit–is to try to round out the portfolio, to make sure that we’ve got all the right pieces in our portfolio.

But you find out that… boy, the cool stuff doesn’t exist. So okay, either you have to find somebody who makes it or you have to make it. And so, we do that all the time. We have a team of developers that, if we need to come up with something creative, we’ll do it ourselves.

Fletch: And Arrow S3 is really a culmination of a lot of companies, now, right?

David Lover: It kind of is, yeah.

Fletch: It’s merger upon merger. What are all the different companies that make up Arrow S3.

David Lover: I started with Cross Telecom, which a lot of people know as one of the big players in the traditional Avaya space, and there’s Shared Technologies, which was one of the big players in the Nortel space.

That’s how Arrow Electronics, who’s a huge distributor of electronic components, one of their divisions happens to be in the data center space, Enterprise Computing Solutions, or ECS. They’re actually the ones that wanted to kind of get into the unified communications space. So they first acquired Shared Technologies, and then more recently, Cross Telecom.

That combination is actually great because Cross has the legacy Avaya expertise and strong professional services integration in the contact center world (along with UC) and then Shared Technologies was really about maintenance managed services, which a lot of the Nortel business were at that time. You tie that together. You tie the fact that Arrow, ECS, or Arrow Electronics, is big in the data center space. You bring those three together, you have everything.

You have not only the solutions, the integration, the managed services, the maintenance, potentially the hosting, end-to-end. Tie that in with application developers and you’ve kind of got the whole package.

Fletch: Sure, and with Shared Technologies and Cross, you kind of had the same business mantra, I’ll call it.

David Lover: Kind of, yeah.

Fletch: Really caring about the customer. A company that you weren’t just a number there. The customers were really ingrained in the company.

David Lover: Cross Telecom was, it was one guy, Bob Coughlin, who started it all in his basement and just over the years grew it and grew it and grew it and grew it and all of a sudden it became this huge company.

Fletch: Sure, and Shared started with Standard.

David Lover: Yeah, exactly.

Fletch: I remember back in my days at Bell Atlantic, we used to ride around laughing at those guys in their rat trap vans that they would drive around in, and it’s like …

David Lover: Fast forward! You pay your dues, right?

Fletch: You pay your dues.

David Lover: You pay your dues and you have a good product, good service, customer satisfaction, and literally, that will take you everywhere. The trick, obviously, to stay relevant, because back in the old days you could look at a PBX, literally you could point to a PBX and you knew exactly what it was, where it was, what it did, and you could probably point to the whole thing with one finger.

Now, it’s spread all over the place. You’ve got directory services here. You’ve got your session management somewhere else. You’ve got your feature servers over here. You’re dipping into databases that are over there, and to be able to have the whole package, again, all of those pieces we had talked about, it’s not the option.

I look at it, and I’m like, how would you survive without having all of those areas of expertise? Unless you’re a traditional voice person and that’s all it is, I don’t know how you survive without the rest of those things.

Fletch: Yeah, right, and spare parts don’t even exist anymore.

David Lover: Yeah, it’s a crazy world.

Fletch: It definitely is. You guys are on the forefront of everything. The Collaboration Environment has got to be exciting to you guys, I would think.

David Lover: Yeah. Again, and all the way back to the various iterations and history of it, too. The Collaboration Environment really, from my perspective, I’m a huge fan of Avaya’s SIP portfolio. Starting with Session Manager, being IMS based, IP multimedia sub-systems, really allowing you to get in the middle of call flow with this concept of sequenced applications.

The concept is great but you look and you see not a lot of customers leveraging it. It’s a carrier concept, and some of the creative people–whether it’s the resellers, the integrators, the customers–but it has to be tied to the business to be interesting and again, relevant.

What we’ve found is you need somebody very, very smart who can put those pieces together to really maximize IMS. Collaboration Environment makes that a heck of a lot easier because they’ve taken the fundamentals of application development. You have to worry about scale. What happens if this actually takes off and a lot of people start using it? That’s a very different way of writing software.

Fletch: Sure, it is.

David Lover: You have to be able to scale big and the same way, security, and all of those things. It’s not just about writing the application. It’s about making sure it’s going to work in real life, and Collaboration Environment says, “Hey, how about we focus on making sure that it scales, it’s secure, it’s all of these things and give you a set of APIs that really let you leverage the features, the capabilities?”

You can harness and focus your creativity on the parts that are front-and-center. They’re the sexy things. Scale, everybody wants it but nobody necessarily wants to think about it.

Fletch: That product has gone through its iterations, as well. Version 1 was kind of a proof-of-concept, so to speak. I’ll call Version 2 a deployable prototype, but Version 3 is really where it’s going to come together.

David Lover: To me, it’s all about the contact center, where that’s probably one in the telephony world, the killer app in telephony is still contact center. It’s where you can justify the very deep integrations and whether it’s data dips into that info or you’re building from, it’s where you find ROI.

ROI is easy in the contact center, if you do it right. Version 3 with Collaboration Environment really is about the contact center, and we’re seeing some really cool kinds of things there. So I think that’s when it’s going to really take off.

Fletch: I think the, we do a lot with Next Generation 9-1-1 stuff. I see WebRTC and Collaboration Environment, I see those being major disruptors to Next Generation 9-1-1, because you can almost deploy it without deploying Next Gen 9-1-1 in the network.

You remove that carrier independence and man, while that could be a scary thought, it’s an interesting one that would really on-ramp that whole …

David Lover: It decentralizes everything even more. Just when you think, boy, it couldn’t get more decentralized, now all of a sudden WebRTC, truly empowering at the browser level to take ownership of some of those things.

Avaya’s certainly done their versions of that with OneTouch Video, where it’s a Flash-to-SIP gateway, which that was the closest thing we had to a web browser. Granted, it was still a plugin with Flash, but you could kind of count on everybody having it.

We know Apple doesn’t, the iPad doesn’t support Flash. So using truly that seamless connectivity and interaction just isn’t there when it comes to Flash the way we need it to be.

WebRTC just has the opportunity to change all of that and really empower the individual clients and devices. Like you said, in one aspect, it’s a no-brainer and then in the other, it’s just mind boggling as to what the potential is going to be. Just when we thought it couldn’t get weirder, this is going to change everything.

Fletch: That’s got to be something that’s tough with your job, David. You’re with the Office of the CTO. You’re in charge of strategy and technology and vision and all the CTO words that we use. How do you stay on top of all of this?

David Lover: It’s hard, and it’s the balancing act that is the hardest, because if you go too far ahead, you’re relevant. People, they view it as science fiction and they’re like, “Yeah, that sounds great, Dave, but we still have our day job.” And absolutely. You have to make today’s stuff work, but you have to to be thinking about the future and you have to be thinking forward. I don’t know. The way I do it, I don’t think it’s rocket science. You’ve got to stay on top of things. You’ve got to talk to a lot of people, because it turns out, there’s a ton of smart people in our industry.

You find out what’s in their head and you just try to, you find trends and you’re like, “Boy, I’m hearing this topic, over and over and over again.” Every once in a while you find a nugget of something that’s like, wow! Why doesn’t anyone else know about this? I don’t know. It’s surrounding yourself with similar-minded people that are trying to find that balance. I love to find the people who are six, seven, eight years out, but holy smokes! Sometimes I’m like, “What are you thinking? That’s so far away.”

Fletch: The one thing that I’ve seen and your marketing people are going to love me for this, but one thing that stuck with me is your 10-year-out promotional …

David Lover: Five years out, yeah.

Fletch: Or your five years out … It was so good I gave you ten.

David Lover: I even look at five, I’m like, leave it to a marketing person to try and think five years out. Five years out is an eternity!

Fletch: That was an interview question. When I went to work at UBS Swiss Bank, the guy said, “Where do you see yourself in five years?” I’m thinking, my God. If I’m still here, then I haven’t done a good job.

David Lover: Right. Five years is a ridiculously long amount of time in today’s world. Obviously, 15 years, 20 years ago, five years was nothing, but today it’s just crazy…

Fletch: How do you plan? Knowing that five years out is certainly a goal that’s got to be there, but it’s not realistic, how do you plan around that?

David Lover: I think you find… I guess I don’t look at it in terms of years. I don’t try to, and again, this is probably a difference of me as a technologist versus a finance guy. Probably finance people are looking at very discreet yearly things. I don’t. I look …

Fletch: That’s why I don’t get along with finance guys. They want to make it all pay for itself. I’m like, I just want to make it work.

David Lover: I want it to be relevant. Find out what you want to be, whatever that is. For some people it’s a year. Some people it’s five years. Some people it’s three years. Again, I don’t like to think of it in terms of time, but what do you want to look like? Is it what your competitors are doing? Is it bringing a new level of innovation to your business?

Whatever that is, and then try to work backwards from there and say, “Okay, this is where we are today,” which I find a lot of people aren’t, they don’t always exactly know where they are today, even, but if you can match up today with where you want to be tomorrow, now all of a sudden it becomes a pretty easy thing to just, it’s a step-by-step approach and follow your plan. But the first thing is to have a plan so you can follow it.

Fletch: At the Evolutions events we had a lot of great speakers that came in, and I had the great opportunity of sitting down with Guy Kawasaki, and when we were talking about different stuff there, he was like, “If you make the best teletype, you need to be thinking about the best computer. If you make the best telephone, you need to be thinking about then next video technology.” That’s how you stay ahead, is to stay on the curve.

David Lover: Yeah, and the interesting thing about that is you don’t always get to know that from asking your customers. Sadly, this is the weird part. One of the best quotes I ever heard when talking about disruptive innovation, is from Henry Ford.

If he were to go ask his customers what they needed, they would have said, “Well, I could really use a better buggy whip,” because that’s, “I just need a better buggy whip.” That might be innovative, but it’s not disruptive innovation by any stretch of the imagination.

Fletch: That’s interesting. I like that, David. That’s good.

David Lover: It’s hard, because again, it’s about being relevant, so you’re not viewed as some social outcast, but at the same time, pulling people forward, to say, “I don’t know if I should always ask you what you want. We should, hey, this is something different.”

Again, I’m sure most people have heard or read “The Innovators Dilemma”. A great book that kind of talks about disruptive innovation and what it really takes. It’s along those lines that you’re describing of you have to be thinking not just forward but to your side and forward at the same time.

Fletch: Right, on the next curve.

David Lover: On the next curve. It’s a different curve. It’s not step two. It’s something different. That gets pretty hard.

Fletch: That was Guy Kawasaki’s message. It’s not the next curve, it’s the next different curve.

David Lover: It’s a different curve, yeah.

Fletch: That’s amazing.

David Lover: You certainly know the people who are brilliant at that, from the Steve Jobs and everybody else that you’re like, “Where did they come up with that?” A lot of times it was old ideas but in a completely different context. It’s just finding relevance in new areas. It always comes back to relevance, yeah.

Fletch: It’s always good to talk to you, David. I’ve seen a lot of stuff around Arrow S3, and people don’t know the entire width and breadth of your company.

David Lover: That’s, I don’t know if that’s good or bad. I guess it’s good that you see us as how we are and yeah, we probably have to do a better job of explaining those.

Fletch: But you’ve got your fingers into a lot of stuff that’s around the whole industry, and that just drives the thinking, the innovation, the technology. Someone like yourself who’s there that can see all that and pull it all together, you do a great job at that.

David Lover: It’s a team. It’s a big team of people and it’s just brainstorming and everybody sharing their ideas. I think we do a good job of it, and we kind of see the bigger picture of what needs to happen. Again, we got to keep the lights on. You always have to keep the lights on, the day to day, what you do, but you’ve got to be thinking about the future, that’s for sure.

Fletch: For you to come out to a… this is a relatively small show in the large scale of things. It’s an important show, a bunch of great users here, but to have a VP come out … it’s close.

David Lover: It is. It’s close. I’m from Wisconsin, so it’s old home week for me.

Fletch: But still, just to acknowledge that and do that and to be here when you really didn’t need to be here, I think that level of support to the users just says a lot about you as a person. It says a lot about you as a company.

David Lover: Yeah, we’re big into that concept of helping our customers be successful. For me, it’s about education. It’s about knowledge. I’m convinced people who have the right information will always make better decisions. Our hope is that they make those better decisions with us.

Fletch: That’s what I was saying before. The root of Cross, the root of Shared Technologies, having that same company mantra on the backend really, really shines through, and I think that’s, in my opinion, that’s a key to your success.

David Lover: I agree, very much agree.

Fletch: Listen, thanks for sitting down with us. I really appreciate it.

David Lover: Thank you, man.

Fletch: We’re talking with David Lover, who’s the Vice President Strategy and Technology in the office of the CTO at Arrow S3.

Want more technology, news and information from Avaya? Be sure to check out the Avaya Podcast Network landing page at There, you will find additional podcasts from industry events, such as Avaya Evolutions and INTEROP, as well as other informative series by the APN staff.

APN Blog Banner

Thanks for stopping by and reading the Avaya Connected blog on E911. I value your opinions, so please feel free to comment below or, if you prefer, you can email me privately.

Public comments, suggestions, corrections and loose change is all graciously accepted 😉 Until next week. . . dial carefully.

Be sure to follow me on Twitter at @Fletch911


For Unified Communications Pros: How to Record Calls with SIPREC

“This call may be recorded for quality assurance.”

It’s nearly impossible to call a contact center without hearing that message or something very similar.  A company will record calls for a variety of reasons.  It may be to help improve customer service.  Supervisors listen to their agent’s interactions for training and evaluation purposes. Companies also record calls to protect themselves.  A significant number of “he said, she said” arguments can be cleared up by simply playing a recording of the customer’s conversation.  There are also situations where call recording is required by law.

I began my career well before SIP and remember trunk-side recording with TDM taps.  These taps were devices that split a T1 into two links.  One went to the PBX and the other to a call recorder.  They were effective, but required one such device for every T1 line.

With the advent of SIP, we are able to move away from T1s and their channelized DS1s and DS0s to a network connection where the number of trunks is limited only by the amount of available bandwidth.

Tapping into a dedicated line is no longer an option with SIP.  Ethernet and MPLS are not physical mediums that lends themselves to hardware taps.  We need a new way to perform trunk-side recording.

As with many questions related to SIP, the answer is the Session Border Controller.  It is, after all, the device that sits between the carrier and your enterprise.  Can you think of a better place to “tap” into a SIP call and simultaneously send it to a call recorder and your communications system?  I can’t.

To help the SBC with the job of call recording, the IETF (Internet Engineering Task Force – the folks who manage SIP and most of the Internet protocols) came up with a framework that manufacturers of SBCs and call recorders can follow.  Session Initiation Protocol Recording, or SIPREC for short, defines the architecture, associated call flows, and metadata that can be used for call recording.

SIPREC identifies two players involved in call recording – the Session Recording Client (SRC) and the Session Recording Server (SRS).  Although SIPREC doesn’t limit the SRC and SRS to specific entity types, for the purposes of trunk-side recording, it is safe to say that the SRC is an SBC and the SRS is a call recording platform such as Nice.

The following diagram shows the relationship between the different entities.  Note that SIPREC message types are only applicable between the SRC and the SRS.  Normal SIP messages are sent between the SBC and the SIP carrier and the SBC and the communications platform.  Also, although I have shown a SIP telephone inside the enterprise, there is no reason why it needs to be SIP.  It could be any telephone type supported by a SIP communications system.

There are no new SIP message types to support SIPREC.  SIPREC utilizes common messages such as INVITE and BYE.  The big change lies within the message body of those INVITE and BYE message.  As is expected with all SIP call flows, Session Description Protocol (SDP) describes the session’s media (e.g. G.711 or G.729).  In addition to SDP, the message body of a SIPREC INVITE contains a second part.  In SIP parlance, this is known as a multipart MIME message body.  The first part of the message body is SDP and the second part contains SIPREC metadata.   This metadata is used to convey information that is specific to the process of call recording.

The metadata of an SIPREC INVITE is formatted as XML data.  This means that there will be tags that define the start of a section of data and tags that define the end of a section of data.  For example, a participant might be encoded as follows:




        <name xml:lang=”it”>Bob B</name>



A SIPREC INVITE will typically contain information about both participants in a call and descriptors for the recording session.  A SIPREC BYE will contain similar metadata to stop and archive the recording.

I am not about to present all the gory details of SIPREC metadata, but I can direct you straight to the source.

It is important to know that SIPREC is still in draft form and has not been ratified by the IETF.  However, a number of vendors have already begun to adopt it in anticipation of its ratification.  Among the SBC vendors, I’ve seen Sonus, AudioCodes, and Oracle Acme state their support for SIPREC.  Among the call recording platforms, I’ve seen Oracle Acme and Nice.  This doesn’t mean that other vendors don’t support SIPREC.  I simply haven’t run across documentation stating their acceptance one way or the other.

I have just discussed SIPREC as a mechanism for trunk-side recording.  However, there is nothing to say that it cannot be used for station-side recording, too.  Of interest is the Avaya SBC which is being positioned as both an edge and internal security device.  If an Avaya SBC was positioned between all SIP endpoints, it could easily use SIPREC to perform call recording for station to station calls.

Stay tuned for further developments.


This article originally appeared on Andrew Prokop’s unified communications blog, SIP Adventures, and is reprinted with permission.

How Unified Communications Can Make Multitasking Work for You

multitasking man

I sometimes feel as if interruptions define my work life. My days are an endless stream of emails, instant messages, SMS text messages, telephone calls, and voicemails.  They are all like doorbells that won’t stop ringing.  As soon as I respond to the first, the next visitor is at the door demanding my attention.  I could ignore the bells and knocks, but how would I know that I wasn’t missing something extremely important?

I’ve come to realize that unless I quit my job and sit at home watching soap operas, this deluge isn’t going to change.  So, instead of constantly complaining, or allowing my productivity to come to a grinding halt, I do what I can to make those interruptions meaningful.  In other words, I allow the important interruptions to capture my time and energy and I send the less meaningful, or meaningless interruptions to the back of the line.

The trick to adding meaning to interruptions is finding the relevant context of those interruptions.  This allows me to categorize, prioritize, and appropriately manage the barrage of communications mediums that fill my day.

We already do this to some extent with email today.  First, there is the subject line that may help me decide at a glance whether this email is important or not.  Next, there is the preview pane that gives me the first couple of lines.  There are also the disposition indicators such as forward or reply.  All of these allow me to discern the context of an email without having to actually read it.

Those same categorization aspects can be applied to other forms of communications.  Imagine knowing why your phone is ringing before answering it.  We already have calling line and calling name identification, but they are only the tip of the iceberg.  Knowing that Mary Smith is calling is important, but it doesn’t tell me why she is calling.  Did she pick up the phone and simply dial my number?  Did she do a click-to-call from an email I previously sent?  Was it the email that asked for last month’s sales reports or the one asking if she wanted to do lunch on Friday?

Let’s take this further.  Would it help me better categorize the call if I knew that she was calling from within a document I posted on a SharePoint site?  What difference might it make if I knew the exact document?  Would I be more apt to answer her call if I knew that it was placed from the parking lot of our biggest customer?   The more I know about the context of the phone call, the better prepared I am to determine the meaning of the interruption.

Here in the age of multimodal communications you can be reached in many different ways and context can and should be applied to every one of them.  If context is important to an email, it’s more important to real-time forms of communication where time to answer and reply are more critical.  The more information you are provided at the time of the interruption the better – for you and the caller.

This kind of context processing is important to me, the desk jockey, but imagine someone who works in a high stress, life critical job.  Imagine a doctor being able to tell exactly why her phone is buzzing before responding to the phone call, text message, email, or voicemail.  Imagine how the quality of her care would go up if she were able to intelligently ignore the unimportant interruptions and spend her time responding to critical matters.

Now, before you start making calls to your favorite systems integrator, it’s important to know that not every one of these context classifications are possible with today’s unified communications products.  As far as I know, there is no system that can tell you that a call is being made from a parking lot.  However, it’s not that farfetched to imagine a time when that feature exists.  The goal of this blog is not to tell you what you can buy today, but rather what is possible and may be on the market tomorrow.

Think of how context allows you to make better decisions.  Think of how much more productive you are when you are able to sort interruptions by importance.   This is the future of communications.  This is what makes unified communications “workflow relevant.”


This article originally appeared on Andrew Prokop’s unified communications blog, SIP Adventures, and is reprinted with permission.