First of all let’s start proceedings with the disclaimer. H323 is an ITU protocol used to set up VOIP calls between two endpoints  (conferences, gateways, terminals) sitting on  the network. It is a very, very complex umbrella protocol with many sub-protocols from ITU and IETF referenced/defined. Not to mention the copious amounts of revisions that have taken place over the past 15 or so years.  Needless to say, this blog is not going to be a full comprehensive guide to H323. It is however a streamlined summary (kind of a fast start guide :-) of what is most relevant based on the CCIE Voice Lab blueprint. We will focus in this blog on the H323 messaging involved in a call between UCM & UCME via a gatekeeper.
Read Full Entry »

Cisco Unity Express uses three type of Message Waiting Indication mechanisms when integrated with a CME or SRST router. All 3 mechanism used are based upon the SIP protocol. Contrast this with the way CUE updates the MWI status on phones registered to UCM- in this instance JTAPI is used.

The focus on this particular article is a technique which relies on the SIP Notify method which is used to tell the CME to light the lamp for a particular extension. An example of a NOTIFY method being received by the CME from the CUE is shown below after the debug ccsip messages command has been used on the CME router.
Read Full Entry »

Cisco Unity Express uses three type of Message Waiting Indication mechanisms when integrated with a CME or SRST router. All 3 mechanism used are based upon the SIP protocol. Contrast this with the way CUE updates the MWI status on phones registered to UCM- in this instance JTAPI is used.
Read Full Entry »

We are pleased to announce that we were in attendance at the CCIE Voice Techtorial, given by Ben Ng (Cisco CCIE Voice Program Manager) at the Cisco Live Networkers Conference.  In that 8-hour session, we found out some interesting information regarding the CCIE Voice Written and Lab exam that we would like to pass along to you in no particular order.

There were no changes to the blueprint announced (thankfully!). All software versions will remain at 7.0 and are likely to remain at this release for a couple of years. It is worth pointing out that Cisco are well aware of the fact that there are several “bugs/undocumented features” that can be expected with any “.0” release. However candidates are expected to provide workarounds where applicable.

As most of you know, the Core Knowledge questions were removed some time in May 2010 and were replaced with troubleshooting tasks. The speaker repeatedly brought attention to the types of troubleshooting tasks candidates can expect. We have tried to summarize some of the most important points raised below.

• There is no dedicated troubleshooting section for the time being- troubleshooting is embedded into the configuration tasks of the exam. This is subject to change- in other words they may look at providing a dedicated troubleshooting section at some point in the future.
• Troubleshooting tasks account for approximately 15% of the points on the CCIE Voice Lab exam.
• Candidates will have to troubleshoot existing configuration which has built-in errors. More details of example errors are given below.
• Infrastructure tasks will for the most part be complete and will not be the responsibility of the candidate. However configuration might not be 100% correct!
• Going forward phones will be pre-configured into the UCM database. It was mentioned that SIP endpoints have not been tested thus far but candidates should expect SIP endpoints in the lab in the very near future. Interestingly it is the intention to have phones pre-registered with the correct firmware in advance- that means candidates will not be responsible for changing the firmware of the phone. This will come as a relief to many of you since this process is time-consuming.
• Troubleshooting tasks could potentially include in depth knowledge of the protocols used for establishing call setup. Detailed knowledge of the call flow involved in protocols such as SIP/MGCP/H323/SCCP/Q931/etc will be required in order to explain why certain calls to the “provider” are failing. It was mentioned that the candidate may not even have to fix the problem and instead create a text file with the relevant traces/debugs and a suitable explanation. A process not too dissimilar when you create a TAC case.
• Cisco will continuously modify the content of the lab and this includes changing the number of UCM and UCME sites. You can expect 3 UCM sites, 3 UCME sites or anything in between!
• Gatekeeper/CUBE/SIP Trunk tasks will be added to the lab at some point in the near future (if not already!). The PSTN provider in the lab may not necessarily be a T1/E1 connection but rather a H323 or SIP ITSP.
• Security related tasks (authentication and encryption of signaling and media) are not going to be tested since these tasks are too difficult to maintain and implement. However the CCIE Voice Written test which will be updated later this year will cover those topics.
• The Voice CCIE pass rate is currently between 20% and 25% but expect that figure to drop as the impending lab updates will no doubt increase the difficulty of the test.

Overall we were very pleased with the outcome of the discussion- no major updates for a couple of years will come as a huge relief to all training vendors. The IPexpert BLS and bootcamps have for more than a year now been covering SIP Phones, CUBE, multiple UCME sites and detailed knowledge of the protocols involved in call set up. The biggest takeaway from the session was undoubtedly troubleshooting is going to be the singular most important skill candidates will need to pass the lab – if you are going to pass the CCIE Voice going forward you need to focus on the why and not only the how as has been the case in the past.

Amy Ryan CCIE# 24677
Senior Technical Instructor
IPexpert Inc

There are specific instances when it is MANDATORY to localize the format of the Calling Number on the Device Pool and not the Device. I’m talking about calls from the PSTN to an IP Phone registered to UCM. We want to store the globalized number in the Missed/Received call log, but whilst the phone is ringing we want to show the localized number.

Read Full Entry »