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.

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.

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.

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.

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)

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.

Intercompany Media Engine Architecture

I had a quick study session this morning reading up more on a new feature to me called Cisco Intercompany Media Engine. I went over the call processing and how it uses IME compatible ASA's and Unified CM's to learn and place calls between enterprises. Along with our to fail over to PSTN in case of connectivity or latency issues. It's a pretty neat technology but I'm curious as to how many enterprises implement this solution currently.