Acquisition #2 – Complete!

Well, the Presidio acquisition of INX is now complete!

I’m now working for the second largest company I’ve ever worked for.

Time will tell but I’m looking forward to having a similarly positive impact in the new sea I find myself swimming in.

Presidio is now 1,800 employees strong and the Cisco Collaboration market on all coasts.  If I am to admit, I would acknowledge (with great anticipation) that the region I’m in has the greatest untapped potential for growth.

Presidio now has over 45 offices in the US, three of which fall in my region.

Presidio wisely acknowledges INX’s delivery framework as a key asset in the acquisition, and is looking to adopt this model across the organization.  THAT is exciting to me – taking a proven process and using it to light a match on a powder keg of human and financial capital – leading to explosive growth!

First Video call from iPad2 to Cisco environment! (1 of 2)

I’ve been wanting to get my hands on an iPad2 long enough for a while to try out a perhaps unexpected way to use it for video calls with our internal Cisco VCS/VCS-X/TMS/Tandberg Endpoints, Cisco Video Phones, Cisco Immersive TP endpoints environment.

The unexpected way?  Use the Polycom mobile app announced and released a few weeks ago.

I picked up a few iPad2’s tonight, and got some time while the wife and kids were away to hack at it for a while.

So far I’ve tested successful 2-way video calls between the iPad2 and:

  1. Cisco Movi 4.2 running on iMac 27″
  2. Cisco Movi 4.2 running on MacBook Pro
  3. Cisco Cius running firmware sipcius.9-2-1SR2-21SEC through call to MCU 4501
  4. Cisco Cius running firmware sipcius.9-2-1SR2-21SEC through call to Cisco TPS

Directly dialing between the Cius and the iPad2 results in only audio coming from the Cius to the iPad2.

I’ve also tested and expect it is working (but can’t verify the other side of the call) calls to:

  1. Cisco C40 registered to VCS-Control (whereas I’m registered to the Expressway)
  2. Cisco EX60 registered to VCS-Control

Lastly (cuz I need sleep) I tested presentation from the Movi client and it worked successfully.

A few screen shots showing what settings I used:

This is the main settings screen.  I ignored the Polycom specific settings:

Now for the SIP settings – I haven’t gotten H323 calls working just yet:

I blurred out the specific settings, however you will want to set them as the following:

  • SIP Proxy Server – set this to your external VCS Expressway address (I’m using DNS, haven’t tried IP) – exactly how you would have it setup in your Movi client
  • SIP Registrar Server – Same as above
  • Domain – your domain – for me it was simply  Exactly what you would use for your Movi client.
  • SIP User Name – This is the SIP address you will register with.  I’ve played with this a bit and found that as long as you can authenticate, you can tweak your SIP URI.  As such you can call me @ if my client is running.  It also works to register as the same URL you use for Movi (most practical) and the Expressway will ring all of your logged in Movi endpoints.
  • Authorized Name – This is the login name, no @domain or DOMAIN was needed for me.
  • SIP Password – Password you would use to login to Movi
  • Transport Protocol – UDP – didn’t work on TCP

From what I understand there has been a Tandberg Movi app for several years that simply hasn’t seen the light of day.  Here’s to hoping I can get my hands on a real Cisco video client for the iPad and Android soon!



UPDATE:  I also tried out the ClearSea service and am rather displeased at the full-court bait and switch they employ.  They offer a service, and then e-mail you a few days later to let you know you are on a trial and you are going to be limited to a nearly useless account if you don’t cough up $40/month.  Screen shot below shows pricing.

Acquisition #2 – Underway

Here I go again!

Nearly 7 years ago the small Cisco Silver Partner (Datatran Network Systems) I worked for was acquired by INX.

This is an exciting time in the industry and I woke up this morning to a company nearly quadrupled in size!

It was announced today that Presidio is buying out INX – my current employer.

The response thus far both internally and externally has been very positive with my general sense being “sweet, we are bigger now”.

We seem to be a good match in geography and skill sets and while details are still being worked out, I’m excited about what the future holds!


While I was deeply involved in the sale of DNS and helped drive it to close, this one came as a surprise.

I guess that is the difference between being a big fish in a small pond vs. a big fish in a small lake!

Time to be a big fish…in a small sea….

(I feel like the timing of starting Seth Godin’s Linchpin a few days ago was almost prescient…)

ASA Licensing Update…from a Collab guy!?


Yah, that’s what I would have thought a few years ago as well.

As the ASA is embedded in the path of my solutions more and more (aka borderless concerns) I’m finding that it is crucial to understand and be able to verify licensing on customer ASA’s.

This is true not just in the most common scenarios – ASA handling secure connectivity for a user at their house who is running any of the variety of teleworker scenarios (IP Communicator/other softphone over VPN, ASA/8xx router with fixed VPN, IP Phone with Phone Proxy, or IP Phone with VPN) but other up and coming scenarios such as IME, and IM/XMPP federation.

The ASA truly is becoming an integral device to the overall architecture to common UC deployments (not just the one you have up there for the security conscious customers).

All that said, I’ve quoted ASA licensing several times, and advised customers numerous times but I felt I had some gaps – so I sat in on an ASA Licensing training.

What is below is not a comprehensive view of ASA licensing, but rather a focus on the most common discussion points for ASA Licensing from a UC view.

First – there are four scenarios for remote employees that I mentioned above:

  1. PC/Mac/Mobile Device VPN – and a softphone on said device
  2. Physical (and usually stationary) device creating a VPN tunnel – and a physical phone behind said device
  3. IP Phone using the Phone Proxy feature (a la Cisco’s Metreos acquisition in 2006)
  4. IP Phone using SSL VPN (aka AnyConnect Premium)

Below is a bit more detail on each of the options, along with information on the licenses required.


PC/Mac/Mobile Device VPN w/ Softphone

This option is historically the most common scenario.  Softphone client options are:

  • Cisco Softphone (yah, the old CTI version)
  • Cisco IP Communicator
  • Cisco Unified Personal Communicator
  • Cisco CUCI-x (Lync, MOC, Sametime, Connect, etc.)
  • Cisco Jabber (for this discussion – essentially CUCI-Connect for Mac)
  • Third-party PC/Mac options
  • Cisco Mobile for the iPhone
  • Cisco Mobile/Jabber for Android
  • Cisco Mobile for Nokia
  • Cisco Quad UC Integration
  • And probably more I’m missing…

The solution is very flexible – VPN anyway possible to the corporate network, and you have a phone client operational.

VPN licensing can pretty much be any VPN option – SSL VPN, IPSec, etc.


Physical device creating VPN tunnel

This scenario was pretty common and is still around, but is being phased out for options that don’t require hardware at the home/small office.

Typical hardware for the remote site included:

  • Cisco PIX 501 – basically a older version of the 5505
  • Cisco ASA 5505 – nice because it included PoE for the phone
  • Cisco 8xx router – 871 seemed to be the most common, although if you wanted 911 dialing you might go with the 888SRST.  For voice quality sensitive users, this is still the best choice.
  • Cisco 1700/1800/1900 – For very small offices connecting over VPN, this would give you a bit more capability/power and handle a few users, not just a single user

Again, this solution was flexible from a VPN selection perspective – use whatever needed to provide the proper security, and keep the tunnel up and running as long as desired.


IP Phone using Phone Proxy

While I only had two customers actually use the original Metreos “Phone Proxy” appliance, Cisco did a good job of cleaning up the issues with the original rendition, and moving the code/functionality to a pretty ubiquitous platform in the ASA.

The premise is great – drop nearly any Cisco IP Phone somewhere on the Internet, plug it into a local power brick, and you are off and running.

Unfortunately, there a couple of major issues with the Phone Proxy option:

  1. Lack of geographic redundancy – when you configure the phone, you are setting up a static entry as the Alternate TFTP to get it working.  The Alternate TFTP points a specific public IP of the ASA you are connecting to.  If that ASA – or even the ISP you are getting that IP from (in the scenario of a dual-connected Internet) is unavailable, your remote phones are out of luck.
  2. Confusing licensing – Ok.  Perhaps “confusing licensing” is an oxymoron.  Let me explain…All remote phones will consume a license for EACH UCM appliance they are connecting to.  So if you have the max of three UCM’s in the phone’s list – you are going to consume 3 licenses…for 1 phone.  Err…  Oh yah, if you look at the output from a “show phone-proxy secure-phones” command – you won’t see the hidden licensing consumption.  Look instead to “show tls-proxy session” to see the real license usage.  End result – not only is the ASA pair/site/ISP a single point of failure – you essentially want to have UCM a single point of failure for remote phones too.
  3. No IP Phone Services – IP Phone Services don’t work on Phone Proxy.  Corporate Directory does…maybe.  See below.  So if you are using Extension Mobility…or um…the Berbee flight lookup tool…or an actual IP Phone Service you developed – well too bad for remote users.
  4. Cisco doesn’t want you to use it anymore… – While I can’t point to any e-mail from Chambers scolding me for using it…I can point to bugID CSCtl11930.  Go ahead.  I’ll wait…..You back?  Love that “Workaround:  download to firmware 8.5(2)…” didn’t you?  So essentially Cisco is saying – “if you want to use Phone Proxy, well fine we can’t stop you.  But we can stop you from using new firmware.”  I’m not so sure about reading tea leaves, but I’ve gotten pretty good at reading Bug notes.  That says – “stop using Phone Proxy.  Use SSL VPN instead.”  Oh yah, that is what the unnamed TAC guy said too…

The biggest benefit – it works on older phones (7940/7960’s).


IP Phone using SSL VPN (AnyConnect Premium)

That’s the last time I’m going to use the old term of SSL VPN.  I’m on the bandwagon – AnyConnect it is!

This is my personal favorite option – mainly because getting the AnyConnect infrastructure in place helps not just for remote phones, it helps for mobile devices, remote phones, remote PC/Mac’s…basically everything!

Think of AnyConnect as the IPSec of 2011-???

AnyConnect requires a couple licenses:

  • AnyConnect Premium – YES – Premium, NOT Essential!
  • AnyConnect for Cisco VPN Phone – yup, that’s a part number – L-ASA-AC-PH-<Your Model # here> in fact!

The AnyConnect Premium license is based on the number of CONCURRENT sessions.

There is even better scenarios where you can pool licenses on a single ASA, and have other ASA around the world or country grab licenses in blocks of 50 on an as needed basis.

The AnyConnect for Cisco VPN Phone licenses is per PLATFORM – throw it on the ASA and you are set.  These licenses are cheap – $100-500 based on the platform.

While you are at it, thrown in the AnyConnect for Mobile (L-ASA-AC-M-55XX) as well so you can have iPhones/iPads/Android devices (see my tweet from 10-28 btw) connect using AnyConnect.  That license is roughly the same as the AnyConnect for Cisco VPN Phone’s cost.

There are a couple big wins for this option in my book:

  • Super simple setup – especially if AnyConnect is already setup and in use on the ASA
  • Faster phone bootups (vs. Phone Proxy at least)
  • Ability to have redundant geographic datacenters – In nearly all designs I’ve seen in the past 3 years – there are geographically redundant UCM servers.  Since the clustering over the WAN requirement went to 80ms, nearly any WAN can handle this.  If there are a lot of remote users, or keeping the remote users operational is critical to the business — this is a MUST have.
  • Standardizes troubleshooting on single technology – no dealing with TLS just for Phone Proxy…

One last note for this option – it requires 8.0.4+ version of ASA code.


That’s all for now, I’ll address IME and the Federation discussion later…or not…

SDF – Free Prize Inside!

I just finished reading Seth Godin’s “Free Prize Inside“.

Great read, and as all of Seth’s works – it inspires the individual to feel empowered about doing SOMETHING to improve their world.

The premise of the book – go to the edge, find out what my customers want – and give them that.

Even if it turns things upside down, seems crazy, disrupts the current status quo – find what customers want (and are willing to pay for), and innovate that into my products.


This led me to thinking about what INX offers as our “Free Prize Inside” to our customers.

I realized with delight that as a credit to Andy Cadwell (SVP of Sales and Field Ops), and Kip Poindexter (his secret weapon IMHO) – INX has a Free Prize called SDF or Strategic Delivery Framework.


What system integrator customers want – a predictable, successful, and most importantly – GUARANTEED outcome.

What our competitors (and us until 6 years ago) give them – a risky, costly, and HOPEFUL outcome.


Strategic Delivery Framework is a framework that is designed to guarantee results of our projects – not just in terms of time or cost – but outcomes.  We (nationally) complete well over 2,000 projects a year and are experts at what works and what doesn’t.  Therefore we apply our expertise in a real way to customers – we guarantee that the outcome is what is desired by the business, and we put that in writing.


While this is a great and remarkable product – eventually our competition will figure out how to deliver better business results and lower risk to their customers and our growth based on our Free Prize Inside will slow.

What will our next free prize inside be?

What do you want to see from your system integrator/business partner?

New CUWL changes – AGAIN!


Cisco recently announced changes to the Cisco Unified Workspace Licensing (CUWL) bundle.



–1 Year of WebEx Connect (Jabber) subscription for all Standard and PRO users

–1 Port of WebEx MeetingCenter for all 10 Pro users


Rumor has it, customers who have purchased as recently as May of 2011 are eligible to grab the freebies.


MeetingPlace is also changing again – away from the User Connect Model and back to a “buy license here, another one there, and sometimes that one too” model.


The changes to CUWL are great and needed, however I see confusion coming on how they are going to be implemented.


Here are some of the questions I have to start:

  1. What about someone who has been a CUWL customer for many years?  Do they automatically get the WebEx Connect/MC addons?
  2. What about CUWL Standard users who deployed CUPS – is there any benefit for them?
  3. What about smaller CUWL PRO users who are deployed on MeetingPlace Express?  The change allows them to move to the cloud (and a better product in WebEx MeetingCenter vs. MeetingPlace Express) but the on-premise, fixed cost model they like is still not an option.
  4. Speaking of not fixed price – how are audio minutes going to be sold?  I’ve heard rumor they are on the GPL (Cisco Partner speak for price list we can sell), but haven’t seen any pricing on it.
  5. Is the WebEx MC ports going to be able to integrate with third-party for audio minutes?


I’ll be tracking down these and more answers, and will update the post as more details are fleshed out…