Daryl Hunter – Hubby, Daddy, Mentor, Friend

Today was another technology milestone day for LifeChurch.tv's remote employees.  For the last year or so we've been experimenting with a few full-time employee positions being "remote" employees – that is – living somewhere we do not currently have a LifeChurch.tv campus.  I believe there are 5 of us now in 5 different states – myself included – I'm in Kentucky.

If I'm not mistaken, I'm the only remote employee with a "company" phone on my desk.  The rest of the gang use the Cisco VPN client to connect back to Oklahoma and they use their cell phones.  The nature of my job is a little different – I have full-remote access via IPSec/VPN (hardware based).  My home router is a Cisco 871w connecting to the Cisco ASA 5520 cluster in Oklahoma.  My desk phone is a Cisco 7941G connecting to our Cisco CallManager cluster in Oklahoma.  Everything has been great.  No problems.

Here's the rub – what if we wanted to provide a deskphone to a remote employee who did not have a fancy IPSec/VPN tunnel at home?  What if we wanted one of our employees to take a phone with them when they traveled overseas, and have that phone "sync up" to the CallManager cluster to have phone service no matter where they are?  How do we do that?  Cisco UC Phone Proxy is how we're doing it.

Here are three great resources to get started configuring UC Phone Proxy – you may need a Cisco CCO login to use these.

• Configuring UC Phone Proxy via CLI
• Configuring UC Phone Proxy via ASDM
• Troubleshooting UC Phone Proxy

Rather than walk through the configuration process on our setup, I'll just let you know we used a combination of CLI and ASDM.  We didn't do anything "out of the ordinary" – it was a very very basic setup following the examples above as closely as made sense.

However.  Phones wouldn't work.  They couldn't get the CTL file (tftp) or Register to the CUCM cluster.  Why?  We went through the config about a bazillion times, and it "looked" right.

During troubleshooting, I remembered a guy I follow on twitter – Michael Whaley – tweeting about UC Proxy last week.  I dropped him a line, and he was kind enough to help.  During the course of the day, we traded a dozen emails and scrubbed/partial configs.  His setup is much more complex than ours, but at the end of the day, he uses a similar config.  Why would his work and not ours?

Here are a few things we noticed during debugs (debug phone-proxy tftp):

So, 74.x.x.223 is my external IP.  172.x.x.10 is the IP of my CUCM Publisher / TFTP – the place my phone is trying to get to.  Lots of retransmits.  And something about an "unsigned" config file.

I'm going to skip forward 8 hours – nothing useful happened here

I got a Cisco TAC Case opened, and engineer Wasan walked through a few things with me.  We ended up on the phone, and Webex, and he jumped in my Cisco ASA config.  I'm thinking he's ran into this problem before, because about 10 minutes later he asked about my IPS (intrusion prevention) situation.  He noticed my ASA Cluster uses the integrated IPS module.  He wanted to do a test and bypass the IPS for any traffic destined for my CUCM cluster.  We did.  It worked.  Yes, you read that right.  The "problem" wasn't a problem at all.  My Cisco IPS was doing it's job – it saw odd traffic, and prevented it from hurting my network.  Ha!  There were a few other things to tighten up too, so I'll give you the breakdown of the three things that we changed.

CTL-FILE
During our UC Proxy Configuration, we created a CTL-FILE – that's what the phones get to create the encrypted traffic between the phone and the UC Proxy.  It contains the CUCM and TFTP information.  Here's what ours ended up looking like:

During our setup, we (by we, I mean Brad – I hate certificates) had the CA trustpoints created for our CUCM cluster SUB (subscriber) and PUB (publisher) – the addesses you see here – CCM-SUB/CCM-PUB are the INSIDE/private addresses of our CUCM cluster.

SERVICE-POLICY
During our UC Proxy Configuration, it is necessary to create a policy-map, and apply that to an interface.  We mistaken thought we could simply apply this to the existing "global policy" – that's not the case.  Here's our full policy information including class-map, policy-map and phone-proxy details.

Basically, we defined SIP traffic as using port 5061 and skinny (SCCP) traffic as using port 2443.  We then applied those classes to the policy-map "voice_policy" – we inspected for that traffic and then applied the phone-proxy called "asdm_phone-proxy" – details can be found in the documents linked at the beginning of this post.  Finally, we applied this policy to the Outside interface.

IPS Configuration
This was the biggie.  At the end of our global policy, we have the following

That means, match the class-map "ips_class" and then run IPS in promiscuous mode.

Let's track that down a little more and look at the "ips_class" map

Fine… and… the access-list?

Yup, you guessed it, that means – block anything you think is bad… but we need to fix that.  We want any UDP traffic going to our CUCM cluster to be allowed.

That's better.  Let's try again.

Will It Work?
Unplug remote phone.  Plug it back in.  Wait a minute and watch the debugs.

Much better.  The phone is now talking!  Wait a minute longer and all the rest of the magic happens and my phone is ready to go.

Anyway, I hope that was helpful for someone.  Mike, thanks so much for sharing your information.  Brad, I'm glad you get certificates – I hate them.  And, Wasan from Cisco, if you stumble here – thank you for being so helpful.

Update 8/24/2009 – I've added a few more things here related to UC Proxy & Directory URLs and Service URLs and One-way Audio.