The Shift

In 1999, we were all talking about ‘Voice over IP’ and then came Call Manager, Unity, and a few years later IM and Presence. We’ve seen a few new features here and there, the migration from Windows to the appliance model, off-prem extension with Expressway, but by in large, it’s the same old thing that we’ve been doing for the last decade and a half. Don’t get me wrong, I’m not complaining. It’s a great thing that enterprise communications has been so consistent – and reliable – but the last 12 months has really made it obvious to me that we’re at a technology precipice, not a slow evolution.

Collaboration is going cloud. There’s no denying it. Now I’m not saying that there won’t be on-prem hardware or components, sure there will be, but why would you replicate all these capabilities customer after customer, site after site, if you can do it once, manage it once, and did anybody mention those magic words ‘recurring revenue’? With new technologies such as Cisco Spark, the recent release of the SparkBoard, hosted collaboration offerings, solutions like Tropo, etc, its all ‘cloud, cloud, cloud’. The industry has spoken, and I hear you.

With the shift to cloud, we’re starting to see other technologies starting to touch collab. Internet Of Things is one of them. As an engineer, I’m constantly reinventing myself as technology shifts occur, and in most cases that means picking up an additional skill set as opposed to leaving one behind. For me, I predict that IoT is going to be an area in which there is going to be unparalleled demand for skilled engineers, so I’m brushing up not only my electronics and communications skills, but also my development skills. As an engineer, not only do I need to understand the protocols moving our data around, i need to understand the code putting them on the wire, and the hardware interfacing with the sensors and devices under control / devices under observation. I even took some vacation time from work in the coming weeks to attend a virtual IoT bootcamp. There are a lot of players getting into this space, Cisco included, and I can’t wait to get my hands on each of their development kits to see what they bring to the table. But most of all, I look forward to the customers challenges that I’ll be faced with solving using these new toolkits….. and how to tie it back into the rest of the collaboration tools we’re already using. ;)

Times, they are a changing….

So in my last installment, I had just undertaken a bit of a digital detox – it was a great experience for me, and I’m back with a renewed energy. I’ve learned that everything I said in the previous post is true, and I’m learning how to better make communications tools work for ME, instead of making me work for THEM.

I just came back from a cruise (a work conference venue) and while networking with my peers and some industry leaders, something became more apparent to me than ever before… times are a changing.

Back in the late 90′s, early 2000′s when I was first getting into collaboration, it was ‘voice’. Voice was the new enabling technology that was about to completely change the way data networks function, and it did exactly that. Technologies such as QoS went into rapid evolution, and the apps began to ramp up features as quick as you could blink. But here we are, 2016 going into 2017, and those apps have reached what I consider to be a point of maturity. They work, hell, they work rather freaking well. We’ve all but mastered enterprise telephony. But a shift is coming – it’s already begun.

You’ve heard me say it before, and I’ll say it again. Over the next 5 years, we’re going to see technologies such as Cloud, IOT, and Collaboration merging together. Technologies such as Tropo and Spark are going to force us to stop being ‘voice engineers’ and become ‘collaboration engineers’. This is going to require us to learn new skill sets, and think differently. We’re going to be doing more that just voice VLAN’s and DSCP, we’re going to be thinking about API and functions and automation. Let’s even give it a name – for now I’ll call it ‘CollabOps’.

So what’s next for those voice engineers among us, who are aiming to become a collaboration engineer…. learn a programming language (PHP, Python, Ruby – you choose) but learn the fundamentals. Over the next few years, the knowledge we have of communications is going to be combined with these new skills, and we’re going to create some epic stuff. Stay tuned!

Twitter… and other drugs

Over the course of the last month or so, I’ve taken a step in a different social direction – I’ve deleted, yes you heard me right, deleted both the Twitter and Facebook apps from my iPhone, hence the substantially lower volume level of communication originating from me.

In my day job, I find myself interacting with lots of new people every day, but very few of them on a regular/repeat basis. Being in front of new faces every day, and not in the office much, I haven’t formed the traditional ‘work wife/husband’ relationships that many of my peers have who work in other industries; that person or group of people that know you better than anyone else, because you spend so much time together, a pseudo-family if you will.

Human beings are a social creature, and I found myself leaning on the social media channels for my daily dose of human interaction. I was replacing the gap of close interpersonal interactions in my own life with surrogate friendships forged through these channels. Don’t get me wrong, they weren’t ‘fake’ friendships, they just don’t have the same dynamic as in-the-flesh human interaction. Rather than true in-person interaction, I was living in a world of ‘like this’ or ‘comment on that’, and doing so became an automatic, almost pre-programmed response. These channels of communication had my brain at peak levels of interaction 24×7, and had become a distraction from ‘getting away from it all’ – the mental burden was tremendous! I was literally never shutting down. To that end, I owe a bunch of people an apology for being ‘in your face’ to the extent I was; it was annoying, and I’m sorry. In many ways, over-communicating had become an addiction, and was a behavior that I needed to modify.

So what’s next for me – well, I’m going to continue using social media as an avenue to interact with my peers, but I’ve got to be more diligent and controlled about how and when I use it. It’s no longer ok for me to stare at these apps all day long, all the time ignoring what was happening in ‘meat space’ around me. That was the ‘heroin’ that had me hooked, and I was mainlining it!

I will continue reading and posting, but in a much more controlled fashion, paying attention to how these technologies captivate my attention, and not letting them take control. Social media doesn’t affect everybody in the same way it did me – but in retrospect, there were warning signs. Technology has the potential to improve our daily lives in so many ways, but if you can’t put the phone down, close the app, and walk away, it’s time for a digital detox, so that’s what I’m doing.

And for now, that’s all I’ve got to say. See you in a later post!

On behing high-energy, and the ‘Cisco Live Effect’

It’s been referred to as ‘camp’ for geeks (Thanks Fish!), a technology mecca, among many other things; for me, it’s something more. My first Cisco Live (2005, I still carry the backpack) was called Networkers, and it opened my eyes to something that the uninitiated simply cannot imagine. I’ve probably attended Cisco Live some 10 times by now, or darn near close to it. There was a couple-year gap when life just got in the way, but by in large, I’ve been attending Cisco Live the majority of the time over the past 11 years. It seems like everybody has their own ‘post conference blog post’. This one is mine.

A few years into my Cisco Live experience, I signed up for this new communications tool called Twitter. It became a forum for me to bring my thoughts and ideas into a larger audience in a realtime way. Since 2009, I’ve sent roughly 26,000 tweets – some might call that high energy, and it wouldn’t be an understatement. Much of this content was generated during the course of one industry event or another; sometimes Cisco Live, sometimes a Tech Field Day event, there have also been others. Something about these events ramp me up and give me a high energy level to communicate – and often times, it’s too high.

Friends have brought to my attention (a few times over the years, actually) that at times I can be an overwhelming communicator; this is something I have to work on, particularly in those times following these events when my energy levels are still peaking. Its just so easy in the day of realtime feeds of ‘person X did this, person Y said that’ to click a button and favorite an update, or to click a button and chime in with your commentary. I know this is something that can get a little out of hand, or even come across as creepy in the wrong situation – for my friends who I annoy, I apologize; I’m working on it. I just like interacting with you people, truth be told.

All told, it’s and interesting (and unintended) consequence of this crazy connected world we live in. Our iPhones are like crack, and we’re the ones hooked. And social media is the breeding ground, because it’s where the content lies. Lesson to be learned – Perhaps we all need a bit of a digital detox from time to time.

The networking industry is NOT stuck in the 1980′s

I recently read a blog post that Greg Ferro (@etherealmind) had posted up on Twitter, and it stirred something up inside me. Joe Howard is the Technology Market Builder at Brocade (I’m not 100% sure what this means, but sounds like sales to me), and while we’ve never met – you’ve got it all wrong, my friend.

Here is a link to the article Joe published. Give it a read before you continue further.

I’ve been a network engineer for the majority of my career, and while not as seasoned as some of my peers who are pushing 30+ years, I am quickly approaching the 20 year mark. I first cut my teeth on Novell systems administration circa NetWare 3.12, installed (and later ripped out) ArcNet, Token Ring, and 10-Base-2 ethernet, so I’m not what you’d call a ‘millennial engineer’. Disclosure: These days I work for a Cisco partner, but I was a customer for a long number of years. I’m not in sales, and I’ve got no ulterior motives – these are my opinions as an engineer.

In the past 18 months, I’ve migrated my personal IT environment to a MacBook, an iPhone, and an iPad (away from Windows and Android OSs). Why? The usual reasons – better reliability and security, a superior user experience, near seamless interoperability, and they “just work.” I really like my Apple products. No wonder Apple has been the most important technology company, by a long shot, for several years.

I couldn’t agree more, Joe. My first attempt at making the switch to Apple was when the mini first came out (I actually returned it), but it just didn’t work for me – that is, not until the Intel processor. Add a couple years of product evolution and virtualization to the equation and I was sold and have never looked back. Now I own 3 or more of just about every device Apple has made, and I pretty much love them all. You’ve nailed it with ‘it just works’ – I’ve been referring to this as ‘the apple effect’. However I’ve got to disagree with much of what you have said in the rest of your article, and I’d like to call out some quotes, if you don’t mind, and argue a few points. No offense, but I see things a bit differently.

Ethernet and IP networking is embarrassingly complex, unreliable, arcane, and parochial. That results in very high operational costs, poor security/high vulnerability, and nothing close to five nines reliability.

I’d have to disagree entirely. In comparison to legacy technologies, Ethernet and TCP/IP networking has been some of the most reliable technology driving global communication over the past 30+ years. It’s gone through a consistent evolution (both speeds and feeds, as well as upper layer protocols), but one thing has been relatively constant – the concept of architecture. Designing enterprise-class networks for much of my career, I’ve seen the exact opposite. The networks I supported weren’t embarrassingly complex. They weren’t unreliable, in fact, they had some of the highest levels of availability I’ve ever seen. It wasn’t because I was some rockstar engineer, or because I bought the latest and greatest whiz-bang product – it was because of architecture and strategy. A solid design, based on solid fundamental principles, with a well-defined scope of operation and service-level. Did I use Cisco gear – absolutely (among others), but not because they were the 800b gorilla. I used it because they had an end to end architecture strategy to go with it, and following that design philosophy allowed me to get the most out of the equipment I was purchasing.

Cisco has no incentive (in any serious way) to innovate and make the technology inherently more automated, standardized, and easier to operate. Their market dominance is dependent on complexity.

Cisco’s market dominance isn’t dependent on complexity – it’s the result of decades of product development, and furthering of the architecture strategy I mentioned previously. The technologies we’re using today (and I’m not talking proprietary Cisco technologies, I’m talking industry-standard protocols) weren’t made up overnight; they underwent continual development over decades, sometimes stumbling and failing, but ultimately resulted in the production of many of the core networking technologies we rely on today to keep our networks running. Highly-available enterprise architectures aren’t ‘overly complex’ by the sheer nature of being big – in fact, its quite the opposite. Simplicity is often a dominating factor in the most reliable of networks. Simplicity in itself IS a strategy (I’m sure you’ve heard of the KISS approach) and I’ve found that when you use simplicity as one of the building blocks in your enterprise, you can reap the rewards from it.

Most network engineers have achieved Cisco certifications. Cisco trained engineers will be heavily biased towards Cisco products.

How is this any different from what we agreed upon in the opening of this post – we both love Apple products because they ‘just work’. We aren’t biased towards them because Apple makes them (not directly); we’re biased towards them because we’ve used them, and the experience we had was a good one – again, ‘the apple effect’. I’ve had that same experience with enterprise Cisco networking gear. I’ve also spent a lot of time ripping my hair out trying to make things work on gear made by those other manufacturers who only have that 3-4% market share.

Furthermore, Cisco trained engineers embrace the complexity, for the obvious reason that their skills become special, valuable and well compensated.

No, actually we embrace the reliability and consistency we experience in deploying Cisco enterprise networking solutions. When something works well, and we can do it over and over again in a dozen locations without having to worry that it “won’t work this time” THAT’s what we embrace. None of us want to spend our weekends sitting on the floor of the data center troubleshooting a production-impacting issue, we all prefer technologies that ‘just work’.

In fact, I really don’t think your article is about networking technology much at all. You’re using it as a guise for calling their baby ugly, and I’m calling bullshit. People use Cisco because it works. Am I a fan-boy – ABSOLUTELY; because time and again, as a customer and as an end user, they’ve earned my loyalty – but they didn’t do that by being a marketing machine, they did it by making available to me mature, time-tested and field-tested solutions that in most situations ‘just worked’. I haven’t given them a free pass because they were the incumbent (although it did earn them a seat at the table for conversations when the time to purchase new equipment came up), and on at least a couple occasions, I walked away from some of their solutions that seemed a bit half-baked, but those occasions were few and far between in comparison to the number of successes they’ve afforded me.

Now, you do have a few points that I agree with you on.

As SDN technology matures with time and investment, resulting automation will lower OpEx, improve operations, and enable new network services and capabilities.

I see a mixed future for SDN. In the right environment, most importantly, when the right people care about the right things and really want to take things to the extreme, I think that SDN can offer a lot. It can definitely simplify deployment of end-to-end architectures (to my point above that it’s all about the architecture, not about the whiz-bang feature of the month), but only certain audiences call for that. There will be a certain subset of customers (of which I’m not ready to speculate the percentage of) that will always be better served by a ‘KISS’ style network architecture. They don’t need automation; they don’t need orchestration – what they need is something to provide basic, highly-reliable connectivity and communications.

Insist on engineers that are network professionals, not Cisco clones. A true professional is all about the protocols and technology and operational excellence, not about a specific vendor’s products.

I couldn’t agree more – true engineering is about more than a single vendor, in fact, I’m going to leave _every_ vendor out of my response to this – vendors aside, it’s the architectures and design, the underlying technologies that enable us to build the networks of today, and will enable the networks of the future. Understanding these fundamental concepts will apply to every network you build moving forward, just like many of the skills I learned back in the days of 10-Base-2 Ethernet still apply today.

Now is the time to move beyond the 1980s and start towards a modern network world. Every serious technology executive can contribute to the advancement of the state-of-the-art, and the first step is to not automatically give that next big order to Cisco.

I think I’ve sufficiently demonstrated my point above that we’re not in the 1980’s networking world, and as a manufacturer, if you want 60% market share instead of 3-4%, you’re going to have to create something, disrupt the industry, and change the world. Begging people to stop buying from the companies who have been innovative, created disruption and changed the world – well, I’m afraid that’s not going to get you very far.

Announcing the Band – Cisco Live 2016


It’s that time of year again. The time when everybody is anxiously awaiting the upcoming Cisco Live event, and of course, wondering who the band is going to be at the CAE. Last year I had the opportunity to meet the band (Aerosmith) and had a fantastic time (Thanks!) This year, it’s my privilege to be the first to announce to you the entertainment arrangements for the CAE for Cisco Live 2016.

Cisco will be pulling out all the stops and has blocked out the entire MGM Garden Arena for this wonderful and epic event, one you won’t soon forget!


Our artist may be all about RED, but deep down she bleeds BLUE… Cisco Blue. She’s the recipient of 10 Grammy Awards, 19 American Music Awards and 22 Billboard Music Awards. She’s also been awarded 11 Country Music Association Awards, 8 Academy of Country Music Awards, 10 People’s Choice Awards, and 25 Teen Choice Awards. She is also a seven-time winner of the Nashville Songwriters Association International Award for Songwriter/Artist of the Year. As a songwriter, she has been honored by the Songwriters Hall of Fame. She also holds five records in the Guinness World Records book. Let me be the first to introduce to you, the wonderful Taylor Swift.


After the concert, stay tuned for more information about Cisco’s latest acquisition and re-branding, a blending of two companies that are bound to take the collaboration world by storm.

Seriously? It’s April 1st. Everything you just read was complete bullshit. A parody. Get it? Got it? Good!

April Fools!

I look forward to hearing about the real band for the Cisco Live 2016 Customer Appreciation Event (I sure hope I didn’t spoil anything, I’m pretty sure it’s NOT Taylor Swift) – I hope to see you there in beautiful sunny Las Vegas, Nevada! I’m not kidding about that one! Registration is still open, so get your ass to #CLUS !

CIPTV2 – I Passed!

I first certified as a Cisco CCNA in 2002, and the years since that time has seen me pursue and achieve a number of various Cisco certifications, including the CCVP (later CCNP Voice), and with the most recent test, I’ve successfully achieved CCNP Collaboration. In all fairness, the CCNP Voice to CCNP Collaboration involved the passing of only a single exam, CIPTV2. Since my certificate was set to expire in March, and no Cisco Press book is out yet (I always seem to need to pass a test before focused study material is available), I had to sort of learn on my own and figure out what I needed to focus on. It took me 4 attempts, but as of this past Friday, I’m now a CCNP Collaboration, having passed my exam!

I wanted to share some study advice on what I did to prepare for the exam – forward: there is NO NDA-breaking content here, just some tips and feedback based on the exam blueprint.

In looking at the Cisco Exam Blueprint, available here, Cisco breaks this exam down into several topic areas, shown below.

In each of these areas, there are some specific objectives you need to focus on

For Section 1 – VCS Control

1.1 Configure registration of devices
1.2 Explore the fundamentals of subzones
1.3 Describe zone plans for VCS
1.4 Describe and configure traversal zones
1.5 Describe the benefits and configuration of transforms and create call policies
1.6 Explore VCS searches for endpoints
1.7 Integrating LDAP
1.8 Explain DNS and SRV records and document requirements for SRV records
1.9 Describe how clustering and replication works and configure a cluster
1.10 Configure interworking with VCS
1.11 Configure H.323 (including gatekeeper) and SIP
1.12 Configure trunking

For Section 2 – Collaboration Edge (VCS Expressway)

2.1 Identify and configure the requirements when deploying a collaboration edge
2.2 Establish a relationship between C/Expressway E and CUCM
2.3 Document and produce requirements for firewall and NAT configuration
2.4 Describe and implement privacy and security controls for external devices and calls
2.5 Describe elements in a traversal call (H.460 and Assent)

For Section 3 – Configure CUCM Video Service Parameter

3.1 Configure DSCP
3.2 Configuring clusterwide parameters system QoS

For Section 4 – Describe and Implement Centralized Call Processing Redundancy

4.1 Describe device fail over
4.2 Configure call survivability
4.3 Configure Cisco Unified Survivable Remote Site Telephony operation
4.4 Verify redundancy operations

For Section 5 – Describe and Configure a Multi-site Dial Plan for Cisco Unified Communications Manager

5.1 Describe the issues with multi-site dial plans
5.2 Describe the differences between the various gateways and trunk types supported by Cisco Unified Communication Manager
5.3 Implement trunks to VCS
5.4 Describe globalized call routing based on URI dial plans and ILS
5.5 Implement a numbering plan for multi-site topologies

For Section 6 – Implement Call Control Discovery/ILS

6.1 Configure Service Advertisement Framework Forwarder
6.2 Configure Service Advertisement Framework Client Control
6.3 Configure Service Advertisement Framework Call Control Discovery
6.4 Configure URI calling
6.5 Configure ILS network
6.6 Configure Global Dial Plan Replication

For Section 7 – Implement Video Mobility Features

7.1 Configure extension mobility, and device mobility
7.2 Configure unified mobility (including video)

For Section 8 – Implement Bandwidth Management and Call Admission Control on CUCM

8.1 Configure regions
8.2 Implement transcoders and MTPs
8.3 Configure locations CAC and Enhanced CAC
8.4 Correlate events based on traces, logs, debugs and output of monitoring tools
8.5 Parse and interpret traces, logs, debugs and output of monitoring tools

The blueprint goes a long way in painting a picture of what to expect on the exam, and will be a tremendous resource as you begin preparing your study efforts. I attended a 5-day class put on by Global Knowledge, and while it covered a lot of the content, I don’t think it covered the material near deep enough, so even after 5 days of focused learning and another week of study, I was not prepared to pass this particular exam. It’s my understanding that each of the authorized training partners use the same content, so I don’t really place the blame on the training provider – but word to the wise – it’s going to take more than sitting a class to pass this exam. Keep in mind, I’ve been doing Cisco UC since Call Manager 3.x, but MANY of the topics on this exam were things I’m not using on a day-to-day basis, so I really had to buckle down and study to set myself up to pass this exam.

The resources I found most useful in preparing for this exam include the following

Cisco Unified Communications System 9.x SRND
Unified Communications Mobile and Remote Access via Cisco VCS
Cisco VCS Basic Configuration (Single VCS Control) Deployment Guide
Cisco VCS Basic Configuration (Control with Expressway) Deployment Guide
Cisco Unified RTMT Administration Guide

The information contained in these documents will go a long way towards helping you in your study efforts.

I also used the following Cisco Press book, from the previous version of this exam
Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) Foundation Learning Guide: (CCNP Voice CIPT2 642-457), 2nd Edition

I’ll warn you – this was not an easy exam for me, and even though it took me several tries, I did it, and so can you! Don’t take shortcuts, you’re going to need focused study time, and you’re going to need to set up each of these systems to learn the in’s and out’s of them. My advice – set them up, install them, make them work, it’s going to help you a LOT more than just reading a study guide.

Now that my CCNP Voice has been converted to CCNP Collaboration, I’ve begun the process of going after my CCIE Collaboration Written exam, I’m a glutton for punishment, I suppose. I hope the information in this post has been informational to you, and I wish you the best as you prepare for your CIPTV2 exam! You can do it!

Cisco IOS SRST – Minimum Required Configuration

I’ve spent a few hours this evening getting back to basics, and taking the time to review what I’m going to call ‘Minimum Require Configuration’ for SRST – both SIP and SCCP.

SCCP SRST Minimum Required Configuration

ip source-address port 2000
max-ephones 10
max-dn 10

SIP SRST Minimum Required Configuration

voice service voip
registrar-server expires max 600 min 60

voice register global
max-dn 10
max-pool 5

voice register pool 1
id network mask

With the configuration shown, both SIP and SCCP devices can failover to the Cisco 28xx ISR that I’m using for testing. There are lots of other nerd knobs you can tweak if you want, but this is all that’s required to get endpoints to register.