ID Please

While there are many reasons that people hide/block their caller ID information, there is no reason for a hospital to do so.  In fact, showing up as UNKNOWN to patients and physicians can be quite a hindrance to a hospital's business.

The increasing use of cell phones has made caller ID an expected feature of phone service. As such it has also become commonplace for people to ignore calls from UNKNOWN.

For the last three years I have researched and battled to get our hospital's caller ID information to consistently show up.  I say consistently, because some calls would have caller ID and some wouldn't.  Finally this year as I was getting into the minute details of our current phone system to write an RFP for a new one it dawned on me what was going on.  Only the calls made over our long distance T1 CAS were not showing the caller ID information.  After calling several different numbers, I found intelligent life at our long distance provider and was told that it was a simple configuration problem... on THEIR end (be still my heart) that was causing our issue.  A week later we had a "cut over" to fix the configuration.

The secret sauce that had been missing for so long is what they call LOCO service.  Basically LOCO service tells their switch to send out our number when a call originates from our T1 CAS.  Now all is well and the hospital's calls show up correctly for everyone.  The moral of the story is that if you're going loco due to caller ID and you have a T1 CAS (not PRI), you need LOCO!

Telephone Jones and the Bridge to Nowhere

Today started like any normal Monday looking at the random tickets from over the weekend.  Then I decided to work on installing a new phone for our new IT team member.  Keep in mind that I am still supporting an ancient (that's being nice) Rolm/Siemens 9006i CBX (Computer Branch eXchange) for a phone system.  So unlike my lucky colleagues in the IP Telephony realm, a new phone is still a production number when it comes to layer 1.

For those not familiar with traditional phone systems, you have to have a copper path from the phone to the port on the phone system.  There are no intermediate switches like on the network side.  These paths are created using jumper wires between phone blocks like shown to the left.  As you can see, there is not much room for labeling.  To add insult to injury, through use, even with permanent markers, the labels tend to fade or disappear completely.  Of course this is why every telephony engineer carries a toner set and knows how to use it.

Today's adventure started at the user's cubical.  There were four telephone jacks labeled 22 A, 22 B, 22 C, and 22 D.  Generally when the jacks all have the same number and just a different letter, it is one 8 conductor (CAT5/CAT5e/CAT6) cable that has been split across four jacks.  Usually A represents the blue/white pair, B the orange/white pair, C the green/white pair and D the brown/white pair.  In my case the port labeled B was available so I plugged in my toner and ran off to the IDF to find the other end.

This is where it got fun.  Normally when toning out a cable, you will find one place on the other end that you hear the tone.  That being said, when I heard tone (keep in mind the labels had worn off) I assumed I was on the right cable.  I punched down my jumper from the phone system to the orange/white pair and went back to the cubical to check the phone.  Nothing.  The phone was as dead as it was before I plugged it in.

Thinking that maybe the B pair was damaged, I hooked the toner up to the D pair and repeated the process.  So this time though I found the tone on a different orange/white pair.  Remember when I said that D should go to brown/white?  Well at this point I got puzzled.

In my environment it is common for lines to have been abandoned without removing the old jumpers.  This turned out to be the case this time.  As I continued my troubleshooting I found the tone in 7 different places on the 66 block.  I noticed that there was a jumper cable on all of the terminals that had tone.  After following the jumper I found that all 7 locations were bridged for an old modem or fax line.

The solution to my problem was to remove the bridging jumper and voila my tones worked right and I was able to get my phone setup.  Unfortunately this whole process took 3 hours with interspersed other morning fires in the mix.

Rant: DRM for PDFs

Any device, any where, any time.  That has been the credo of many technology leaders including Cisco CEO John Chambers recently as they tout mobility and BYOD.  Unfortunately Cisco doesn't follow what it preaches when it comes to its course documents.

Last week I took an online Cisco class through a training partner.  Thankfully I have a Windows side on my laptop.  Cisco's DRM (FileOpen) requires Adobe Acrobat Reader and the FileOpen plugin.  Although both are available for my Linux side, the older version of Acrobat Reader required was no longer functional with Ubuntu 12.04.  Personally I would rather have the PDFs on my iPad, but that's not an option at all.  Offline access is also not available since the DRM software phones home each time the file is opened. 

All in all, it makes me nostalgic for the 40lb stack of dead trees that Cisco used to give each student.   At least I could use those books the way I needed to for studying. 

Cisco Learning Labs

Well I have now used the new IOS on Unix (IOU) based virtual labs from Cisco for the past three days for my CCNP ROUTE course.  So far I give the lab environment itself a B+.  Being that it is real IOS, the routers are full featured.  Unfortunately the web interface surrounding the IOS instances is still a bit clunky.  I would like to see tools to save and load configurations via text files.  I would also like to see a better L2 switch implementation.  The switches in the labs were unable to be setup for more than one vlan which meant the topology wasn't really setup correctly.


The lab exercises were where things really broke down.  Because you can't change the wiring configuration or the number of devices, you have to rely on Cisco to build the appropriate topologies and initial configurations to match the lab guides.  Unfortunately they apparently never reviewed the lab guides for the OSPF labs in the CCNP course.  None of those labs was configured correctly which caused a lot of extra work before being able to even start the lab you were assigned.  I guess that Cisco was trying to mix TSHOOT with ROUTE.  Because of this I have to give the lab setup a D (the EIGRP labs were done correctly).


Being that this lab environment was just released recently, I'm hoping that the quality improves quickly as people report the problems.

Internet Explorer 6 -- Ere he says he's not dead yet.

Contrary to reports that say IE 6 is dead, unfortunately it is not.  Today I got an urgent call to come help an outside technician that was installing a new remote support tool on some equipment.  He was having problems because he couldn't get past our IronPort WSA web filter.  I trotted up expecting to just add a few device IPs temporarily to the proxy bypass list until he was done downloading things.  Unfortunately the application needed web access all of the time and used the installed version of IE which of course was IE 6.  This is where it gets hairy.

Ironport WSA is configured to use passthrough NTLM authentication to authenticate users for Internet access.  This works great for IE 7+, Firefox and Chrome.  Unfortunately IE6 is braindead when it comes to NTLM authentication and only works with some NTLM proxies.  This means that I have to hard code any IE6 clients to use our proxy explicitly.

Moral of the story, vendors please update your "appliances" to modern software versions.