Sunday, September 18, 2011

The New CCNP: Voice Certification is Expensive...For Me

Now that I'm preparing to deep dive into the CCNP: Voice track, I'm in the very early stages of figuring out what hardware, software, etc I'll need to get through the entire exam. At the very minimum I'll need to cough up at least $2,000-3,000 dollars I think. Sadly when I put together my CCNA: Voice lab before the new update I used all equipment that isn't compatible with the new version 8.x that Cisco is currently on. I have a few 1760 routers and possibly even some VWIC's and some other stuff that I might not be able to reuse. I should of done better research of the long term and what will be needed.

Oh well lesson learned, I'm going to either borrow equipment from work or purchase a few 2801's and a beefy PC to through all the Cisco Software on in a VM environment. I need a new PC any ways, it's about 4-5 years old lol. I can obtain IP phones for both Type-A and Type-B easily, my work laptop for Presence testing and other random things. I'll need to buy some cheap analog phones which is simple and other random things. I'm going to go off of this good diagram which is a HQ, one branch, and a PSTN router for external calls. If absolutely needed I'll buy equipment to make a 2nd branch office. Hopefully this will get me through everything. I'm estimating about 18 months of study time give or take. Cisco changes certification requirements so much that if I'm going to tackle this I need to start now rather than later. It would suck to get 3/4 through the CCNP: Voice and have to start over due to an update to the track.

Wednesday, September 14, 2011

User Input on Type-A and Type-B Phones


The SRND guide describes to types of phones which are the group of phones known as Type-A and the other group known as Type-B. Type-A phones consist mainly of the older and less power phone types such as the 7912's, 7940's, and 7960's. The Type-B phones are mainly the newer models such as 7941's and 7942's. The way you dial phone numbers vary by the phone type and the the protocol used (SCCP or SIP). Cisco phones connected to CUCM are basically dumb terminals that really on the CUCM to control them.

What's interesting is that user input when dialing numbers using SCCP on the Type-A phones relays a signalling event to CUCM every time a key is pressed. Which results in CUCM sending feedback regarding the buttons pressed in real time such as dial tone, ring back, etc. However when you're using SIP on Type-A phones, all user input events are stored until the user press the # key or Dial softkey. This is similar to cell phones where you dial the entire phone number you would like to call and then hit the "send" button to place the call with the carrier.

Saturday, September 10, 2011

Dial Plan Design


I ran through most dial plan design recommendations today in the SRND guide. The example above show's the model that we've adopted due to the smaller size of our network environment.

Sunday, September 4, 2011

Unified CM and CME Connectivity



There are two primary ways to connect Cisco Unified CM systems and CME's between sites, that is H.323 or SIP. The primary focus in the SRND seems to be on the H.323 model which is deployed using either a Cisco Unified Border Element (CUBE) or what's called a via-zone gatekeeper. The important thing to note between CUCM and CME is that H.450 is used with CME for supplementary services but not with CUCM which can turn into dropped calls over a PSTN due to compatibility issues. I believe CUBE or a via-zone gatekeeper is used to mitigate these issues and act as the middle man. SRND is a pretty high-level document so a lot of things I read aren't going to really explain the reasons why or how. That's what's the CCNP: Voice books should provide for me...hopefully.

Saturday, September 3, 2011

Gatekeeper Redundancy




There seems to be two different options for gatekeeper design, clustering and directory gatekeeper (DGK). It looks as if the preferred method is clustering gatekeepers together rather than creating a DGK. Using gatekeeper clustering, you configure a local gatekeeper at each site but then you make redundant alternate connection other sites. This allows for the gatekeeper to provide primary call routing for the main site along with providing alternate call routing for other locations connected to it and vice versa.

DGK depends on the Hot Standby Router Protocol (HSRP) or by configuring multiple DGK's in your environment. I'm still trying to wrap my head around how this particular way works a little more.

Wednesday, August 31, 2011

Call Processing Overview


I'm on part 2 of the Unified CM SRND guide, it's a good 400 pages long so it's going to take me a while to finish this section. The last few days I went through 40 pages or so reading up on a high-level over view regarding the best ways to deploy Call Manager 8.x along with providing scalability, resiliency, and high speed performance. This is for all three flavors of Cisco Unified Communications:

Cisco Unified Communications Manager (CUCM)
Cisco Unified Communcations Manager Business Edition (CMBE)
Cisco Unified Communications Express (CME)

Sunday, August 28, 2011

Unified CM Clustering over the WAN


I went over yet another Cisco VoIP deployment model which involves configuring a CM cluster that is spread over multiple remote sites. So there is a subscriber and maybe a backup subscriber (depending on resiliency needed) at each site that is to be involved with the CM Cluster. With that you provide either local fail over or remote fail over. Local fail over provides the most resilience sense it implies that there's a subscriber and backup subscriber at each site. Remote fail over provides more flexibility since you are failing over to another remote sites CM subscriber server essentially instead of failing over to your own local subscriber. This model only requires one subscriber as well.

I also reviewed the section that discusses virtualization of all of these different deployment models using Unified Computing System (UCS) which is just all of the Cisco VoIP products deployed on a VMware system using Fibre Channel over Ethernet (FCoE) as the media for communication between them all.