A Mini-Adventure Using Expect to Query Voice Gateway Configurations

Many moons ago, I started a series on the NetCraftsmen blog site covering various "tools" in my UC toolkit . I never did finish that series out and I may pick it back up and carry it forward. I still get asked about it from time to time and a recent query got me thinking about some of the more useful tools in my toolkit: scripting/programming languages.

I don't want to get into the pros/cons of specific languages here. There are just too many options available and I am not fool enough to consider myself an expert on the nuances between programming languages or development environments. I'll leave that to those who live and breath this stuff.

What I want to do with this entry is emphasize the fact that the greatest tool you can add to your toolkit is "ingenuity". Sometimes you need to go outside of the box and create a solution to your problem rather than waiting for Cisco or some other vendor to solve your problem with a bit of software. 

Personally, if I can't find a way to automate a task using existing tools I wonder if I can build it myself. That doesn't always work (trust me) but it works more often than not and I find the process to be a lot of fun. Then again, I am a bit of a nerd and what I find fun usually isn't by most standards. That's cool, too.

Dealing with Provisional Response and SIP 183 Messages with SDP

A month or so ago, I was deploying a solution integrating SIP trunks from a CLEC with Cisco Unified Communications Manager (CUCM) and Cisco Unified Border Element (CUBE). While running through the ol' validation routine, I came across an issue with SIP provisional response. Normally, we wouldn't have hit this problem because of the way we provision SIP trunks. However, this time around the integration guide for the ITSP had a configuration requirement that hindered our ability to support provisional acknowledgements.

The interesting thing about this particular issue is that if you weren't looking for it, you probably wouldn't catch it. Normal call setup was working fine. But when you called certain numbers you would receive ringing when you are expecting the call to be treated with an IVR.

There are a couple of ways of dealing with provisional SIP responses. The following covers some of the techniques I tested/used.

Cisco TelePresence Endpoints and IP Address Dialing with CUCM

Cisco has been steering customers and partners to centralize all call processing on the Cisco Unified Communications Manager (CUCM). This includes video or we can call it telepresence, if you prefer. For deployments where the Cisco Video Communications Server (VCS) is in play with CUCM, Cisco has some general design guidance that is slanted to registering Cisco telepresence endpoints on the CUCM. The VCS being relegated to legacy endpoint registration, protocol interworking, and facilitating firewall traversal.

This is all well and good but there are gaps. One of those gaps is supporting the ability to dial an H.323 party by IP address. Dialing by IP address refers to the ability of an endpoint to set up a video session with a remote party by simply using the IP address. This method is natively supported by H.323 devices. SIP devices use a URI format for "dialing". While SIP URIs can certainly use an IP address as the suffix, that is not the focus here.

How Video Kills the Audio Call with Early Offer

This is a quick blurb regarding an issue someone emailed to me a few weeks ago. It is a pretty straightforward example of why one should pay attention to CUCM Region settings and interoperability parameters of your ITSP before you deploy Early Offer (EO).

Using SQL as a Phone Provisioning Methodology for CCIE Voice

"What is the fastest way to provision the phones for the CCIE Voice Lab?" That is a question I asked myself a lot during my preparation for the IE lab. I also saw this question posed by a fair number of fellow candidates on various forums. There are a lot of different methodologies that could be applied here, but the bottom line is you have to go with what you know. You need something you can execute consistently and rapidly. 

I tried a lot of different methods and came up with one that worked best for me. I originally planned to post an entry on my method and then stopped short because I thought the benefit of the method would be lost in blog format. When I thought about posting it again I was slammed busy and I figured that the new blue print is right around the corner. Timing is everything.  

However, recently I have received several requests from readers asking about the phone provisioning method I alluded to in other blog entries. So, I dusted off the draft and am presented it now. Hopefully, someone finds this information useful.

Congratulations to the Cisco Designated VIPs - 2014

Cisco recently announced the new Designated VIPs for 2014. The Cisco Designated VIP program recognizes the top external individual contributors in Cisco's online communities, including the Cisco Learning Network (CLN), the Cisco Support Community (CSC), and the Cisco Developers Network (CDN). You can read all about the VIP program and discover the Cisco Support Community (CSC) here.

This is the fourth year for this program and I am happy to see the Cisco team running the program keeping it alive an well. The CSC is, without a doubt, the best online resource for getting support and information on Cisco technologies. The Cisco team that works behind the scenes of the CSC are an outstanding group of individuals who really care about establishing a robust and sustainable collaboration environment. 

The best news (from my point of view anyway) is that I was selected as a Cisco Designated VIP for 2014. I didn't make the cut for 2013 (I'd like to use my pursuit of the CCIE as an excuse, if you'll allow!) and it feels good to be back in that circle of outstanding talent. There are 36 VIPs this year! That is amazing and definitely demonstrates that the community is alive and well.

I'd also like to take a moment to congratulate the other designated VIPs. I am in great company and you all make me look good, keep it up because I need all the help I can get! I'd also like to thank a few of the VIPs for taking the time to help me out of a few jams. Thanks to Aaron, Anthony, Huff, Jonathan, Martin, Chris D., and of course my brother, David Hailey. 

While I am at it, hats off to my fellow Chesapeake NetCraftsmen colleagues Rick Burts and David Hailey for also making the cut. 

---

Thanks for reading. If you have time, post a comment!

Unity Connection Design Guide Drops 90ms from Latency Budget

This is just a quick note concerning a documentation change in the Unity Connection Design Guides. A few days ago one of my teammates was working on a Unity Connection design for a customer and came across a change in the network requirements for clustering Unity Connection over the WAN. Apparently, Cisco modified the clustering requirements section in the Unity Connection Release 8x and Release 9x design guides. 

The bandwidth requirements remain the same as they were when 8x was released. However, the round trip time (RTT) requirements have changed from 150 ms to 60 ms. Which is quite a big jump. It looks like this change was made on August 29, 2013.

This is more than a little disconcerting because I was looking at the design guide in July and made design recommendations based on the previous RTT requirement. Fortunately, my customer's network can still accommodate the updated budget. But what if that wasn't the case and I had to make a major design change in the middle of the project? Or worse, what if I didn't go back to re-read the design guide and the customer ran into an issue? 

Basically, I would have been screwed. Again, I am fortunate that we are still within budget and that I generally pick the lowest common denominator for clustering over the WAN designs. Which, prior to August 29, 2013, was 80 ms RTT for CUCM clustering. Interestingly enough, UCCX clustering also has a 80 ms RTT budget. It is odd (to me) that Unity would drop below the 80 ms threshold. 

Last point of interest. The UC 9x SRND still states that the maximum Round Trip Time (RTT) budget is 150 ms. That is probably still there to keep things interesting for the operators in the field! Obviously, it is best to err on the side of caution and assume the SRND recommendation is no longer valid.

I tried to find more information to see why the sudden drop in RTT budget. I suspect there may be a defect or some other revelation. If anyone has more information please post a comment. I am genuinely curious.

---

Thanks for reading. If you have time, post a comment!