About two weeks ago I posted an article on Understanding Basic MGCP Egress Call Setup. At the same time I started an outline and collected traces for the "ingress" view of MGCP. Then a "little bird" told me about a blog article that Vik Malhi posted on http://blogs.ipexpert.com that covers dissection of the ingress call. Vik's article breaks it down quite nicely (no big surprise here) and there is no sense in duplicating effort!
Thanks for reading. If you have time, post a comment!
As I mentioned in a previous blog on MGCP Egress Call Setup, I have been studying for the CCIE-V and putting some emphasis on getting cozy with trace files. This is a necessary aspect of the IE voice exam. In what may become a series, I am taking my notes and dumping them in the ol' blog blender.
In this installment, I want to walk through a SIP call setup scenario.
Recently I was interviewed for the Cisco Support Community, which is an online technical support forum for Cisco Systems. The content of that interview is available here. I wanted to thank Dan Bruhn and Litsa Pitsillidou for setting up the interview and for their (as well as their team's) dedication to making the Cisco Support Community so successful!
I'd also like to thank Litsa and Rhonda Raider (Raider Communications, Inc.) for conducting the interview. You're tops in my book!
Thanks for reading. If you have time, post a comment!
In this installment of the SQL query series I wanted to actually explore a query that is inspired by one of the comments on my blog. The reader asked:
Is there a command that will show the route list, route group, and gateway a pattern points to?
Seems like a reasonable request to me. Cisco Unified Communications Manager (CUCM) doesn't provide a command that will dump this information but there are a couple of ways to get at the data and using SQL is one.
In the toolkit I developed to survey customer sites, I have a query that does exactly that. Using SQL, or more accurately using AXL/SOAP API to access SQL queries, is the best option when bulk surveying a site for the purpose of gathering data that will be processed off line. However, there is another method that is more straightforward for a quick view of the path a pattern will take through your dial plan.
For the past couple of months I have been diligently preparing myself for a successful CCIE-V lab. One of the key factors in successfully navigating this exam is your ability to quickly troubleshoot a problem and, sometimes, provide information to the proctor about how you came to your conclusions.
Unfortunately, you can't say things like "well, I know the codec is G711 because the phone told me so (double "?")" nor can you use explanations such as: "based on the annunciator message, I conclude that the call is failing because it is Unallocated/Unassigned". You actually need to show definitive proof to back up your conclusion. So, you need to dissect traces or debugs and demonstrate that you understand them fluently.
I have been collecting notes on trace dissection as I study and I figured that I should try to integrate studying with my blog a little more than I have to date. So, this may be ugly but I am going to start with a basic MGCP call and using "debug mgcp packet" to identify the key phases of call setup, media initiation, and call termination.
As noted in my blog on Cisco Jabber for iPad Now Has Video, the latest version of Cisco Jabber for iPad was released on July 11, 2012. This version of Jabber not only adds video capabilities that leverage the built-in cameras on the iPad2 and 3rd generation iPad, but it also combines call processing, presence, and IM functionality into a unified client.
In this series on provisioning, I am going to go through the various provisioning options for the Cisco Jabber for iPad. We'll initially start with the basics of getting the client communicating with various back-end services by using the Cisco Unified Presence Server and Cisco Unified Communications Manager integration options.
Seeing that I have not taken the practical yet, it may be a bit presumptuous of me to offer up "tips" on taking the CCIE-V lab. Maybe it is better to think of this post as more of an idea I have or a process I plan to adopt when taking my own lab. I invite others to comment if they have suggestions for improvement.
I feel
that when you are entering a pressure cooker, it is best to have a well thought out plan of execution. For the CCIE-V lab you can't have a detailed plan for every situation. There are just too many permutations. However, you can (and should) have some "base" methodologies that you attach to your test taking strategy. I think one of these base plans should include configuration management.
The problem I am focused on here is making sure I have a process to roll back configurations during the middle of the lab -- just in case I break something. I was inspired to think on this problem after watching some of the excellent videos from Kevin Wallace. I suspect that my idea is nothing at all new for veterans who are preparing for this lab. The tools I will be discussing are staples for anyone who has been studying on their own lab gear or managing live systems.
