CCIE 12932

Secure Multi-Tenancy and FlexPod

2011-04-11T22:56:00.007-04:00

In my two previous postings, I highlighted the key features and benefits two industry leading private cloud architectures; the VCE VBlock Infrastructure Package and the HP BladeSystem Matrix. This posting will provide a brief overview of the Cisco/NetApp/VMware FlexPod Architecture.

The FlexPod Architecture is a Cisco Validated Design based on Cisco UCS Compute resources, Cisco Nexus, NetApp Storage, and VMware vSphere at the virtualization layer. The FlexPod architecture allows customers to adapt quickly and offers the needed flexibility to make fast changes without large amount of resources and processes.

Secure Multi-Tenancy

A shared cloud environment requires strict isolation between the different tenants that are resident within the infrastructure. The tenants can be different clients, business units, departments or security zones. Previously, customers with a shared cloud infrastructure were able to achieve “pockets” of isolation within the virtual server layer, the network layer, and storage, but never completely end-to-end.

Feature and Benefits of FlexPod

- Low-risk standardized shared infrastructure supporting a wide range of environments
- Highest possible Data Center efficiency
- IT flexibility giving business agility: scale out or up, but manage resource pools
- Complete Data Center in a single rack
- Flexibility in performance and capacity
- Fast setup for production
- Solutions guide for multiple environments
- Easy path for upgrading without fork lifting or data migrations
- Centralized management: NetApp OnCommand and Cisco UCS™ Manager
- VMs are isolated using vShield zone technology
- VMs connected and secured using Nexus products
- VMs on secure partitioned storage via MultiStore
- Service level assurance through VMware resource pools, Cisco QoS, and NetApp FlexShare

WWT and FlexPod
As a NetApp Star Partner with over 100 NetApp customers, combined with Cisco’s North American Partner of the Year, WWT is the leading FlexPod systems integrator. For example, WWT recently planned, designed, and implemented a FlexPod for a major financial institution based in New York and hosts a number of FlexPod demos throughout the United States.

The HP BladeSystem Matrix

2011-03-09T17:32:00.014-05:00

"Thirty-nine years of my life had passed before I understood that clouds were not my enemy; that they were beautiful, and that I needed them. I suppose this, for me, marked the beginning of wisdom. Life is short." — Iimani David, author of literary fiction

Whether you are leveraging the public cloud or building out your own private cloud, Cloud Computing is on the minds of most of the customers that I talk with. DHS is certainly building out their own private cloud initiative. In my previous post, I briefly discussed the VCE Coalition and the Vblock Architecture for the private cloud. This post will briefly discuss the BladeSystem Matrix, which is HP's compelling vision for the private cloud infrastructure.

The HP BladeSystem Matrix is a converged infrastructure platform for shared services that is ideal for private cloud deployments. HP BladeSystem Matrix delivers one virtualized pool of network, storage, and compute resources that can be continuously optimized and instantly adjusted to meet dynamic business demands for any workload type. It unites the tools, processes, and architecture of the physical and virtual worlds to help cut costs and speed time to service delivery, while reducing Capital expenditures (CapEx) and operational expenditures (OpEx).

The HP BladeSystem Matrix Architecture at a High-Level

HP BladeSystem Matrix is comprised of one or more BladeSystem c7000 enclosures, server blades, and shared storage, sized to each customer’s requirements, as well as all of the management software needed to provision, optimize, and protect the infrastructure. Matrix arrives at the customer site as a factory-integrated solution. Each Matrix solution also includes HP on-site implementation services and training, enabling the customer to begin realizing the value of Matrix and the shared services model immediately.

Matrix supports the full range of HP ProLiant and Integrity full-height and half-height server blades and is scalable to over 1500 managed systems (virtual machine and physical machine instances). The StorageWorks 4400 Enterprise Virtual Array (EVA4400) can be factory integrated (recommended option) or Matrix can be connected to newly purchased or existing HP StorageWorks or supported third-party Fibre Channel storage area networks (SANs).

The Matrix management console, built on HP Insight Dynamics, combines automated provisioning, capacity planning, disaster recovery, and a self-service portal. Matrix can be easily incorporated into existing data center environments: Virtual Connect modules in the BladeSystem enclosure enable Matrix to be connected to any standard Ethernet network or N_Port ID Virtualization (NPIV)-capable Fibre Channel fabric and the platform is compatible with a range of operating systems and hypervisors.

With its open, extensible approach, BladeSystem Matrix runs any application workload out of the box and integrates seamlessly with storage and network infrastructure from HP StorageWorks and HP Networking, as well as infrastructure from other vendors such as EMC and Cisco. It is also integrated with the leading virtualization technologies from HP, Microsoft, and VMware.

WWT and HP BladeSystem Matrix

WWT is an HP Elite Partner and is certified to resell and deliver the HP BladeSystem Matrix. WWT is one of a handful of HP Elite Partners to have a fully installed and working HP BladeSystem Matrix demo unit in our Customer Briefing Center. With over 59 HP-certified Technical Architects and Pre-Sales engineers on staff, WWT can assist in the Planning, Design, and Implementation of HP BladeSystem Matrix and other HP solutions.

What is VCE and Vblock?

2010-11-04T16:44:00.020-04:00

The Virtual Computing Environment (VCE) coalition is a collaborative effort between Cisco, EMC, and VMware to deliver a complete IT infrastructure that integrates best-of-breed virtualization, networking, compute, storage, security, and management technologies. The concept is wrapped around VCE's Vblock Infrastructure Packages, composed of the Cisco Unified Computing System (UCS), EMC storage, and VMware vSphere. The result is a reference architecture jointly created by EMC, VMware, and Cisco to create a modular building block architecture for cloud computing.

There are three Vblock Reference Architectures:

Vblock 0 (300 – 800 VMs): An entry-level configuration to meet the IT needs of small datacenters; test/development platform for Partners and customers.

1-2 Blade Chassis

6-30 ½-height Blades + 2 Management
32-128 Cores
48-GB Server Memory per Blade
46+ TB Storage Capacity
SATA drives
NAS, iSCSI, and SAN
1 Rack

Vblock 1 (800 – 3,000 VMs): A mid-sized configuration to deliver a broad range of IT capabilities to organizations of all sizes.

2-4 Blade Chassis
16-32 Blades
128-256 Cores
960-1,920-GB Server Memory
38-64-TB Storage Capacity
FC, SATA, & EFD drives
SAN, iSCSI, and optionally NAS
2 racks (min) or 3 racks (max)

Vblock 2 (3,000 – 6,000+ VMs): A high-end configuration that is completely extensible to meet the most demanding IT needs of large enterprises or service providers.

3,000-6,000 VMs
4-8 Blade Chassis
32-64 Blades
256-512 Cores
3-7TB Server Memory
96-146TB Storage Capacity
FC, SATA, & EFD drives
SAN, iSCSI, and optionally NAS
4 racks (min) or 5 racks (max)

WWT and Vblock

As Cisco largest UCS and Federal partner, WWT has successfully deployed the Vblock solutions a number of customers. For example, VCE was deployed for one customer to performance issues for their existing Virtual Desktop Infrastructure (VDI) solution. After implementation, overall performance in creating and starting virtual machines was enhanced by 50% or more. Having reads from “delta” disks on SSD drives eliminated I/O issues. PCoIP was proven to display audio and video well enough to meet their needs.

Cisco & The Private Cloud

2010-10-05T15:46:00.000-04:00

In my previous post, I briefly discussed Cisco and Citrix Teaming up on the Desktop. While I suggested this was an exciting development, I failed to put the announcement in proper context of the overall evolving Private Cloud initiatives that I foresee on the horizon. First, let’s define Cloud Computing, based on NIST’s version 15 definition:

“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.”

NIST then defines three service models:

Cloud Software as a Service (SaaS)
Cloud Platform as a Service (PaaS)
Cloud Infrastructure as a Service (IaaS)

To a certain extent, many Federal Agencies have already dipped their toes in some or all three of these services models. For example, the Department of Homeland Security is in the process of developing their own Private Cloud and offering email-as-a service to many of its various sub-agencies. But, what other SaaS, PaaS, and IaaS are available for consideration?

For example, perhaps deploying a Cisco Unified Communications Solution on the Cisco UCS platform in a virtual datacenter type of environment, providing true collaborative UC options across multiple agencies? How about thin client and VDI solutions on iPad and Android tablet devices, as I alluded to in my previous post, with imbedded VTC capabilities? Most importantly, how do you build out the virtual storage and cloud infrastructure to support these concepts and infinitives?

In upcoming posts I’ll touch on two other Cisco partnerships to support the Cloud Infrastructure as a Service (IaaS): the Cisco/EMC/VMware Virtual Computing Environment (VCE) initiative and the Cisco/NetApp/VMware Secure Multi-Tenancy (SMT) concept.

Cisco and Citrix Team up on the Desktop

2010-09-20T14:18:00.003-04:00

This was a very interesting announcement which caught my attention a few weeks ago. It appears the Cisco and Citrix have teamed up to develop joint desktop virtualization solutions using Citrix XenDesktop and the Cisco USC Server Platform. I think a Citrix blog on the announcement hits the nail on the head perfect:

“Cisco has an amazing history of catching market trends right before they take off. Let's take a quick look at their track record:

1. From connectivity to communications - Cisco caught the voice transition as it went from analog to IP
2. From communications to collaboration - Cisco then capitalized on unified communications as the voice market transitioned
3. From collaboration to telepresence - Arguably its new hallmark, Cisco is now the king of video and high-def conferencing”

Coincidentally, many of my customers are asking more and more about multi-vendor OEM VDI solutions over platforms such as the iPad and Android. WWT’s Datacenter Practice is also developing various VDI solutions over both client platforms. For me, this is an exciting and promising announcement!

Changes & Updates….

2010-08-09T15:27:00.001-04:00

First, my apologies for not having posted an update in quite some time. It has been an extremely busy three months for me professionally…

A business leader at GE once told me that “The only constant in the business world is change. If one is afraid of change, then he should find a new career.”

Since my previous post, I have transitioned into an Account Manager role here at World Wide Technology. My new responsibilities will be to support the United States Department of Homeland Security (DHS). Prior to my new role, I was supporting DHS as a Presales SE. My predecessor Account Manager, with whom I had a great working relationship and a great deal of respect for, decided to leave WWT to pursue a professional opportunity with Cisco. Given the circumstances, I felt this was an excellent opportunity to try something new in my career, leveraging my existing technical skills. Only time will tell with regards to whether this was a smart career move, but I am excited about my new responsibilities, as well as supporting the mission of DHS.

As for this blog, at the very least, I will continue to keep the legacy postings online. However, given that I no longer plan to pursue a CCIE Voice, I will no longer continue with any new lab postings. Moving forward, I may utilize this space to post observations as well as general insights relating to the IT products, solutions, and services that WWT provides to its customers.

Finally, I’d like to thank everyone who has enjoyed my postings and has shared comments, feedback, and/or suggestions over the past 2+ years. I wish everyone the best of luck in their CCIE pursuits and professional endeavors.

Comments on Cisco’s Tandberg Acquisition

2010-05-04T23:10:00.006-04:00

In case you haven’t been following, Cisco completed its acquisition of Tandberg on April 18. By coincidence, I was attending a Tandberg training class at their Reston, VA facility on the first official day of the marriage. There was certainly an atmosphere of excitement in the area during that week.

I had been vaguely familiar with the Tandberg product line prior to my training. At the conclusion of that week of class, it became varies obvious why Cisco choose to pursue this acquisition – Tandberg’s VTC products rock! Tandberg’s impressive offerings include a software video MOVI client, various desktop units, room based solutions, and a Telepresence offering that is absolutely incredible. Their management GUIs are extremely intuitive and I look forward to many of those features being integrated into Cisco’s UC product portfolio (awesome troubleshooting tools!).

As a leading Cisco Gold Partner, I am very excited about this new set of solutions that I can now offer my customers. One of my DOD customers has told me that the word “Tandberg” is often treated as both a verb and a noun and is synonymous to VTC (e.g.: “Please Tandberg me to the Deputy Director”). There will undoubtedly be some kinks in the weeks and months ahead in terms of integrating the product line into Cisco’s UC portfolio. However, this acquisition certainly reinforces John Chamber’s belief that Video Is the next Killer App, as discussed during the 2009 Networkers Conference.

CCIE Voice Lab 1.12 – UCCX

2010-03-19T15:32:00.017-04:00

We will configure Cisco Unified Contact Center Express in Lab 1.12.

CCIE Voice Lab 1.12 Tasks

1. Configure UCCX to work with CUCM using the following parameters:
a. CUCM AXL Username: use your CUCM Admin username and password
b. Cisco Unified CM Telephony Provider Configuration, User Prefix: uccxcti; create a password
c. RmCm Provider Configuration, User ID: uccxrmcm; create a password
d. NTP Server: NY VGWY
e. Number of HR session licenses: 3
f. Recording Count: 6
g. Number of Outbound seats: 6
h. Codec: G711
i. Cisco Unified CCX Administrator: Ari Gold (agold) and David Wright (dwright).
j. Use CTI Ports/DNs beginning with 1201.

2. Configure the auto attendant script to answer calls when a call arrives at 1300. However, when callers hit the AA, they should be greeted with “Welcome to Ballplayers LLC” followed by the default welcome AA. Do not modify the existing AA.

3. Configure an NY Mets ACD Queue that will be triggered when dialing extension 1010. When callers dial 1010, they should be greeted with “Welcome to Ballplayers LLC” followed by the default prompt. Ari Gold should have a new UCCX DN 1011; David Wright should have a new UCCX DN 1012. Ari should also take the call first, unless he is busy. Caller should hear Music On Hold while sitting in queue.

4. Ari and David should be able to log into ACD service from their phone without typing a username and password. Both should be in a ready state once he has selected the “Ready” softkey and remain ready as long has he hasn’t either logged out or selected the “not ready” softkey.

CCIE Voice Lab 1.12 Solutions

The CCIE Lab is notorious for wording task in such a way to as either “confuse” or trip up the test taker (at least this was the case when I took my Route/Switch lab). I’ve worded the tasks in Lab 1.12 to makes the student think about all of the tasks in this lab. For example, just because a particular task comes later, that doesn’t necessarily mean that the test taker must complete those tasks in that particular order.

Also note, the Administration Guide for Cisco Unified CCX and Cisco Unified IP IVR, Release 7.0(1) is only available on CCO as a PDF document. Therefore, I will refer to specific chapters during my explanations below.

1. Prior to configuring UCCX, I begin by provisioning the user parameters in UC Manager; specifically adding the UCCX DNs for Ari Gold and David Wright, as configuring a new UCCX template. First, I create a new Phone Template for agents, and then associate this Phone Button Template with Ari’s and David’s phone.

Next, I add the 1011 and 1012 lines to Ari and David phones, respectively. Finally, under User Management > End User, I associate these new DNs with both Ari and David as their IPCC Extension. See Guidelines for Configuring Agent Phones, page 4-16 of the Administration Guide for Cisco Unified CCX and Cisco Unified IP IVR, Release 7.0(1) for further details.

2. Before we can begin configuring either the AA or ACD, UCCX requires some basic setup. When logging into UCCX the first time, a setup wizard launches. During this wizard, you are prompted to provide the following configuration parameters:

UC Manager IP address: 10.1.10.20
AXL Username: Administrator
Password:
Installation of License
Cisco Unified CM Telephony Provider Configuration, User Prefix: uccxcti; create a password
RmCm Provider Configuration, User ID: uccxrmcm; create a password
NTP Server: NY VGWY
Number of HR session licenses: 3
Recording Count: 6
Number of Outbound seats: 6
Codec: G711
User Configuration: Ari Gold (UCCX Administrator) and David Wright.

For additional information and details, refer to Provisioning Unified CM Telephony Subsystem, page 6-5 of the Administration Guide for Cisco Unified CCX and Cisco Unified IP IVR, Release 7.0(1).

Next, configure the Cisco Unified CM Telephony Call Control Group under Subsystems > Cisco Unified CM Telephony. See Adding a New Unified CM Telephony Call Control Group, page 6-9 of the Administration Guide for Cisco Unified CCX and Cisco Unified IP IVR, Release 7.0(1).

You can verify that the CTI ports are registered with UC Manager under Device > Phone.

3. There are a few things we need to do in order to work with the default AA script. First, record your prompt per the task. Refer to Recording and Uploading Prompt Files, page 10-12 of the Administration Guide for Cisco Unified CCX and Cisco Unified IP IVR, Release 7.0(1) for instructions on using the Microsoft Windows Sound Recorder in Windows XP. Then, upload your prompt in Applications > Prompt Management.

Next, launch your Cisco Unified CCX Editor. Open the Auto Attendant template under File > Open > C: > Program Files > wfavvid > Scripts > Template > IVR > Auto Attendant.aef. On the left side of the editor, expand the Media Folder and drag “Play Prompt” in front of the existing “Play Prompt” in the script. Then, right-click this new prompt and select “Properties”. In the “Prompt” option tab, type the name of your Prompt in “quotations”. Verify the script and then save it in the Script Repository > Default.

To configure the new AA script, go to Application > Application Management > Add a New Application. From the Add a New Application > Application Type drop-down, select Cisco Script Application, then next. Provide the necessary information for the Cisco Script Application and select Add.

Lastly, we need to add a Trigger for this script. Under the Trigger Type drop down, select “Unified CM Telephony Trigger”. Then, provide the necessary Trigger Configuration information, and Add. At this point, you should be able to dial 1300, whereupon you will hear your custom prompt followed by the standard AA.

Refer to the Configuring Script Applications, page 9-3 of the Administration Guide for Cisco Unified CCX and Cisco Unified IP IVR, Release 7.0(1) for additional information and guidance.

Configuring the ACD follows a similar process. Once again, launch the Cisco Unified CCX Editor. This time, open the ICD template under File > Open > C: > Program Files > wfavvid > Scripts > Template > Queuing > Simple Queuing.aef. As before, add a new “Play Prompt” step prior to the first one. However, in order for a call to hear MOH, you must add a Call Hold step and Call Unhold step before and after “Delay DelayedWhileQueued sec”. Verify the script and then save it in the Script Repository > Default.

5. Since UCCX Extensions have already been associated with users, there are two primary tasks left for configuring the NY Mets ACD queue; creating/modifying a script and then setting up another Cisco Script Applications.

Once again, open the Cisco Unified CCX Editor, and select the ICD template. As with the AA script, modify the ICD script to include your custom welcome message. Next, in order for callers to hear MOH while in queue, you must add the “Call Hold” and “Call Unhold” steps to the queueLoop.

Next, in UCCX, go to Subsytems > RmCm and configure a Resource Group and assign the users to that Resource Group. Then, configure your CSQ, Script Applications, and Trigger.

6. The last task involves the configuration of Cisco IP Phone Agent and a few system tweaks. You’ll notice that during the CSQ configuration, Automatic Work is disabled by default, which is what we want. Then, under system parameters, change the value of “Agent State after Ring No Answer*” from the default Ready to Not Ready.

To have Ari and David login into IP Phone Agent (IPPA), refer to the Configure a "One Button Login" for IP Phone Agents example on CCO.

CCIE Voice Lab 1.11 – Unity Connection and CUE

2010-02-08T21:54:00.006-05:00

In CCIE Voice Lab 1.11, the New York, Los Angeles, and London locations will be configured to support voice messaging and associated components.

CCIE Voice Lab 1.11 Tasks

1. Configure Cisco Unity Connection (CUC) integration with CUCM. You must integrate using SCCP. Use pilot 1170, directory number 1171 and 1172, and 1180 for MWI-on and 1181 for MWI-off.

2. Configure Unity Connection voicemail for all users in New York and Los Angeles. Users must be imported from CUCM. Ensure that the users in the directory are listed last name, first name. Accounts should be created with the following requirements:
a. No Limit for Failed Logons
b. Credential Never Expires
c. Minimum Credential Length: 5
d. Stored Number of Previous Credentials: 0
e. No Check for Trivial Passwords
f. User must be prevented from sending Broadcast Messages to Users

3. Configure an Auto Attendant for NY with DN 1000. Configure the AA so that when users press “0” they are routed to Ari Gold at ext. 1001. Business hours are 8AM – 6PM EST/EDT. Customize the greeting as follows:
a. Allow callers to press “4” to use the phone keypad to spell all or part of the last then first name of the Connection user that they want to reach.
b. At the end of the greetings, users should be sent to a Directory Handler. If a Caller Exits, he/she should be sent back to the NY Opening Greeting. If a caller provides No Input, No Selection or Presses Zero, the call should be routed back to Ari Gold’s mailbox.
c. After hours messages should also be stored in Ari Gold’s mailbox.

4. Configure an Auto Attendant for LA with DN 2000. Configure the AA so that when users press “0” they are routed to Arliss Michaels at ext. 2001. Business hours are 8AM – 6PM PST/PDT. Customize the greeting as follows:
a. Allow callers to press “4” to use the phone keypad to spell all or part of the last then first name of the Connection user that they want to reach.
b. At the end of the greetings, users should be sent to a Directory Handler. If a Caller Exits, he/she should be sent back to the LA Opening Greeting. If a caller provides No Input, No Selection or Presses Zero, the call should be routed back to Arliss Michaels’s mailbox.
c. After hours messages should also be stored in Arliss Michaels’s mailbox.

5. Configure a second line appearance on Ari’s phone using *1001. When Ari’s primary extension is busy, calls should roll to this number, followed by voicemail. This line should be able to access voicemail in Ari’s mailbox.

6. London CUCME users should use their local CUE for voicemail, with the following parameters: pilot 3170; and 3180 for MWI-on and 3181 for MWI-off. Create mailboxes for Jerry Maguire and David Beckham with blank passwords and PINS.

7. Create an AA in London using ext 3000. Ensure that callers in NY and LA can reach the AA via VOIP as well as PSTN dialing.

CCIE Voice Lab 1.11 Solutions

1. The Cisco Unified Communications Manager SCCP Integration Guide for Cisco Unity Connection Release 7.x is an excellent document for describing the tasks required to integrate CUC with CUCM. I more or less used the examples and naming conventions provided in Programming the Cisco Unified CM Phone System for Integrating with Cisco Unity Connection section of the Setting Up a Cisco Unified Communications Manager 7.x SCCP Integration with Cisco Unity Connection chapter.

Below is screenshot of the final page of the Cisco Voicemail Port Wizard.

After the wizard finishes, configure the Hunt List and Hunt Pilot.Then, add the MWIs, Voice Mail Pilot Number for the Voice Mail Ports, and Voicemail Profile, per the instructions in Programming the Cisco Unified CM Phone System for Integrating with Cisco Unity Connection.

Now, proceed to Creating a New Integration with Cisco Unified Communications Manager. Do not forget to add your Pub as an AXL Server under the Phone System Configuration, as well as adding Unity Connection as an Application Server in CUCM.

2. To modify “No Limit for Failed Logons”, “Credential Never Expires”, “Minimum Credential Length: 5”, and “Stored Number of Previous Credentials: 0”, modify the default “Voice Mail Authentication Rule” under System Settings > Authentication Rules.

Looking ahead to the AA configuration, it would be wise to create a new schedule under Systems Settings > Schedules. Then, apply this new schedule to the Templates > User Templates > voicemailusertemplate.

Next, to ensure that users cannot send Broadcast Messages to Users on This Server, verify that “User Can Send Broadcast Messages to Users on This Server” is not-checked under Templates > User Templates > voicemailusertemplate > Send Message Settings.

Finally, you can import users from CUCM from Tools > Import Users. Be aware, users in CUCM must have their primary extension define. Visit Creating Multiple User Accounts from Cisco Unified Communications Manager Users for a good overview. Keep in mind that when you import your users, they will inherit the system Timezone. For your LA based users, you will need to modify their Timezone to PST.

3. Now we are ready to create the AA for both New York and Los Angeles. The process if almost identical. Basically, I create two now Call Handlers, “NY-Opening-Greeting” at extension 1000 and “LA-Opening-Greeting” at extension 2000. Edit the Greetings and Caller Input to match the task requirements. I then created to new Directory Handlers, one for NY and another for LA. I edit the Caller Input for each based on the task requirements.

4. Task 5 is relatively straight forward. Create a new Voice Mail Profile for the *1000 extension with a Voice Mail Box Mask of 1000; this strip the “*”. When you add the *1000 dn to Ari’s Phone, make sure that you use this Voice Mail Profile on this line appearance.

5. We now move on to CUE. Given that I covered CUE extensively in the CUCME-CUE Labs, so I will not recap the details here. However, I did run into an issue, which I haven’t fully yet fixed….

Because the SIP dial peer to the AA in London is not H323, it does not register with the gatekeeper. Therefore, I cannot dial 73000 from either NY or LA to hit the AA in London. I tried adding the e164 via the alias commands under gatekeeper. However, this is only a temporary fix and will not work in the actual lab. When you reboot either the gatekeeper (NY) or the CUCME router (London), the CUCME (London) will attempt to register using a random port. Since the alias command uses a static port (either 1719 or random, depending on how you initialing configuring), the RRQ from the gateway will be rejected (RRJ) by the Gatekeeper. I’ve spent a fair number of hours trying to find a work around, nothing has successfully worked. For now, I am moving on. If anyone finds a resolution, please share!

CCIE Voice Lab 1.10 – Quality of Service

2009-12-28T14:23:00.004-05:00

Quality of Service (QoS) will be the focus CCIE Voice Lab 1.10.

CCIE Voice Lab 1.10 Tasks

1. Ensure that Skinny traffic from New York to Los Angeles is set to DSCP CS3. Any and all markings should be done by the endpoint whenever possible.

2. Limit SCCP traffic in both New York and Los Angeles to 30k per endpoint, and exceed traffic should be remarked to AF11.

3. Configure the frame relay link between New York and Los Angeles as if it is a full T1 (1536kpbs) link. Ensure that MLP FLI is enabled on the link. Lastly, configure the QoS as follows:
a. Voice media traffic should have a 30% priority of link bandwidth;
b. Voice signaling traffic should be given 5% of the link bandwidth;
c. All other traffic should be treated with weighted fair queuing.

4. Configure the frame relay link between New York and Los Angeles as if it is a half- T1 (768 kbps) link, with the following QoS parameters:
a. Voice media traffic should have a 192K of link bandwidth prioritized;
b. Voice signaling traffic should be given 38K of the link bandwidth;
c. All other traffic should be treated with weighted fair queuing.

5. Ensure that the New York VGWY, Los Angeles VGWY, and London CUCME send signaling and media traffic at DSCP CS3 and EF respectively.

CCIE Voice Lab 1.10 Solutions

1. By default, SCCP DSCP values are set at CS3 in the CUCM Enterprise Parameters.

Next, identical QoS policies are configured on both the New York and London switches (3750 and NME-16ES-1G-P, respectively). First, enable QoS globally, then define the policed DSCP remarking:

mls qos
mls qos map policed-dscp 24 to 10

Then, create the appropriate access-list to identify the SCCP traffic, following by the class-map to match the traffic, and finally, the QoS policy.

!
access-list 101 permit tcp any any eq 2000
!
class-map match-all SCCP
match access-group 101
!
!
policy-map MARK-SCCP
class SCCP
set dscp cs3
police 30000 8000 exceed-action policed-dscp-transmit

The final step is to create an inbound service-policy for the switchports that have IP phones.

interface FastEthernet1/0/8
description newyork phones
switchport access vlan 11
switchport voice vlan 12
spanning-tree portfast
service-policy input MARK-SCCP

2. The QoS and Traffic Shaping described in task 3 requires the creation Modular QoS CLI, a Virtual Template, and Frame Relay traffic shaping on both the New York and Los Angeles routers. Note, the configurations are identical on both routers, with the exception of the IP Addressing on both sides of the link. The first step it to create the QoS policy.

class-map match-all SIGNAL
match ip dscp cs3
class-map match-all RTP
match ip dscp ef
!
!
policy-map NY-LA-QOS
class RTP
priority percent 30
class SIGNAL
bandwidth percent 5
class class-default
fair-queue

Next, create the Virtual Templates for both New York and Los Angeles. Below is the New York side of the link.

!
interface Virtual-Template102
bandwidth 1536
ip address 172.16.1.1 255.255.255.252
ip ospf network point-to-point
ppp multilink
ppp multilink interleave
ppp multilink fragment delay 10
service-policy output NY-LA-QOS
!

Then, create the frame relay traffic shaping policy, and associate the Virtual Template with the Frame Relay sub-interface, and associate the frame relay traffic shaping policy.

!
map-class frame-relay FRTS-NY-LA
frame-relay cir 1536000
frame-relay bc 15360
frame-relay be 0
frame-relay mincir 1536000
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay lmi-type cisco
!
interface Serial0/2/0.102 point-to-point
description frame relay link to Los Angeles
ip ospf network point-to-point
frame-relay interface-dlci 102 ppp Virtual-Template102
class FRTS-NY-LA
!

3. The QoS configuration between New York and London is slightly different, since the tasks do not instruct us to configure MLP LFI. For this link, the QoS policy-map is defined, reusing the previously configured class-maps. Then, a frame-relay traffic shaping policy is defined, with the QoS service-policy tied to it. Lastly, the FRTS policy is associated with the frame-relay sub-interfaces between New York and London.

!
policy-map NY-LNDN-QOS
class RTP
priority 192
class SIGNAL
bandwidth 38
class class-default
fair-queue
!
!
map-class frame-relay FRTS-NY-LNDN
frame-relay cir 768000
frame-relay bc 7680
frame-relay be 0
frame-relay mincir 768000
service-policy output NY-LNDN-QOS
!
!
interface Serial0/2/0.103 point-to-point
description frame relay link to London
ip address 172.16.1.5 255.255.255.252
ip ospf network point-to-point
frame-relay interface-dlci 103
class FRTS-NY-LNDN
!

4. By default, the MGCP and H323 gateways send media (RTP) marked as ef and signaling marked as af31.

To verify New York, first issue:

newyork#sh dial-peer voice 100 include DSCP
ip media DSCP = ef, ip media rsvp-pass DSCP = ef
ip media rsvp-fail DSCP = ef, ip signaling DSCP = cs3,
ip video rsvp-none DSCP = af41,ip video rsvp-pass DSCP = af41
ip video rsvp-fail DSCP = af41,

Then, modify the markings for each VOIPdDial-peer. Dial-peer 100 is shown below.

newyork(config)#dial-peer voice 100
newyork(config-dial-peer)#ip qos dscp cs3 signaling

In Los Angeles, verify by issuing a “show mgcp” to view the defaults.

losangeles#sh mgcp
!
MGCP media (RTP) dscp: ef, MGCP signaling dscp: af31

To modify, issue

losangeles(config)#mgcp ip qos dscp ef media
losangeles(config)#mgcp ip qos dscp cs3 signaling

then verify

losangeles#sh mgcp
!
MGCP media (RTP) dscp: ef, MGCP signaling dscp: cs3

CUCME marks voice media traffic at DSCP value EF by default and voice signaling DSCP value CS3 by default. These parameters may be changed under the telephony-service CLI parameters. A “show telephony-service” in London verifies the values.

london#sh telephony-service
CONFIG (Version=7.1)
=====================
Version 7.1
Cisco Unified Communications Manager Express
For on-line documentation please see:
http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_products_support_series_home.html

ip source-address 10.1.32.1 port 2000
ip qos dscp:
ef (the MS 6 bits, 46, in ToS, 0xB8) for media
cs3 (the MS 6 bits, 24, in ToS, 0x60) for signal
af41 (the MS 6 bits, 34, in ToS, 0x88) for video
default (the MS 6 bits, 0, in ToS, 0x0) for serviceservice directed-

CCIE Voice Lab 1.9 – Conferencing, Transcoding, and MTP Resources

2009-12-16T22:17:00.012-05:00

CCIE Voice Lab 1.9 requires the set up and configuration of Conferencing, Transcoding, and MTP Resources for Ballplayers, LLC.

CCIE Voice Lab 1.9 Tasks

1. For New York users, configure conferencing resources on the New York VGWY first, followed by the PUB, then SUB.

2. For LA users, configure conferencing resources on the LA VGWY first, followed by the PUB, then SUB.

3. Allow a maximum of 8 users in a conference bridge session. Ensure that when the Conference Controller leaves an AdHoc Conference, the call is dropped.

4. For each location, configure a MeetMe conference bridge using an x100 DN, where x= the appropriate dial plan for each location.

5. For both NY and LA, configure local transcoding resources.

6. Configure the London CUCME router to provide local transcoding and both MeetMe and AdHoc conferencing resources for users. Users should have a distinct join and leave tone.

7. Enable MOH for all three locations. Ensure that MOH files are available in G.711ulaw, G.729, and Wideband. Ensure the MOH loops.

CCIE Voice Lab 1.9 Solutions

The tasks in lab 1.9 require configuration in both the CUCM and VGWYs. The IOS commands will be covered first, followed by the CUCM, and lastly the London CUCME configuration.

1. The first step is to configure the DSP services on the New York and Los Angeles. The configurations on both VGWYs are nearly identical, with one exception pertaining to MOH in Los Angeles. That exception will be discussed separately later.

Essentially, you enable dspfarm services, followed by creating dspfarm profiles, and then associating those profiles with SCCP. The NY VGWY configuration is as follows:

newyork#sh run
!
voice-card 0
dspfarm
dsp services dspfarm
!
!
sccp local Loopback0
sccp ccm 10.1.10.21 identifier 2 version 7.0
sccp ccm 10.1.10.20 identifier 1 version 7.0
sccp
!
sccp ccm group 1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 2 register NY-VGWY-TRANS
associate profile 1 register NY-VGWY-CONF
!
dspfarm profile 2 transcode
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g722-64
codec g729br8
codec g729r8
maximum sessions 2
associate application SCCP
!
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
codec g722-64
maximum sessions 2
associate application SCCP
!

newyork# sh sccp
SCCP Admin State: UP
Gateway Local Interface: Loopback0
IPv4 Address: 1.1.1.1
Port Number: 2000
IP Precedence: 5
User Masked Codec list: None
Call Manager: 10.1.10.21, Port Number: 2000
Priority: N/A, Version: 7.0, Identifier: 2
Trustpoint: N/A
Call Manager: 10.1.10.20, Port Number: 2000
Priority: N/A, Version: 7.0, Identifier: 1
Trustpoint: N/A

Transcoding Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 10.1.10.20, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 2
Reported Max Streams: 4, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: g722r64, Maximum Packetization Period: 30
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum Packetization Period: 30

Conferencing Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 10.1.10.20, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 1
Reported Max Streams: 16, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: g722r64, Maximum Packetization Period: 30
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum Packetization Period: 30

2. Borrowing from the concepts of Gateways > Route Groups > Route Lists, first define the conference bridges and trancoding resources.

Next, define Media Resource Groups (MRG) and assign the conference bridges and trancoding resources accordingly. I’ve created a MRG for each location; New York and Los Angeles.

The MRGs are then added to a Media Resource Groups List (MRGL); one for each location. Watch the ordering, so that HW resources are used prior to SW resources.

Finally, assign the appropriate MRGL to the appropriate Device Pool for each location.

3. Configuring conferencing and transcoding resources for the London CUCME router is nearly identical to as configuring the resources on the NY and LA VGWYs. However, SSCP is associated with CUCME under telephony-service, rather than the UCMs. Rather than revisit the configuration, refer to CUCME-CUE Lab 7 – CUCME Conferencing & Transcoding. I assigned dn 3100 for the MeetMe bridge and 3101 for the AdHoc bridge.

4. There are few tricks for the MOH, specifically for the LA SIP-based location. First, make sure that the “Cisco IP Voice Media Streaming App” is activated under Cisco Unified Serviceability.

Next, make sure that G.711ulaw, G.729, and Wideband are selected under the Service Parameters > Cisco IP Voice Media Streaming App.

The MOH servers are then assigned to the MRGs; see the NY MRG screenshot above. To quickly assign the same MOH file to all phones, go to Device > Device Settings > Common Device Configuration, and create a custom configuration. I’ve chosen “1952 Vincent Black Lightning” from Alt-County band “Reckless Kelly”.

This newly created “MOH Common Device Configuration” can now be assigned to each phone.

When testing MOH up to this point, I noticed the phones based in Los Angeles were not receiving MOH. After some research, I discovered the MOH for SIP phones needs to terminate on an MTP resource on the LA VGWY. Therefore, one additional dspfarm profile is required for the LA VGWY, along with its companion configuration in UCM. This MTP is then assigned to the LA MRG.

losangeles#sh run
!
sccp ccm group 1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 3 register LA-VGWY-MTP
associate profile 1 register LA-VGWY-CONF
associate profile 2 register LA-VGWY-TRANS
!
!
dspfarm profile 3 mtp
codec g711ulaw
maximum sessions software 2
associate application SCCP
!

CCIE Voice Lab 1.8 – SRST and AAR

2009-11-25T09:25:00.020-05:00

This lab will challenge the candidate to configure Survivable Remote Site Telephony (SRST) and Automated Alternate Routing (AAR).

CCIE Voice Lab 1.8 Tasks

1. Configure the Los Angeles router for SIP SRST. Phone should display a “SRST Fallback Active” message.

2. While in SRTS mode, calls to 911 or 9-911 should be route immediately. You may only use on outgoing dial-peer to accomplish this task.

3. Preserve the dial-9 for PSTN access during an SRST scenario.

4. While in SRST node, users should be able to dial 4-digit to NY and 7+3… to London. Calls should be routed over the PSTN without the need for users to add prefixes to these locations. You may not use a Prefix in the dial-peer, and this task must be accomplished using a minimal amount of commands.

5. Ensure that users at New York and Los Angeles are able to call each other when bandwidth limits are met.

CCIE Voice Lab 1.8 Solutions

1. Tasks 1 – 4 involved setting up SRST for SIP phones. A very good reference document is the Cisco Unified SIP SRST System Administrator Guide . First, start by configuring the basis SRST commands on the Los Angeles VGWY.

losangeles#
!
voice register global
system message SRST Fallback Active
max-dn 10
max-pool 10
dialplan-pattern 1 2135432... extension-length 4
!
voice register pool 1
translation-profile incoming emergency
id mac 0021.D8B9.BC72
number 1 2001
codec g722-64
!
voice register pool 2
translation-profile incoming emergency
id mac 0021.D8BA.2373
number 1 2002
codec g722-64
!
!
application
global
service alternate default
!
!
ccm-manager fallback-mgcp
!
!
call-manager-fallback
max-conferences 4 gain -6
transfer-system full-consult
!

2. To configure 911 and 9-911 routing, configure 9-911 translation rule and translation profile. Then, apply the translation profile to the voice register pool configurations. Lastly, create a 911 pots dial-peer.

!
voice translation-rule 1
rule 1 /9911/ /911/
!
!
voice translation-profile emergency
translate called 1
!
!
voice register pool 1
translation-profile incoming emergency
!
voice register pool 2
translation-profile incoming emergency
!
!
dial-peer voice 911 pots
description SRST 911
destination-pattern 911
port 0/1/0:23
forward-digits all
!

3. Task 3 and 4 involve the creation of additional pots dial-peers. However, you need to create some additional translation rules and a translation profile to accommodate the 4-digit and 7+4-digit dialing requirements.

!
voice translation-rule 2
rule 1 /\(1...\)/ /212432\1/
rule 2 /^7\(3...\)/ /207654\1/
!
!
voice translation-profile SRST
translate called 2
!
!
dial-peer voice 2 pots
description SRST Long Distance
destination-pattern 91[2-9]..[2-9]......
incoming called-number .
direct-inward-dial
port 0/1/0:23
!
dial-peer voice 3 pots
description SRST Local 10-Digit
destination-pattern 9[2-9]..[2-9]......
port 0/1/0:23
!
dial-peer voice 4 pots
description SRST London
destination-pattern 901144T
port 0/1/0:23
!
dial-peer voice 5 pots
description SRST 4-digit to NY
translation-profile outgoing SRST
destination-pattern 1...
port 0/1/0:23
!
dial-peer voice 6 pots
description SRST 7+4-digit to London
translation-profile outgoing SRST
destination-pattern 73...
port 0/1/0:23
!

4. Test the SIP SRST fallback by shutting down the WAN link from Los Angeles to New York. First, the phones should failover to SRST and display the “SRST Fallback Active” message. The “show voice register all” will provide the SRST configuration. Lastly, place some test calls, using 4-digit, 7+4-digit, and PSTN dial patterns.

losangeles# sh voice register all
VOICE REGISTER GLOBAL
=====================
CONFIG [Version=7.1]
========================
Version 7.1
Mode is srst
Max-pool is 10
Max-dn is 10
Outbound-proxy is enabled and will use global configured value
System message is SRST Fallback Active
timeout interdigit 10
network-locale[0] US (This is the default network locale for this box)
network-locale[1] US
network-locale[2] US
network-locale[3] US
network-locale[4] US
user-locale[0] US (This is the default user locale for this box)
user-locale[1] US
user-locale[2] US
user-locale[3] US
user-locale[4] US

VOICE REGISTER DN
=================

VOICE REGISTER POOL
===================
Pool Tag 1
Config:
Mac address is 0021.D8B9.BC72
Number list 1 : Pattern is 2001
Proxy Ip address is 0.0.0.0
DTMF Relay is disabled
kpml signal is enabled
Translation-profile incoming emergency

Dialpeers created:

dial-peer voice 40003 voip
destination-pattern 2001
redirect ip2ip
session target ipv4:10.1.22.16:5060
session protocol sipv2
digit collect kpml
codec g722-64 bytes 160
after-hours-exempt FALSE

dial-peer voice 40004 voip
destination-pattern 2135432001
redirect ip2ip
session target ipv4:10.1.22.16:5060
session protocol sipv2
digit collect kpml
codec g722-64 bytes 160
after-hours-exempt FALSE

Statistics:
Active registrations : 1

Total SIP phones registered: 1
Total Registration Statistics
Registration requests : 1
Registration success : 1
Registration failed : 0
unRegister requests : 0
unRegister success : 0
unRegister failed : 0

Pool Tag 2
Config:
Mac address is 0021.D8BA.2373
Number list 1 : Pattern is 2002
Proxy Ip address is 0.0.0.0
DTMF Relay is disabled
kpml signal is enabled
Translation-profile incoming emergency

Dialpeers created:

dial-peer voice 40001 voip
destination-pattern 2002
redirect ip2ip
session target ipv4:10.1.22.17:5060
session protocol sipv2
digit collect kpml
codec g722-64 bytes 160
after-hours-exempt FALSE

dial-peer voice 40002 voip
destination-pattern 2135432002
redirect ip2ip
session target ipv4:10.1.22.17:5060
session protocol sipv2
digit collect kpml
codec g722-64 bytes 160
after-hours-exempt FALSE

Statistics:
Active registrations : 1

Total SIP phones registered: 1
Total Registration Statistics
Registration requests : 1
Registration success : 1
Registration failed : 0
unRegister requests : 0
unRegister success : 0
unRegister failed : 0

5. The final tasks require the configuration of setup and configuration of Automated Alternate Routing (AAR). AAR is disabled by default on CUCM, so the first step is to configure the AAR Service Parameters in CUCM by choosing System > Service Parameters > Cisco Call Manager.

Next, configure an AAR group. Since my Adtran PSTN simulator does not accept the “1” for long distance calls, I simply prefix a “9”. In the CCIE Voice Lab, and possibly your home lab, you may need to prefix “91”.

AAR Partitions and Calling Search Spaced are then created for AAR. Below is the NY AAR CSS, which included the NY AAR LD Partition.

Two new Route Lists are created, one for each location. These new route lists used for the AAR only point to the local PSTN gateways. Below is the NY AAR RL.

Create two new route patterns for ten-digit NY to LA and LA to NY calling (remember, my Adtran PSTN simulator does not accept “1+10-digit” dialing). Link these new route patterns to the appropriate AAR Route lists.

Finally, add the appropriate AAR Calling Search Space and AAR Group to each phone and AAR settings for line.

For testing, I temporary modify the bandwidth between locations to 24kbps (one call). Nail up two calls between each location. With the second call, the phone should display “Network Congestion, Rerouting” and the call should be placed via the PSTN.

CCIE Voice Lab 1.7 – Voice CODECs and CAC

2009-11-19T16:20:00.013-05:00

Now that the dial plan has been properly configured between New York, Los Angeles, and London, this lab will focus on configuring the proper CODECs between locations as well as Call Admission Control.

CCIE Voice Lab 1.7 Tasks
1. Calls within a location should use G.722 wideband.

2. Calls between locations should use G.729.

3. Allow five concurrent calls between New York and Los Angeles.

4. When calls from London to either New York or LA use the IP WAN, they should negotiate G.729. However, in the event that there are any transcoding issues, only one G.722 call should be allowed across the WAN.

CCIE Voice Lab 1.7 Solutions
The tasks in this lab are relatively simple. A good discussion on locations, regions, and CAC are covered Call Admission Control chapter of Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 7.x. You can also click here and here for some old, but decent Gatekeeper configuration examples.

1. The first step is to create regions for New York, Los Angeles, and London and assign the codecs to be used between each location. You may have done some of these task earlier when configure phones.

2. Next, create Device Pools and assign the Regions accordingly.

3. Next, assign your newly create device pools to devices.

4. Create your locations and assign the appropriate bandwidth. Make sure you understand how CUCM allocates bandwidth for a particular codec. Then, assign these locations to the Phones.

5. On the gatekeeper, configure the proper bandwidth settings.

newyork#
!
gatekeeper
zone local newyork ballplayersllc.com 1.1.1.1
alias static 10.1.10.21 1720 gkid newyork gateway voip ras 10.1.10.21 33072 e164 2002 e164 2001 e164 1003 e164 1002 e164 1001
bandwidth total zone newyork 128
no shutdown

6. Finally, nail up some calls between locations to exceed the bandwidth limits. On CUCM phones, once bandwidth limits are hit, the phones should display “Not Enough Bandwidth”. On the gatekeeper, “debug ras” and “show gatekeeper zone status” are useful commands.

CCIE Voice Lab 1.6 – Call Routing

2009-11-10T15:13:00.021-05:00

This lab focuses on developing the Call Routing and dial plan for Ballplayers, LLC. Please note, depending on your PSTN simulation, some task may require digit manipulation not explicitly defined in the tasks. For example, my Adtran does not accept the London international dial plan. Therefore, I will need to strip the 011+44 from the international dialing from New York and Los Angeles. Your solution may vary, depending on what you are using to simulate the PSTN, and what digits that device will accept.

CCIE Voice Lab 1.6 Tasks

1. Ari Gold (1001) and Arliss Michaels (2001) are allowed full dialing privileges, including international. David Wright (1002) and Kobe Bryant (2002) are not allowed international dialing. Finally, Eli Manning can only call on-net calls.

2. New York should be configured with the following call routing options and parameters:

Calls to London: 7+4 digits
Emergency: 911 and 9911
Local: 9+10 digits
Long Distance: 9+1+10 digits
International: 9+011+any number of digits

In addition:

2a. Local calls from New York should user the local VGWY, followed by the Los Angeles VGWY.

2b. Long Distance calls from New York should user the local VGWY, followed by the LA VGWY.

2c. Calls from NY to the LA area code (213) should route via the LA VGWY, followed by the NY VGWY.

2d. International calls to London from NY should use the 7+4 digit pattern via the gatekeeper, followed by the local NY VGWY. Users should not receive secondary dial-tone when calling London extensions.

2e. All other International calls should route via the NY VGWY, followed by the LA VGWY. Eli should be able to call London an on-net call.

3. Los Angeles should be configured with the following call routing options and parameters:

Calls to London: 7+4 digits
Emergency: 911 and 9911
Local: 9+10 digits
Long Distance: 9+1+10 digits
International: 9+011+any number of digits

In addition:

3a. Local calls from LA should user the local VGWY, followed by the NY VGWY.

3b. Long Distance calls from LA should user the local VGWY, followed by the NY VGWY.

3c. Calls from LA to the NY area code (212) should route via the NY VGWY, followed by the LA VGWY.

3d. International calls to London from LA should use the 7+4 digit pattern via the gatekeeper, followed by the local LA VGWY. Users should not receive secondary dial-tone when calling London extensions.

3e. All other International calls should route via the LA VGWY, followed by the NY VGWY. Eli should be able to call London an on-net call.

4. The London dial plan should be configured as follows:

Calls to New York and Los Angeles: 7+4 digits
Emergency: 999 and 9999
Local London: 9+8 digits
Long Distance UK: 9+0+8 digits
International to US: 9+001+any number of digits

5. You may not use any call blocking mechanisms or local routing to accomplish the task in this lab.

6. You may not use the 9.@ NANP wildcard.

7. All external callers should receive the proper E.164 Call ID from the Calling Party.

CCIE Voice Lab 1.6 Solutions
There are three ways to design a dial plan:

• The Traditional Partition/Calling Search Space approach
• The Line/Device CSS approach
• The New Local Route Groups approach

The wording of this lab, in particular task 5 disallowing the use of blocking mechanism and local routing is an attempt to force the user to configure the dial plan using the Traditional Partition/Calling Search Space approach. The dial plan configuration for both New York and Los Angeles is very similar, so the steps below apply to both.

1. First, begin by creating the appropriate partitions for each location.

2. Next, create the Calling Search Spaces (CSS) and assign the Partitions accordingly

3. Route groups are configured next. For each respective route group, only assign the local gateway. For example, for “RG_LA_MGCP_VGWY” only assign the LA VGWY; for RG_NY_H323_VGWY only assign the NY VGWY; and for RG_GKPR only assign gatekeeper trunk configured in the previous lab.

One note about this lab…. During my testing and staging, I ended up removing the Technology Prefix that was required in Lab 1.5. Therefore, you will need to remove this configuration from the trunk as well as the Gatekeeper.

4. The Route Groups are then added to Route Lists. Pay attention to the ordering of the Route Lists in the Route Groups, so that the task requirements are met. For example, below is the ordering for the LA to NY Tail End Hop Off (TEHO) described in the tasks.

5. The Route Patterns are created next, and assigned to the appropriate Route Lists. Here, your configuration may vary slightly from mine, based on your particular PSTN simulator.

For example, in my Adtran only accepts 10-digit dialing (or, at least that is all I could figure it out to accept). Therefore, I apply a “XXXXXXXXXX” mask so that only the trailing ten digits of a call to London is sent. In this example, if a user in NY dials 9-011-44-20-7654-3001, only “20-7654-3001”, which my Adtran then routes to the London PRI. Don’t forget thing such as “Urgent Priority” for 911 and selecting Discard Digits options where appropriate.

6. Lastly, assign the phones and lines to their appropriate partitions in order to honor the Class of Service described in the task.

7. Networking between CUCM and CUCME can be tricky, especially given the tasks as described. For the 7+4-digit dialing, you need to create a translation rule. A rule is also required to add the appropriate prefix to route calls out the PSTN. Finally, for my testing purpose, I create a rule to translate “999” to “911” so that I could test 911 emergency call to my Adtran.

Another helpful hint during testing is to change the preferences of the dial-peer and observe the behavior of the phone class using the “sh voice call summary” command.

!
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
supplementary-service h450.12
h323
!
!
!
voice class codec 1
codec preference 1 g729r8
codec preference 2 g722-64
codec preference 3 g711ulaw
codec preference 4 g711alaw
!
!
translation-rule 1
Rule 1 71 1
Rule 2 72 2
!
!
translation-rule 2
Rule 0 ^999 911
!
!
translation-rule 3
Rule 1 71 2124321
Rule 2 72 2135432
!
!
dial-peer voice 1 pots
description inbound PRI dial-peer
incoming called-number .
direct-inward-dial
port 0/0/0:23
!
dial-peer voice 999 pots
destination-pattern 999
translate-outgoing called 2
port 0/0/0:23
forward-digits 3
!
dial-peer voice 2 pots
description International
destination-pattern 9001T
port 0/0/0:23
!
dial-peer voice 3 pots
description London Local
destination-pattern 9[2-9].......
port 0/0/0:23
!
dial-peer voice 4 pots
description UK Long Distance
destination-pattern 90[2-9].......
port 0/0/0:23
!
dial-peer voice 1000 voip
preference 2
destination-pattern 71...
translate-outgoing called 1
voice-class codec 1
session target ras
dtmf-relay h245-alphanumeric
!
dial-peer voice 2000 voip
preference 2
destination-pattern 72...
translate-outgoing called 1
voice-class codec 1
session target ras
dtmf-relay h245-alphanumeric
!
dial-peer voice 1001 pots
preference 1
destination-pattern 71...
translate-outgoing called 3
port 0/0/0:23
!
dial-peer voice 2001 pots
preference 1
destination-pattern 72...
translate-outgoing called 3
port 0/0/0:23
!

CCIE Voice Lab 1.5 – Voice Gateways

2009-10-16T16:34:00.003-04:00

In CCIE Voice Lab 1.5, tasks will involved configuring the voice gateways in New York, Los Angeles, and London. To conserve DSP resources in my lab, I am only configuring 3 channels per voice gateway.

CCIE Voice Lab 1.5 Tasks

1. Configure the New York voice gateway as an H.323 gateway, and register with CUCM.

2. Configure Los Angeles as an MGCP gateway. However, you cannot use the “ccm-manager config server” command. If the primary CUCM goes down, make sure all endpoints on the MGCP gateway re-register to the backup CUCM.

3. Configure PSTN connectivity for London.

4. Configure the New York voice gateway as a gatekeeper. Register the CUCM servers and London CUCME router to the gatekeeper. The CUCM servers should register with the technology prefix of “1” and the London CUCME router should register with technology prefix “2”.

5. Verify inbound calling from the PSTN.

CCIE Voice Lab 1.5 Solutions

1. First step in adding the New York VGWY to CUCM is to configure the appropriate parameters in the router, including the VWIC module and dial-plan configurations.

newyork#
!
card type t1 0 0
!
network-clock-participate wic 0
!
isdn switch-type primary-ni
!
!
voice class codec 1
codec preference 1 g722-64
codec preference 2 g711ulaw
codec preference 3 g711alaw
codec preference 4 g729r8
!
!
voice class h323 1
h225 timeout tcp establish 3
!
!
controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-3,24
!
!
!
interface FastEthernet0/0.12
description New York Voice VLAN
encapsulation dot1Q 12
ip address 10.1.12.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip bind srcaddr 10.1.12.1
!
!
dial-peer voice 1 pots
description inbound PRI dial-peer
incoming called-number .
direct-inward-dial
port 0/0/0:23
!
dial-peer voice 100 voip
description Voip DialPeer to UCMSUB01
preference 1
destination-pattern 2124321...
voice-class codec 1
voice-class h323 1
session target ipv4:10.1.10.21
incoming called-number .
dtmf-relay h245-alphanumeric
!
dial-peer voice 101 voip
description Voip DialPeer to UCMPUB01
preference 2
destination-pattern 2124321...
voice-class codec 1
voice-class h323 1
session target ipv4:10.1.10.20
incoming called-number .
dtmf-relay h245-alphanumeric
!
dial-peer voice 2 pots
destination-pattern 9T
port 0/0/0:23
!

Next, add the voice gateway to CUCM. Do not forget to modify the significant digits that CUCM receives for inbound calls.

2. The instructions for adding Los Angeles as an MGCP voice gateway explicitly tell us NOT to use the the “ccm-manager config server” command. Therefore, we need to manually configure the MGCP information on the router.

losangeles#
!
card type t1 0 1
!
network-clock-participate wic 1
!
isdn switch-type primary-ni
!
!
controller T1 0/1/0
cablelength long 0db
pri-group timeslots 1-3,24 service mgcp
!
!
interface Serial0/1/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn bind-l3 ccm-manager
no cdp enable
!
!
ccm-manager switchback immediate
ccm-manager redundant-host 10.1.10.20
ccm-manager mgcp
ccm-manager fax protocol cisco
!
mgcp
mgcp call-agent 10.1.10.21 service-type mgcp version 0.1
mgcp fax t38 ecm
mgcp bind control source-interface Vlan22
mgcp bind media source-interface Vlan22
!
mgcp profile default
!
!
!
dial-peer voice 1 pots
service mgcp
incoming called-number .
direct-inward-dial
port 0/1/0:23
!
dial-peer voice 2 pots
service mgcp
destination-pattern 9T
port 0/1/0:23
!

Next, add the router as an MGCP gateway. Again, make sure to modify the significant digits that CUCM receives for inbound calls.

3. Configuring the PSTN and Dial Peers in London is fairly straight forward. Please note, I could not configure my Adtran Atlass 550 to accept the international dial-plan (44-20-7654-3XXX). As a result, I’ve modified the Adtran to accept 20-7654-3XXX. As for the 44 international code for London, I will work around this issue later (TBD).

london#
!
card type t1 0 0
!
network-clock-participate wic 0
!
isdn switch-type primary-ni
!
!
!
controller T1 0/0/0
cablelength short 110
pri-group timeslots 1-3,24
!
!
dial-peer voice 1 pots
description inbound PRI dial-peer
incoming called-number .
direct-inward-dial
port 0/0/0:23
!
dial-peer voice 2 pots
destination-pattern 9T
port 0/0/0:23
!

4. The final gatekeeper configuration requires a little care. First, pay attention to the wording regarding the technology prefix task. Habit may be to add the “#” sign; however the task instructions state only to add a “1” or “2”. Adding the “#” would result in points lost. Also, because the New York VGWY has been added to CUCM with the 10.1.12.1 IP address, you need to use a different IP for gatekeeper.

newyork#
!
gatekeeper
zone local newyork ballplayersllc.com 1.1.1.1
zone local london ballplayersll.com
gw-type-prefix 1* gw ipaddr 10.1.10.21 1720 gw ipaddr 10.1.10.20 1720
gw-type-prefix 2* gw ipaddr 3.3.3.3 1720
no shutdown
!

london#
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
ip ospf network point-to-point
h323-gateway voip interface
h323-gateway voip id newyork ipaddr 1.1.1.1 1719
h323-gateway voip h323-id london
h323-gateway voip tech-prefix 2
!
gateway
timer receive-rtp 1200
!

Next, add the Gatekeeper and Gatekeeper Controller Trunk to CUCM.

newyork#sh gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags
--------------- ----- --------------- ----- --------- ---- -----
3.3.3.3 1720 3.3.3.3 63826 newyork VOIP-GW
H323-ID: london
E164-ID: 3001
E164-ID: 3002
E164-ID: 3003
E164-ID: 3004
E164-ID: 3005
E164-ID: 3333
E164-ID: 2076543001
E164-ID: 2076543002
E164-ID: 2076543003
E164-ID: 2076543004
E164-ID: 2076543005
E164-ID: 2076543333
Voice Capacity Max.= Avail.= Current.= 0
10.1.10.20 41390 10.1.10.20 32833 newyork VOIP-GW
H323-ID: trunk_to_newyork_gkpr_1
Voice Capacity Max.= Avail.= Current.= 0
10.1.10.21 36152 10.1.10.21 32821 newyork VOIP-GW
H323-ID: trunk_to_newyork_gkpr_2
Voice Capacity Max.= Avail.= Current.= 0
Total number of active registrations = 3

newyork#sh gatekeeper gw-type-prefix
GATEWAY TYPE PREFIX TABLE
=========================
Prefix: 1*
Statically-configured gateways (not necessarily currently registered):
10.1.10.21:1720
10.1.10.20:1720
Zone newyork master gateway list:
10.1.10.20:41390 trunk_to_newyork_gkpr_1
10.1.10.21:36152 trunk_to_newyork_gkpr_2

Prefix: 2*
Statically-configured gateways (not necessarily currently registered):
3.3.3.3:1720
Zone newyork master gateway list:
3.3.3.3:1720 london

5. Each location should now be able to receive inbound calls from the PSTN. However, since a dial plan has yet to be configured on CUCM, only London can dial out.

CCIE Voice Lab 1.4 – CUCME London

2009-10-07T08:45:00.002-04:00

Lab 1.4 focuses on setting up Cisco Unified Communications Manager Express for Ballplayers LLC’s London, UK office.

CCIE Voice Lab 1.4 Tasks

1. Configure the CUCME router in London using the four digit extensions in CCIE Voice Lab 1 Scenario Background. The phones should be provisioned as SCCP phones. Enable call waiting on all extensions.

2. Enable support for g.722 wideband codec.

3. Configure extensions 3003 and 3004. On Jerry Maquire’s phone, 3003 and 3004 should ring on the second line appearance. Since David Beckham only has a two-button phone, his primary extension plus 3003 and 3004 should ring his first line appearance. However, his name and primary extension should be displayed next to the line appearance.

4. Configure extension 3005 and assign this to Jerry Maquire. This line should not support call waiting.

5. Since Jerry Maquire is the lead agent and branch manager in London, assign him a 7962.

6. When a call comes into either 3003 or 3004, and a user is on the phone, the incoming call on the busy phone should disable a visible indicator with no ring. Any phone not busy should ring as normal.

7. The layout of the displays on Jerry Maquire’s and David Beckham’s IP Phones should be identical in appearance to the displays for the New York and Los Angeles IP Phones.

8. David Beckham as a nasty habit of accidentally dialing his wife, Posh Spice (Victoria). Therefore, allow dialing on David Beckham’s phone only by selecting the specific line appearance.

9. David Beckham’s published number to the general public is 44-20-7654-3333. When someone from the PSTN dials this number, Jerry Macquire’s phone should ring first, followed by David Beckham’s phone. If no one answers the call for 10 seconds, it is assumed the person is busy and should be switched to DND mode. If neither Jerry nor David answers, the call should be forwarded to DN 3000.

CCIE Voice Lab 1.4 Solutions

1. Since I have previously discussed in detail setting up CUCME in both the CUCME-CUE Labs and Connection-CUCME Labs, I will not revisit the setup in detail. Below is the initial telephony-service configuration.

london#
!
tftp-server flash:ringtones/Analog1.raw alias Analog1.raw
tftp-server flash:ringtones/Analog2.raw alias Analog2.raw
!etc
!
!
telephony-service
em logout 0:0 0:0 0:0
max-ephones 10
max-dn 20
ip source-address 10.1.32.1 port 2000
service phone g722CodecSupport 2
service phone handsetWidebandEnable 1
service phone headsetWidebandEnable 0
service phone handsetWidebandUIControl 0
system message Your current options
load 7942 SCCP42.8-4-2S
load 7962 SCCP42.8-4-2S
dialplan-pattern 1 442076543... extension-length 4
max-conferences 8 gain -6
transfer-system full-consult
secondary-dialtone 9
create cnf-files version-stamp 7960 Oct 06 2009 21:46:31

2. Configuring the ephone DNs is fairly simple. Keep in mind, extension 3001 – 3004 are dual line; extension 3005 is a single line, thereby disabling call waiting.

!
ephone-dn 1 dual-line
number 3001
label Jerry Maquire 3001
description 44-20-7654-3001
name Jerry Maquire
!
!
ephone-dn 2 dual-line
number 3002
label David Beckham 3002
description 44-20-7654-3002
name David Beckham
!
!
ephone-dn 3 dual-line
number 3003
!
!
ephone-dn 4 dual-line
number 3004
!
!
ephone-dn 5
number 3005
!

3. Things get a little more tricky when configuring the IP Phones.

For Jerry Maquire, ephone-dn 1 is assigned to button 1; ephone-dn 3 and ephone-dn 4 are assigned to button 2 as overlays, using the “c” option rather than the “o” option, which enables call-waiting. Extension 3005, ephone-dn 5, is assigned to button 3.

On David Beckham’s phone, ephone-dn’s 2, 3, and 4 are assigned to button 1 as overlays, also using the “c” option rather than the “o” option. In addition, the “auto-line incoming” command is add, forcing David to either pick up his handset or pressing the speaker-phone button, then pressing line appearance button 1, in order to place a call. This should help prevent him from accidentally dialing his wife, “Posh Spice”.

!
ephone 1
device-security-mode none
description Jerry Maquire
mac-address 0024.97AB.1FB5
username "jmaquire" password null
codec g722-64
type 7962
button 1:1 2c3,4 3:5
!
!
!
ephone 2
device-security-mode none
description David Beckham
mac-address 0021.D8BA.23A1
username "dbeckham" password null
codec g722-64
type 7942
auto-line incoming
button 1c2,3,4
!

4. Finally, a sequential hunt-group will route incoming calls to 3333 (or 44-20-7654-3333) to Jerry Maquire first, followed by David Beckham.

!
ephone-hunt 1 sequential
pilot 3333
list 3001, 3002
final 3000
timeout 10, 10
auto logout 1
!

CCIE Voice Lab 1.3 – Basic CUCM Phone and User Configuration

2009-10-01T20:33:00.008-04:00

In lab 1.3, the IP Phones which auto registered in Lab 1.2 will be assigned their correct four digit extensions. Users will also be provisioned on the system. This lab will not cover detailed phone or dial plan configuration.

CCIE Voice Lab 1.3 Tasks

1. Integrate UCM with LDAP / Active Director for user information. (Note, if you do not have AD in your lab, add the users manually.)

2. Assign the proper extension to each phone in New York and Los Angeles based on the information provided in CCIE Voice Lab 1 Scenario Background.

3. New York IP Phones should be SCCP; Los Angeles IP Phones should be SIP.

4. All phones should prefer UCMSUB01 as its preferred CUCM.

5. New York and Los Angeles IP Phones should reflect their appropriate timezones.

6. IP Phones at each location should use the G.722 codec. Calls between locations should use a low bandwidth, high-quality codec.

7. Both Ari and Arliss should be assigned a 7962 IP Phone.

8. Each users’ first name, last name, and four digit extension should be displayed on the line appearance of each phone.

CCIE Voice Lab 1.3 Solutions

1. Active Directory / LDAP integration involves three steps. First, begin with the basic LDAP System Configuration under System > LDAP > LDAP System and select Microsoft Active Directory under the LDAP Server Type and sAMAccountName under LDAP Attribute for User ID.

Next, configure LDAP Directory information under System > LDAP > LDAP Directory. Below is a screen shot.

Finally, provide the necessary credentials for LDAP Authentication under System > LDAP > LDAP Authentication. You can verify that your UCM is synchronizing with Active Directory by going to User Management > End User to verify that the system has been populated with the users.

2. Word of caution on the next steps…. While this is how I configured my phones, this process may not be the most expedient during the actual CCIE Voice Lab. Remember, time management is key. However, for learning purposes, here are the steps I followed for setting up the phones for New York and Los Angeles…

First, I begin be creating a CUCM group, “Ballplayers_Sub_Pub”, with the subscriber server first in priority.

Next, I created two Date/Time Groups, one for New York, and another for Los Angeles, with the appropriate timezone and NTP information.

Two Regions are then created, one for New York and one for Los Angeles, with the appropriate codecs assigned accordingly.

A Device Pool for both New York and Los Angeles is created. For each Device Pool, modify Cisco Unified Communications Manager Group, Date/Time Group, and Region. Below is the NewYorkDevicePool.

Lastly, I go to System > Cisco Unified CM and disable the Auto Registration previously configured in lab 1.2. This will come into play when we modify the Los Angeles phones for SIP.

3. At the conclusion of lab 1.2, the phones for New York and Los Angeles had registered with the Publisher (UCMPUB01) via auto configuration. By going to Device > Phone, the appropriate parameters for each phone can be modified. For New York SCCP phones, the following parameters are changed and/or configured:

Description > a helpful description for reference
Device Pool > select the device poolOwner User ID > select the end user

Then, proceed to configure the line settings:

Configure the Los Angeles SIP phones requires a few extra steps. First, since the phones for Arliss Michaels and Kobe Bryant auto-registered as SCCP, they first must be deleted.. This was why auto-registration was disabled. If the phone were removed while auto-registration still enabled, the phones would simply re-register. Hint, note the MAC address of each phone prior to deletion. Then, manually add each device as a SIP phone. The process is very similar to adding a SCCP phone, except you need to modify some of the Protocol Specific Information, notably the Device Security Profile and SIP Profile. For now, select the defaults available in CUCM.

Upon completion of adding the phones, modify the lines for Arliss and Kobe. At this point, phones should be able to call each other, whether within each location or too/from each location.

CCIE Voice Lab 1.2 – Initial Cisco Unified Communications Manager Configuration

2009-09-28T11:59:00.006-04:00

Lab 1.2 will explore the initial Cisco Unified Communications Manager (CUCM) configuration and setup. I’ve built two CUCM virtual machines on a VMware ESX 3.5 server. CUCM 7.x release includes a “starter license”, which provided 150 DLUs and a 3 node license. Follow the instructions in the Unity Connection-CUCME Lab 3 – Unity Connection Installation on VMware ESX 3.5 post for the process of building CUCM on VMware ESX 3.5.

CCIE Voice Lab 1.2 Tasks
1. Activate all appropriate and necessary Network and Feature Services.

2. Ensure that the call processing cluster does not need to rely on DNS for any services.

3. Ensure that the interdigit timeout does not exceed 5 seconds.

4. Quickly provision the phones in New York and Los Angeles.

CCIE Voice Lab 1.2 Solutions
1. First step is to log into the publisher, UCMPUB01. From there, navigate to System > Servers. If your servers are listed by their hostname, click each one and change to their IP Address.

2. Next stop, visit the Cisco Unified Serviceability interface. From there, Tools > Control Center – Network Services and verify everything in functioning correctly.

3. Next, the Tools > Control Center – Feature Services in the Cisco Unified Serviceability interface shows that by default, these services are deactivated. By going to Tools > Service Activation, we can select each server and then activate accordingly. To understand which service to activate, go to the Help > This Page and review the information in Table 11-1.

After activating the appropriate services for the Publisher and Subscriber, you can verify status by navigating to Tools > Control Center – Feature Services in the Cisco Unified Serviceability.

4. Returning to Cisco Unified CM Administration, go to System > Enterprise Parameters. Modify the Phone URL Parameters that reference UCMPUB01 to 10.1.10.20.

5. To modify the interdigit timeout, go to System > Service Parameters. Select the Publisher (10.1.10.20) in the Server drop down, followed by Cisco CallManager (Active) in the Service drop down. Look for the T302 Timer, and modify from the default 15000ms to 5000ms.

6. The easiest way to quickly provision phones is to enable auto registration. To accomplish this task, navigate to System > Cisco Unified CM and select the Publisher server. Use a phantom number range, such as 7000 to 7099, and uncheck the “Auto-registration Disabled on this Cisco Unified Communications Manager” box.

7. After a few minutes, the phones should register with UCMPUB01.

Pics of my Lab & Gear

2009-09-26T16:49:00.004-04:00

CCIE Voice Lab 1.1 Solutions

2009-09-22T17:03:00.002-04:00

Rather than dissect each sub-task individually, I will review each device, and then circle back around on verifying connectivity. One thing to keep in mind with the CCIE LAB, you needn’t necessarily configure everything in the order presented in the lab guide.

1. Below is the configuration for the frame relay switch. Also note, I’ve configured this router to synchronize with an NTP server on the Internet. This router will then act as the NTP server for the lab devices.

ISP#
!
clock timezone EST -5
clock summer-time EDT recurring
!
frame-relay switching
!
!
interface Serial0/0/0
description frame-relay link to London
no ip address
encapsulation frame-relay
no fair-queue
clock rate 128000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 301 interface Serial0/0/1 103
!
interface Serial0/0/1
description frame-relay to New York
no ip address
encapsulation frame-relay
clock rate 128000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 102 interface Serial0/1/0 201
frame-relay route 103 interface Serial0/0/0 301
!
interface Serial0/1/0
description frame-relay link to Los Angeles
no ip address
encapsulation frame-relay
clock rate 128000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 201 interface Serial0/0/1 102
!
ntp source FastEthernet0/0
ntp update-calendar
ntp server 198.82.1.201

2. Next, we’ll take a look at the New York router. First, the basic configuration parameters for the IP addressing, including the WAN (frame relay) and LANs/VLANs.

newyork#
!
interface FastEthernet0/0.1
description link to Internet
encapsulation dot1Q 1 native
ip address 10.1.1.101 255.255.255.0
!
interface FastEthernet0/0.10
description New York Server VLAN
encapsulation dot1Q 10
ip address 10.1.10.1 255.255.255.0
!
interface FastEthernet0/0.11
description New York Data VLAN
encapsulation dot1Q 11
ip address 10.1.11.1 255.255.255.0
!
interface FastEthernet0/0.12
description New York Voice VLAN
encapsulation dot1Q 12
ip address 10.1.12.1 255.255.255.0
!
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.102 point-to-point
description frame relay link to Los Angeles
ip address 172.16.1.1 255.255.255.252
ip ospf network point-to-point
frame-relay interface-dlci 102
!
interface Serial0/2/0.103 point-to-point
description frame relay link to London
ip address 172.16.1.5 255.255.255.252
ip ospf network point-to-point
frame-relay interface-dlci 103
!

Next, the routing, including a default route to the Internet:

!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.0 0.0.0.255 area 1
network 10.1.10.0 0.0.0.255 area 1
network 10.1.11.0 0.0.0.255 area 1
network 10.1.12.0 0.0.0.255 area 1
network 172.16.1.0 0.0.0.255 area 0
!
ip route 0.0.0.0 0.0.0.0 10.1.1.3

Finally, some of the key “IP services” configuration in the router, including the DHCP scopes:

!
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
!
clock timezone EST -5
clock summer-time EDT recurring
!
ip dhcp excluded-address 10.1.11.1 10.1.11.15
ip dhcp excluded-address 10.1.12.1 10.1.12.15
!
ip dhcp pool newyork-data
network 10.1.11.0 255.255.255.0
update dns both
default-router 10.1.11.1
domain-name ballplayersllc.com
dns-server 10.1.10.11 4.2.2.1
!
ip dhcp pool newyork-voice
network 10.1.12.0 255.255.255.0
update dns both
default-router 10.1.12.1
domain-name ballplayersllc.com
option 150 ip 10.1.10.20
dns-server 10.1.10.11 4.2.2.1
!
!
ip domain name ballplayersllc.com
!
ntp source FastEthernet0/0.1
ntp update-calendar
ntp server 10.1.1.4

3. Below is are the pertinent pieces of the configuration for the 3750 switch for the New York LAN/VLANs.

s1-newyork#
!
interface FastEthernet1/0/2
description to NewYork
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,10-12
switchport mode trunk
spanning-tree portfast trunk
!
!
interface FastEthernet1/0/8
description newyork phones
switchport access vlan 11
switchport voice vlan 12
spanning-tree portfast
!
interface FastEthernet1/0/9
description newyork phones
switchport access vlan 11
switchport voice vlan 12
spanning-tree portfast
!
interface FastEthernet1/0/10
description newyork phones
switchport access vlan 11
switchport voice vlan 12
spanning-tree portfast
!
!
interface Vlan1
ip address 10.1.1.3 255.255.255.0
!
interface Vlan10
description newyork-management
ip address 10.1.10.2 255.255.255.0
!
interface Vlan11
description newyork-data
ip address 10.1.11.2 255.255.255.0
!
interface Vlan12
description newyork-voice
ip address 10.1.12.2 255.255.255.0
!

4. Next stop is Los Angeles. The configuration here is very similar to New York. Note, this router uses a 4-port Ethernet Switch HWIC module.

losangeles#sh start
!
clock timezone PST -8
clock summer-time PST recurring
!
!
ip dhcp excluded-address 10.1.21.1 10.1.21.15
ip dhcp excluded-address 10.1.22.1 10.1.22.15
!
ip dhcp pool losangeles-data
network 10.1.21.0 255.255.255.0
update dns both
default-router 10.1.21.1
dns-server 10.1.10.11 4.2.2.1
domain-name ballplayersllc.com
!
ip dhcp pool losangeles-voice
network 10.1.22.0 255.255.255.0
update dns both
default-router 10.1.22.1
dns-server 10.1.10.11 4.2.2.1
domain-name ballplayersllc.com
option 150 ip 10.1.10.20
!
!
ip domain name ballplayersllc.com
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
ip ospf network point-to-point
!
interface FastEthernet0/0
description link to Internet
ip address 10.1.1.102 255.255.255.0
duplex auto
speed auto
!
!
interface FastEthernet0/3/0
description losangeles ip phones
switchport access vlan 21
switchport voice vlan 22
!
interface FastEthernet0/3/1
description losangeles ip phones
switchport access vlan 21
switchport voice vlan 22
!
interface FastEthernet0/3/2
description losangeles ip phones
switchport access vlan 21
switchport voice vlan 22
!
interface FastEthernet0/3/3
description losangeles ip phones
switchport access vlan 21
switchport voice vlan 22
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.201 point-to-point
description frame relay to New York
ip address 172.16.1.2 255.255.255.252
ip ospf network point-to-point
snmp trap link-status
frame-relay interface-dlci 201
!
!
interface Vlan20
description Los Angeles Server VLAN
ip address 10.1.20.1 255.255.255.0
!
interface Vlan21
description Los Angeles Data VLAN
ip address 10.1.21.1 255.255.255.0
!
interface Vlan22
description Los Angeles Voice VLAN
ip address 10.1.22.1 255.255.255.0
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 2
network 10.1.20.0 0.0.0.255 area 2
network 10.1.21.0 0.0.0.255 area 2
network 10.1.22.0 0.0.0.255 area 2
network 172.16.1.0 0.0.0.255 area 0
!
ip route 0.0.0.0 0.0.0.0 10.1.1.3
!
ntp source FastEthernet0/0
ntp update-calendar
ntp server 10.1.1.4

5. London’s configuration is very similar to the other locations, with a few exceptions. First, the option 150 command for the voice DHCP scope points to the router, since this is will be a CUCME location. Also, London’s router has an NME-16ES-1G-P, which from the perspective of the router, looks like an independent switch.

london#sh start
!
clock timezone GMT 0
clock summer-time BST recurring
!
ip dhcp excluded-address 10.1.31.1 10.1.31.15
ip dhcp excluded-address 10.1.32.1 10.1.32.15
!
ip dhcp pool london-data
network 10.1.31.0 255.255.255.0
update dns both
default-router 10.1.31.1
dns-server 10.1.10.11 4.2.2.1
domain-name ballplayersllc.com
!
ip dhcp pool london-voice
network 10.1.32.0 255.255.255.0
update dns both
default-router 10.1.32.1
domain-name ballplayersllc.com
dns-server 10.1.10.11 4.2.2.1
option 150 ip 10.1.30.1
!
!
ip domain name ballplayersllc.com
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
ip ospf network point-to-point
!
interface FastEthernet0/0
description link to Internet
ip address 10.1.1.103 255.255.255.0
duplex auto
speed auto
!
!
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.301 point-to-point
description frame relay to New York
ip address 172.16.1.6 255.255.255.0
ip ospf network point-to-point
snmp trap link-status
frame-relay interface-dlci 301
!
!
interface GigabitEthernet1/0
no ip address
!
interface GigabitEthernet1/0.30
description London Server VLAN
encapsulation dot1Q 30 native
ip address 10.1.30.1 255.255.255.0
!
interface GigabitEthernet1/0.31
description London Data VLAN
encapsulation dot1Q 31
ip address 10.1.31.1 255.255.255.0
!
interface GigabitEthernet1/0.32
description London Voice VLAN
encapsulation dot1Q 32
ip address 10.1.32.1 255.255.255.0
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.0 0.0.0.255 area 3
network 10.1.30.0 0.0.0.255 area 3
network 10.1.31.0 0.0.0.255 area 3
network 10.1.32.0 0.0.0.255 area 3
network 172.16.1.0 0.0.0.255 area 0
!
ip route 0.0.0.0 0.0.0.0 10.1.1.3
!
ntp source FastEthernet0/0
ntp update-calendar
ntp server 10.1.1.4

6. As mentioned above, I am leveraging a NME-16ES-1G-P Ethernet Switch Module to function as a “3750” in London. For all intents and purposes, the router “views” this module as a separate device. See here for a detailed explanation and here for an example of how I previous configured this module. Below is the pertinent configuration.

london-s1#
!
clock timezone GMT 0
clock summer-time BST recurring
!
!
interface FastEthernet1/0/1
description london ip phones
switchport access vlan 31
switchport voice vlan 32
spanning-tree portfast
!
interface FastEthernet1/0/2
description london ip phones
switchport access vlan 31
switchport voice vlan 32
spanning-tree portfast
!
!etc…!
!
!
interface Vlan1
no ip address
shutdown
!
interface Vlan30
description London Server Vlan
ip address 10.1.30.2 255.255.255.0
!
interface Vlan31
description London Data Vlan
ip address 10.1.31.2 255.255.255.0
!
interface Vlan32
description London Voice Vlan
ip address 10.1.32.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.30.1
!

7. Finally, some quick ping tests verify connectivity.

newyork#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/28/32 ms

newyork#ping 172.16.1.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.6, timeout is 2 seconds:
!!!!!

newyork#ping 10.1.21.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.21.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/29/32 ms

newyork#ping 10.1.31.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.31.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/32/40 ms
newyork#

CCIE Voice Lab 1.1 – LAN, WAN, and IP Services

2009-09-22T17:01:00.003-04:00

The purpose of CCIE Voice Lab 1.1 is to configure the LAN, WAN and IP Services that will provide the foundation for the entire series of labs. Refer to the CCIE Voice Lab 1 Scenario Background post for a diagram and IP addressing information.

CCIE Voice Lab 1.1 Tasks
Perform the following tasks for CCIE Voice Lab 1.1:

1. Configure LAN and WAN based on the information provided in CCIE Voice Lab 1 Scenario Background.

2. Configure the WAN / Frame Relay as point to point links. On the WAN router, set the clockrate to 128000.

3. Configure OSPF as the routing protocol. The WAN should be area 0; New York LAN subnets area 1; Los Angeles LAN subnets area 2; London LAN subnets area 3.

4. Configure the Frame Relay router as an NTP server and synchronize each router with it. Set the time zones as appropriate.

5. Set up DHCP services for the Voice and Data VLANs. The TFTP server for New York and Los Angeles should point to the UC Manager server in NY. The TFTP server address for London should point to itself using the Voice VLAN IP address (VLAN 32). Exclude the first /28 block from each DHCP scope.

6. Configure switch ports for IP phones.

CCIE Voice Lab 1

2009-09-14T23:18:00.007-04:00

CCIE Voice Lab 1 Scenario Background

Ballplayers, Inc. is a sports marketing firm headquartered in New York City, NY and branch offices in Los Angeles, CA and London, England. The firm represents both current and retired athletes and their associated marketing ventures. The firm had previous piloted Cisco Unified Communications Manager Express and Cisco Unity Connection. Ballplayers, LLC is now interested in deploying an enterprise Cisco Unified Communications solution that includes Cisco Unified Communications Manager, Cisco Unity Connection, Cisco Unified Contact Center Express, and Cisco Unified Presence. Finally, they may also pilot Cisco MeetingPlace Express in conjunction with this solution.***

***Note: I will proceed with MPE only as time permits and for personal learning. MPE is not on the CCIE Voice Lab Blueprint.

Below is a high-level design of the Cisco Unity Connection Pilot.

The following are the VLANs, IP Subnetting, Server Addressing, PSTN E.164 Address, and User/Phone information for this lab. Please note and realize, I may change and/or tweak this as I progress.

The first lab will discuss the basic IP setup requirements for New York, Los Angeles, and London.

Unity Connection-CUCME Labs: Wrap Up

2009-09-09T23:28:00.002-04:00

After some thoughtful consideration, I am going to end any further development of the Unity Connection-CUCME Labs. When I initially launched my study CCIE Voice study efforts in July of 2008, my intention was to drill deep on each component of the lab. However, I've reached the conclusion that while this approach was worthwhile, it was also a tedious and time-consuming process. At the rate I am moving and studying, around normal work responsibilities and daily life, I would be sitting for the lab sometime in 2011! LOL

Instead, I am going to plow ahead with developing more “comprehensive” lab incorporating all technologies. The upside is I hope to accelerate the study process and aim to sit for the lab sometime in late spring / early summer 2010. The possible downside would be failing to delve deep enough to anticipate everything that could be thrown at me.

Look for a new series of postings shortly!

Unity Connection-CUCME Lab 7 – Baltimore CUE

2009-08-31T23:36:00.000-04:00

This lab will revisit setting up CUE in Baltimore for eventual integration with Unity Connection via VPIM. It will be very similar to CUCME-CUE Lab 8.

Unity Connection Lab 7.1 – Baltimore CUE Tasks

1. Configure the Baltimore CUCME router to interface with CUE, using IP address 10.1.12.3/24.

2. Use extension 1999 as the voicemail pilot.

3, Use 8000 and 8001 for MWI.

4. Create voicemail users and mailboxes via the CUE CLI.

5. Mailboxes should be limited in size to accommodate up to 50 users on a AIM-CUE.

6. Make sure that messages can be forward via either dial by name or by extension.

7. Provision the system for GUI access.

Unity Connection Lab 7.2 – Baltimore CUE Verification

Since the tasks here are almost identical to CUCME-CUE Lab 8, please refer to that previous post for help on answers. Note, the Baltimore dial plan for Arliss Michaels and Cal Ripken is slightly different, refer to Unity Connection-CUCME Scenario Background.

Unity Connection Lab 7.3 – Baltimore CUE Wrap-up

The original intention for this lab was to stage Baltimore and then integrate with Unity Connection via VPIM. However, after some thought, I am not sure this is applicable for the CCIE Voice Lab. During the CCIE Voice Techtorial and Cisco Live 2009, the present suggested that the CCIE Voice lab would not have a DNS server. Based on some initial research for VPIM integration, DNS is a requirement. Therefore, one could infer that VPIM would not be tested in the Voice Lab.

That said, I will spend some time pretesting VPIM integration between Baltimore CUE and Unity Connection. If this testing consumes too much time and integration with DNS, I may abort and move on to some other items.

Unity Connection-CUCME Lab 6 – Unity Connection & Los Angeles CUCME Integration

2009-08-20T23:13:00.003-04:00

Unity Connection-CUCME Lab 6 is basically a duplication of Unity Connection-CUCME Lab 4 – Unity Connection & CUCME New York Integration. However, due to the limited number of ports in the Unity Connection demo license, we need to make some modifications to what was done in Unity Connection-CUCME Lab 5 – Unity Connection & CUCME Baltimore Integration.

Lab 6.1 – Unity Connection & Los Angeles CUCME Integration Tasks

1. Remove all voicemail configuration parameters in the Baltimore CUCME router.

2. Remove all telephony integration settings for Baltimore in Unity Connection, including the users.

3. Configure the Los Angeles CUCME router to interface with Unity Connection via a SIP Trunk.

4. Use extension 2999 as the voicemail pilot.

5. Create voicemail users and mailboxes for LA users for testing purposes. However, make the users E.164 their primary voicemail box number and their 4-digit extension

6. Use PIN 135246 for each user and ensure that it never expires.

7. Users should be forced to enroll the first time they access Unity Connection.

8. Ensure that users receive their proper greeting when they dial from their Cisco IP Phone.

Lab 6.2 – Unity Connection & Los Angeles CUCME Integration Verification

1. The first two tasks involve removing the integration between Unity Connection and Baltimore. On Unity Connection, first remove the users (Arliss Michaels & Cal Ripken), then the phone system, port group, and ports.

On the Baltimore CUCME router, the commands to remove the configuration for Unity Connection is as follows:

baltimore(config)#no dial-peer voice 2999 voip
baltimore(config)#telephony-service
baltimore(config-telephony)#no voicemail 2999
baltimore(config-telephony)#ephone-dn 1
baltimore(config-ephone-dn)#no call-forward busy 2999
baltimore(config-ephone-dn)#no call-forward noan 2999 timeout 4
baltimore(config-ephone-dn)#ephone-dn 2
baltimore(config-ephone-dn)#no call-forward busy 2999
baltimore(config-ephone-dn)#no call-forward noan 2999 timeout 4
baltimore(config-ephone-dn)#no ephone-dn 5 dual-line
baltimore(config)#no ephone-dn 6
baltimore(config)#no ephone 3

2. Configuring the Los Angeles CUCME router is nearly identical to the configuration parameters added in Lab 4. To review, refer to Unity Connection-CUCME Lab 4.

3. Because the lab instructions states to configure the user extension using their E.164 address, we have to make some tweaks. First, a screen shot of Jerry Maquire’s Basic User information. Note that Jerry is associated with the LA-CUCME phone system

Next, we need to define Jerry Maquire’s four-digit extension as an alternate extension.

Finally, we need to uncheck the “Inherit User’s Extension” and add Jerry’s four-digit extension under his MWI settings. Repeat the above for Kobe Bryant.

4. Simple enough, right? Jerry and Kobe should be able access Unity Connection. Unfortunately, this was not the case.

I first tested the phone system integrations after adding LA, and Unity Connection indicated everything was functional. However, when I pushed the voicemail key on the phone, I received a busy response. Dialing 2999 directly also returned the same result.

I then proceeded to walk through various troubleshooting procedures, such as placing calls across the “WAN” to other location, ping tests, and various debug voice commands; everything was telling me calls and IP routing was functioning correctly.

Stumped, I begin exploring additional debugs one by one. Debug ccsip revealed the problem, buried in lines of output. I added the LA CUCME router to Unity Connection using the voice vlan subnet IP address 10.1.32.1. As I combed through the debug output, a 172.16.1.5 address caught my attention. It appears that Unity Connection was sending response to the LAN WAN link IP, which is the last hop IP leaving LA to NY. Changing the Server address in Unity Connection for LA from 10.1.32.1 to 172.16.1.5 corrected the problem.

Lab 6.3 – Unity Connection & Los Angeles CUCME Integration Wrap-up

Interestingly, my configuration in Lab 4 did not produce this problem because I added the NY CUCME router to Unity Connection using its 10.1.20.1 address, which is on the same subnet as Unity Connection. Another valuable lesson is using a different, easily recognizable IP Addressing scheme for the WAN (172.16.1.x), rather than borrowing a subnet from the same 10-space used for the VLANS. I wonder how easily I would have spotted Unity Connection seeking LA’s WAN interface I had chosen a 10 address space for the WAN.

Unity Connection-CUCME Lab 5 – Unity Connection & CUCME Baltimore Integration

2009-08-11T16:33:00.001-04:00

Now that the New York CUCME has been integrated with Unity Connection, we will now provision basic voice mail connectivity for the CUCME users in Baltimore.

Lab 5.1 – Unity Connection & Baltimore CUCME Integration Tasks

1. Configure the Baltimore CUCME router to interface with Unity Connection via SCCP.

2. Use extension 2999 as the voicemail pilot.

3. Create voicemail users and mailboxes for Baltimore users for testing purposes.

4. Use PIN 135246 for each user and ensure that it never expires.

5. Users should be forced to enroll the first time they access Unity Connection.

6. Ensure that users receive their proper greeting when they dial from their Cisco IP Phone.

Lab 5.2 – Unity Connection & Baltimore CUCME Integration Verification

1. The first step for this lab is to configure the Baltimore CUCME router to integrate with Unity Connection. The first document to review is the Cisco Unified Communications Manager Express SCCP Integration Guide for Cisco Unity Connection Release 7.x, specifically the section “Programming a Cisco Unified Communications Manager Express Router to Integrate with Cisco Unity Connection (Without a Connection Cluster)”.

Note, this document does not call out the need for a VOIP dial-peer, which of course is necessary in order for Baltimore to connect with Unity Connection in New York. Also, pay attention to both how the actual ephone integration works, as well as MWI; both are different than CUE.

The appropriate sections of the configuration are below.

baltimore#sh run
!
!
dial-peer voice 2999 voip
description VOIP peer to Unity Connection
destination-pattern 2999
session target ipv4:10.1.20.20
codec g711ulaw
no vad
!
!
telephony-service
voicemail 2999
!
!
ephone-dn 1 dual-line
number 1001
label Arliss Michaels 1001
description 410-555-1001
name Arliss Michaels
call-forward busy 2999
call-forward noan 2999 timeout 4
!
!
ephone-dn 2 dual-line
number 1002
label Cal Ripken 1002
description 410-555-1002
name Cal Ripken
call-forward busy 2999
call-forward noan 2999 timeout 4
!
!
!
!
ephone-dn 5 dual-line
number 2999
description CUC1-VI1
name Unity Conneciton
huntstop channel
!
!
ephone-dn 6
number 8000 secondary 8001
mwi on-off
!
!
!
ephone 3
device-security-mode none
vm-device-id CUC1-VI1
button 1:5
!

2. The Unity Connection Integration is clearly documented in the “Creating a New Integration with Cisco Unified Communications Manager Express” section of the Cisco Unified Communications Manager Express SCCP Integration Guide for Cisco Unity Connection Release 7.x guide.

3. Add Arliss Michaels and Cal Ripken in much the same fashion as you did for Lab 4. Then, set up each user’s voicemail box and leave some test messages. Also, try forward messages to users in New York, and vice versa.

Lab 5.3 – Unity Connection & Baltimore CUCME Wrap-up

Since the Unity Connection Demo License only has two ports, we are somewhat constrained on integrating Los Angeles. I’ve played with some possible work-arounds, where users in Los Angeles were able to access Unity Connection. However, I was unable to get MWI to function properly. Therefore, the next couple of labs will involve removing the Baltimore CUCME Integration, adding Los Angeles, reconfiguring CUE in Baltimore, and then attempt to integrate CUE with Unity Connection.

Unity Connection-CUCME Lab 4 – Unity Connection & CUCME New York Integration

2009-07-28T11:14:00.009-04:00

With the basic CUCME setup completed in Lab 2 and an initial installation of Unity Connection in Lab 3, we will now provision basic voice mail connectivity for the CUCME users in New York.

Lab 4.1 – Unity Connection & New York CUCME Integration Tasks

1. Configure the New York CUCME router to interface with Unity Connection via a SIP Trunk.

2. Use extension 2999 as the voicemail pilot.

3. Create voicemail users and mailboxes for NYC users for testing purposes.

4. Use PIN 135246 for each user and ensure that it never expires.

5. Users should be forced to enroll the first time they access Unity Connection.

6. Ensure that users receive their proper greeting when they dial from their Cisco IP Phone.

Lab 4.2 – Unity Connection & New York CUCME Integration Verification
Seemingly simple, this lab presented me with a challenging troubleshooting curve ball.

1. To configure the SIP Trunk from the NYC CUCME Router to Unity Connection, refer to the Cisco Unified Communications Manager Express SIP Trunk Integration Guide for Cisco Unity Connection Release 7.x. I suggest reading this entire document prior to beginning this lab.

For the CUCME CLI configuration, follow the instructions provided in the section “Programming the Cisco Unified Communications Manager Express Phone System for Integrating with Cisco Unity Connection”. The truncated output is as follows:

newyork#sh run
!
voice service voip
no supplementary-service sip moved-temporarily
!
!
!
dial-peer voice 2001 voip
description ucnx01
max-conn 2
destination-pattern 2999
session protocol sipv2
session target ipv4:10.1.20.20
dtmf-relay rtp-nte
codec g711ulaw
no vad
!

2. The next step, although not articulated in the Cisco Unified Communications Manager Express SIP Trunk Integration Guide for Cisco Unity Connection Release 7.x document, is to provision the CUCME SIP phones for voicemail. The process is very similar to the CUCME-CUE Lab 9 – New York City Messaging lab. Below are the truncated commands.

!
voice register global
mwi stutter
mwi reg-e164
!
!
!
voice register dn 1
number 2001
call-forward b2bua busy 2999
call-forward b2bua mailbox 2999
call-forward b2bua noan 2999 timeout 20
name Ari Gold
label Ari Gold 2001
mwi
!
voice register dn 2
number 2002
call-forward b2bua busy 2999
call-forward b2bua mailbox 2999
call-forward b2bua noan 2999 timeout 20
name David Wright
label David Wright 2002
mwi
!
voice register dn 3
number 2003
call-forward b2bua busy 2999
call-forward b2bua mailbox 2999
call-forward b2bua noan 2999 timeout 20
name Eli Manning
label Eli Manning 2003
mwi
!

3. I then return to the Cisco Unified Communications Manager Express SIP Trunk Integration Guide for Cisco Unity Connection Release 7.x document, following the step to configure Unity Connection as discussed in Creating a New Integration with Cisco Unified Communications Manager Express. The integration on Unity Connection is fairly straight forward, so I will not rehash the steps, which are pretty clear in the document and links referenced above.

4. Finally, I add the voicemail user profiles for Arliss Michaels, David Wright, and Eli Manning as described in the Testing the Integration section of the Cisco Unified Communications Manager Express SIP Trunk Integration Guide for Cisco Unity Connection Release 7.x guide. Here I will point out a few modifications. First, for the ease of lab management, I disable the complex password requirements for users under System Settings > Authentication Rules > Recommended Voice Mail Authentication Rule by un-checking the “Check for Trivial Passwords” box.

For each user I modify their Password Settings by checking the “Does Not Expire” box and supplying a default password of 123456.

5. At this point, I am ready to set up each user’s voicemail TUI. On each phone, I press the voicemail key and walk through the Setup Wizard. I then proceed to leave a view voicemails, but quickly notice that MWI is not functioning. I first reviewed the MWI parameters on Unity Connection in regards to the Cisco Unified Communications Manager Express SIP Trunk Integration Guide for Cisco Unity Connection Release 7.x guide, and everything seems to match. Next, I review my previous CUCME-CUE integration from the CUCME-CUE Lab 9 – New York City Messaging lab and notice that I’ve missed the following commands:

sip-ua
mwi-server ipv4:10.1.20.20 expires 3600 port 5060 transport udp

However, within a few minutes of adding these commands I noticed that my SIP phones were spontaneous rebooting. When logging into the router CLI, I also notice horrific response time. My next step was to refer to the Cisco Unity Connection Integration of the Cisco Unified Communications Manager Express System Administrator Guide. Unfortunately, this document was of little value, since it points to a much older Unity Connection 1.1 integration document.

Next, I run the “sh processes cpu sorted” command and notice the two SIP process have consumed the majority of the CPU cycles.

newyork#sh processes cpu sorted
CPU utilization for five seconds: 98%/6%; one minute: 20%; five minutes: 8%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
327 49040 12373 3963 60.20% 10.58% 2.63% 0 CCSIP_SPI_CONTRO
329 22812 10307 2213 21.92% 3.86% 0.98% 0 CCSIP_UDP_SOCKET

Here’s where some dumb luck saved the day…

I add the “unsolicited” keyword to the mwi-server command above, and vola, issue solved.

sip-ua
mwi-server ipv4:10.1.20.20 expires 3600 port 5060 transport udp unsolicited

We can see almost immediately that the SIP process begins to return to normal. An explanation of the unsolicited option is available here.

newyork#sh processes cpu sorted
CPU utilization for five seconds: 12%/0%; one minute: 41%; five minutes: 19%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
327 73376 15862 4625 4.55% 20.75% 8.98% 0 CCSIP_SPI_CONTRO
329 37644 13965 2695 2.15% 11.87% 4.61% 0 CCSIP_UDP_SOCKET

Lab 4 Unity Connection & New York CUCME Integration Wrap-up

One final note. During my staging and configuration, I could not help but notice that my VM image of Unity Connection was running extremely slow. The Performance tab VMWare Infrastructure Client was informing me that the memory utilization was running constantly near 100%. As a result, I have adjusted the amount of memory allocated from the original 1024MB, as described in Unity Connection-CUCME Lab 3 – Unity Connection Installation on VMware ESX 3.5, to 2048MB.

Unity Connection-CUCME Lab 3 – Unity Connection Installation on VMware ESX 3.5

2009-06-10T12:46:00.011-04:00

This lab discusses the procedures that I followed to install Unity Connection on a VMware ESX 3.5 Server. A special thanks to Ket Hum, a Federal Channels UC SE with Cisco, for giving me some tidbits.

1. My VMware ESX 3.5 server is installed on a DL320-G5 with two 750GB drives and 8GB of memory. My first step was to create separate vSwitch for the 10.1.20.0/24 New York Management VLAN.

2. Next step is to launch the “Create a new virtual machine” wizard.

As I walk through the New Virtual Machine Wizard, I select the following:

- Virtual Machine Configuration: Typical
- Guest Operating System: Linux > Red Hat Enterprise Linux 4 (32-bit)
- Memory: set to 1024MB
- Create Network Connection: One NIC on vSwitch1 (UC Network 10.1.20.0)
- Disk Size: 146GB (drive size of a MCS7835)

3. This next step is important… Prior to completing the wizard, check the “Edit the virtual machine settings before submitting” option. This allows us to statically assign the MAC address of the VM.

4. At this point, the wizard completes and the VM is created. You then can either boot the VM via an ISO image or DVD copy of Unity Connection. I opted to boot from an ISO copy of the image that I have on the storage of the ESX server; this is far quicker than booting and installing from the DVD.

5. At this point, you can proceed with the normal installation process. Installing Unity Connection is fairly easy; the Installation Guide for Cisco Unity Connection Release 7.x provides clear instructions regarding the tasks and process.

6. Once the installation process completes, login with your administrator username and password. Note, the console will tell you that VMware is not a supported platform.

7. The final step of the installation process is to very login via the web interface; in the case of this lab https://10.1.20.20/cuadmin. You can also few the demo license that comes with Unity Connection, which supports 10 mailboxes and 2 ports. Lastly, I used the snapshot feature in ESX. This will make things very easy to roll back to the clean image for later labs and study.

Unity Connection-CUCME Lab 3 Wrap-up
I’ve configured a simple Windows 2003 Domain Controller and Active Directory domain, adding users depicted in diagram from the Unity Connection-CUCME Scenario Background posting. With the installation of Unity Connection complete, we will begin the process of configuring the three Ballplayers, LLC CUCME locations to interface with Unity Connection.

Lab 2.2 – Unity Connection-CUCME Setup Verification

2009-06-04T16:12:00.006-04:00

The majority of the tasks in Unity Connection Lab 2.1 were covered in the CUCME-CUE labs. Rather than rehash previously covered topics, links are provided below, a discussion of any subtle differences or challenges, and finally the pertinent output from each ISR.

1. Installing and initializing the CUCME files is discussed in CUCME-CUE Lab 2 – Baltimore Basic CUCME System Setup for SCCP and CUCME-CUE Lab 3 – New York Basic CUCME System Setup for SIP. I did encounter a challenge, as previously discussed.

On the Baltimore SCCP router, the phone loads can be placed in a hierarchical file structure on the flash. Then, the alias keyword is used with the associated tftp-server commands.

baltimore#dir flash:/phone/7942-7962
Directory of flash:/phone/7942-7962/

185 -rw- 2918613 May 27 2009 21:59:06 -04:00 apps42.8-4-1-23.sbn
186 -rw- 485066 May 27 2009 21:59:10 -04:00 cnu42.8-4-1-23.sbn
187 -rw- 2659498 May 27 2009 21:59:24 -04:00 cvm42sccp.8-4-1-23.sbn
188 -rw- 335003 May 27 2009 21:59:26 -04:00 dsp42.8-4-1-23.sbn
189 -rw- 628112 May 27 2009 21:59:30 -04:00 jar42sccp.8-4-1-23.sbn
190 -rw- 658 May 27 2009 21:59:32 -04:00 SCCP42.8-4-2S.loads
191 -rw- 662 May 27 2009 21:59:32 -04:00 term42.default.loads
192 -rw- 662 May 27 2009 21:59:32 -04:00 term62.default.loads

260157440 bytes total (190967808 bytes free)

baltimore#
tftp-server flash:phone/7942-7962/apps42.8-4-1-23.sbn alias apps42.8-4-1-23.sbn
tftp-server flash:phone/7942-7962/cnu42.8-4-1-23.sbn alias cnu42.8-4-1-23.sbn
tftp-server flash:phone/7942-7962/cvm42sccp.8-4-1-23.sbn alias cvm42sccp.8-4-1-23.sbn
tftp-server flash:phone/7942-7962/dsp42.8-4-1-23.sbn alias dsp42.8-4-1-23.sbn
tftp-server flash:phone/7942-7962/jar42sccp.8-4-1-23.sbn alias jar42sccp.8-4-1-23.sbn
tftp-server flash:phone/7942-7962/SCCP42.8-4-2S.loads alias SCCP42.8-4-2S.loads
tftp-server flash:phone/7942-7962/term42.default.loads alias term42.default.loads
tftp-server flash:phone/7942-7962/term62.default.loads alias term62.default.loads

However, using the same procedure on the SIP locations, the phones fail to upgrade the phone loads. For Los Angeles and New York, the phone files are instead installed in the root location of the flash.

newyork#dir flash:
Directory of flash:/

1 -rw- 59224644 May 14 2009 22:41:26 -04:00 c2800nm-adventerprisek9_ivs-mz.124-22.YB1.bin
2 drw- 0 May 27 2009 22:39:18 -04:00 gui
21 drw- 0 May 27 2009 22:39:28 -04:00 ringtones
56 -rw- 2918613 May 27 2009 00:11:20 -04:00 apps42.8-4-1-23.sbn
57 -rw- 485066 May 27 2009 00:11:24 -04:00 cnu42.8-4-1-23.sbn
58 -rw- 3047459 May 27 2009 00:11:44 -04:00 cvm42sip.8-4-1-23.sbn
59 -rw- 335003 May 27 2009 00:11:46 -04:00 dsp42.8-4-1-23.sbn
60 -rw- 630128 May 27 2009 00:11:50 -04:00 jar42sip.8-4-1-23.sbn
61 -rw- 656 May 27 2009 00:11:50 -04:00 SIP42.8-4-2S.loads
62 -rw- 660 May 27 2009 00:11:52 -04:00 term42.default.loads
63 -rw- 660 May 27 2009 00:11:52 -04:00 term62.default.loads
64 -rw- 496521 May 27 2009 14:50:40 -04:00 music-on-hold.au

260943872 bytes total (192548864 bytes free)

newyork#
tftp-server flash:apps42.8-4-1-23.sbn
tftp-server flash:cnu42.8-4-1-23.sbn
tftp-server flash:cvm42sip.8-4-1-23.sbn
tftp-server flash:dsp42.8-4-1-23.sbn
tftp-server flash:jar42sip.8-4-1-23.sbn
tftp-server flash:SIP42.8-4-2S.loads
tftp-server flash:term42.default.loads
tftp-server flash:term62.default.loads

2. Refer to CUCME-CUE Lab 2 – Baltimore Basic CUCME System Setup to setting up the SCCP phones for Baltimore.

3. Refer to CUCME-CUE Lab 3 – New York Basic CUCME System Setup to setting up the SCCP phones for New York and Los Angeles.

4. For guidance on setting up the VOIP and POTS dial peers between all three locations, refer to CUCME-CUE Lab 4 – CUCME POTS & VoIP Dial Peers. However, since there is a potential for hairpin call routing, H.450.12 capabilities should be configured.

voice service voip
supplementary-service h450.12

5. CUCME-CUE Lab 7 – CUCME Conferencing & Transcoding will provide guidance on setting up the transcoding and conferencing.

6. Pertinent Baltimore CUCME configuration.

baltimore#sh run
!
card type t1 0 0
!
network-clock-participate wic 0
!
!
isdn switch-type primary-ni
!
!
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
supplementary-service h450.12
sip
registrar server expires max 600 min 300
!
!
voice class custom-cptone leavetone
dualtone conference
frequency 900 900
cadence 150 50 150 50
!
voice class custom-cptone jointone
dualtone conference
frequency 1200 1200
cadence 150 50 150 50
!
!
voice translation-rule 1
rule 1 /\(20..\)/ /212555\1/
rule 2 /\(30..\)/ /213555\1/
!
!
voice translation-profile prefix
translate called 1
!
!
voice-card 0
dsp services dspfarm
!
!
controller T1 0/0/0
cablelength short 110
pri-group timeslots 1-4,24
!
!
ip http server
ip http path flash:/gui
!
tftp-server flash:ringtones/Analog1.raw alias Analog1.raw
tftp-server flash:ringtones/AreYouThere.raw alias AreYouThere.raw
!output truncated!
!
voice-port 0/0/0:23
!
!
sccp local GigabitEthernet1/0.12
sccp ccm 10.1.12.1 identifier 1 priority 1 version 7.0
sccp
!
sccp ccm group 1
bind interface GigabitEthernet1/0.12
associate ccm 1 priority 1
associate profile 1 register conference
associate profile 2 register transcode
!
dspfarm profile 2 transcode
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729br8
codec g722-64
maximum sessions 3
associate application SCCP
!
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
codec g722-64
maximum sessions 1
conference-join custom-cptone jointone
conference-leave custom-cptone leavetone
associate application SCCP
!
!
dial-peer voice 2000 voip
description VOIP Peer to New York
preference 1
destination-pattern 20..
session protocol sipv2
session target ipv4:2.2.2.2
dtmf-relay rtp-nte
codec g722-64
no vad
!
dial-peer voice 3000 voip
description VOIP Peer to Los Angeles
preference 1
destination-pattern 30..
session protocol sipv2
session target ipv4:3.3.3.3
dtmf-relay rtp-nte
codec g722-64
no vad
!
dial-peer voice 1 pots
description inbound PRI dial-peer
incoming called-number .
direct-inward-dial
port 0/0/0:23
!
dial-peer voice 2 pots
description outbound via pri
preference 1
destination-pattern 9[2-9].........
port 0/0/0:23
!
dial-peer voice 3 pots
translation-profile outgoing prefix
preference 2
destination-pattern [23]0..
port 0/0/0:23
forward-digits all
!
!
telephony-service
sdspfarm units 5
sdspfarm transcode sessions 3
sdspfarm tag 1 conference
sdspfarm tag 2 transcode
em logout 0:0 0:0 0:0
codec g722-64
max-ephones 42
max-dn 144
ip source-address 10.1.12.1 port 2000
service phone g722CodecSupport 2
service phone handsetWidebandEnable 1
service phone headsetWidebandEnable 0
service phone handsetWidebandUIControl 0
system message Ballplayers, LLC Baltimore
cnf-file location flash:
load 7942 SCCP42.8-4-2S
load 7962 SCCP42.8-4-2S
time-zone 12
dialplan-pattern 1 41055510.. extension-length 4
dialplan-pattern 2 21255520.. extension-length 4
dialplan-pattern 3 21355530.. extension-length 4
max-conferences 8 gain -6
moh music-on-hold.au
multicast moh 239.23.4.10 port 2000
web admin system name Cisco123 password Cisco123
transfer-system full-consult
transfer-pattern 10..
transfer-pattern 20..
transfer-pattern 30..
secondary-dialtone 9
directory entry 1 2001 name Ari Gold
directory entry 2 2002 name David Wright
directory entry 3 2003 name Eli Manning
directory entry 4 3001 name Jerry Maquire
directory entry 5 3002 name Kobe Bryant
create cnf-files version-stamp 7960 May 28 2009 12:02:02
!
!
ephone-template 1
conference drop-mode local
conference admin
softkeys seized Endcall Redial Cfwdall Meetme Pickup Callback
softkeys connected Hold Endcall Park Confrn Trnsfer Select Join ConfList RmLstC Flash
!
!
ephone-dn 1 dual-line
number 1001
label Arliss Michaels 1001
description 410-555-1001
name Arliss Michaels
!
!
ephone-dn 2 dual-line
number 1002
label Cal Ripken 1002
description 410-555-1002
name Cal Ripken
!
!
ephone-dn 3 octo-line
number 1020
name Baltimore AdHoc
conference ad-hoc
!
!
ephone-dn 4 octo-line
number 1021
name Baltimore MeetMe
conference meetme
!
!
ephone 1
device-security-mode none
description Arliss Michaels
mac-address 0024.97AB.1F83
ephone-template 1
username "amichaels" password null
codec g722-64
type 7962
button 1:1
!
!
ephone 2
device-security-mode none
description Cal Ripken
mac-address 0023.331A.EDCC
ephone-template 1
username "cripken" password null
codec g722-64
type 7962
button 1:2
!

7. Pertinent New York CUCME configuration. Los Angeles is nearly identical, except of course for different IP addresses and such.

newyork#sh run
!
card type t1 0 0
!
network-clock-participate wic 0
!
isdn switch-type primary-ni
!
!
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
supplementary-service h450.12
sip
registrar server expires max 600 min 300
!

!
voice class custom-cptone leavetone
dualtone conference
frequency 900 900
cadence 150 50 150 50
!
voice class custom-cptone jointone
dualtone conference
frequency 1200 1200
cadence 150 50 150 50
!
!
voice register global
mode cme
source-address 10.1.22.1 port 5060
no privacy
max-dn 144
max-pool 42
load 7962 SIP42.8-4-2S
load 7942 SIP42.8-4-2S
timezone 12
hold-alert
dialplan-pattern 1 41055510.. extension-length 4
dialplan-pattern 2 21255520.. extension-length 4
dialplan-pattern 3 21355530.. extension-length 4
call-forward system redirecting-expanded
url directory http://10.1.22.1:80/localdirectory
file text
create profile sync 0006512451546702
ntp-server 10.1.1.4 mode directedbroadcast
!
voice register dn 1
number 2001
name Ari Gold
label Ari Gold 2001
!
voice register dn 2
number 2002
name David Wright
label David Wright 2002
!
voice register dn 3
number 2003
name Eli Manning
label Eli Manning 2003
!
voice register template 1
softkeys hold Newcall Resume
softkeys idle Redial Newcall Cfwdall Pickup DND
softkeys seized Endcall Redial Cfwdall Pickup
softkeys connected Hold Endcall Park Confrn Trnsfer
softkeys remote-in-use Barge cBarge Newcall
!
voice register pool 1
id mac 0024.97AB.1FB5
type 7962
number 1 dn 1
template 1
dtmf-relay rtp-nte
description 212-555-2001
codec g722-64
no vad
!
voice register pool 2
id mac 0021.D8B9.BC72
type 7962
number 1 dn 2
template 1
dtmf-relay rtp-nte
description 212-555-2002
codec g722-64
no vad
!
voice register pool 3
id mac 0021.D8BA.2373
type 7942
number 1 dn 3
dtmf-relay rtp-nte
description 212-555-2003
codec g722-64
no vad
!
!
voice translation-rule 1
rule 1 /\(10..\)/ /410555\1/
rule 2 /\(30..\)/ /213555\1/
!
!
voice translation-profile prefix
translate called 1
!
!
voice-card 0
dsp services dspfarm
!
!
controller T1 0/0/0
cablelength short 110
pri-group timeslots 1-4,24
!
!
ip http server
ip http path flash:/gui
!
!
tftp-server flash:ringtones/Analog1.raw alias Analog1.raw
tftp-server flash:ringtones/AreYouThere.raw alias AreYouThere.raw
!output truncated!
!
voice-port 0/0/0:23
!
!
sccp local FastEthernet0/0.22
sccp ccm 10.1.22.1 identifier 1 priority 1 version 7.0
sccp
!
sccp ccm group 1
bind interface FastEthernet0/0.22
associate ccm 1 priority 1
associate profile 1 register conference
associate profile 2 register transcode
!
dspfarm profile 2 transcode
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729br8
codec g729r8
codec g722-64
maximum sessions 3
associate application SCCP
!
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
codec g722-64
maximum sessions 1
conference-join custom-cptone jointone
conference-leave custom-cptone leavetone
associate application SCCP
!
!
dial-peer voice 1000 voip
description VOIP Peer to Baltimore
preference 1
destination-pattern 10..
session protocol sipv2
session target ipv4:1.1.1.1
dtmf-relay rtp-nte
codec g722-64
no vad
!
dial-peer voice 3000 voip
description VOIP Peer to Los Angeles
preference 1
destination-pattern 30..
session protocol sipv2
session target ipv4:2.2.2.2
dtmf-relay rtp-nte
codec g722-64
no vad
!
dial-peer voice 1 pots
description inbound PRI dial-peer
incoming called-number .
direct-inward-dial
port 0/0/0:23
!
dial-peer voice 2 pots
description outbound via pri
preference 1
destination-pattern 9[2-9].........
port 0/0/0:23
!
dial-peer voice 3 pots
translation-profile outgoing prefix
preference 2
destination-pattern [13]0..
port 0/0/0:23
forward-digits all
!
!

telephony-service
sdspfarm units 5
sdspfarm transcode sessions 3
sdspfarm tag 1 conference
sdspfarm tag 2 transcode
em logout 0:0 0:0 0:0
max-ephones 42
max-dn 144
ip source-address 10.1.22.1 port 2000
service phone g722CodecSupport 2
service phone handsetWidebandEnable 1
service phone headsetWidebandEnable 0
service phone handsetWidebandUIControl 0
time-zone 12
date-format dd-mm-yy
dialplan-pattern 1 41055510.. extension-length 4
dialplan-pattern 2 21255520.. extension-length 4
dialplan-pattern 3 21255530.. extension-length 4
max-conferences 8 gain -6
moh music-on-hold.au
multicast moh 239.23.4.10 port 2000
web admin system name Cisco123 password Cisco123
transfer-system full-consult
transfer-pattern 10..
transfer-pattern 20..
transfer-pattern 30..
secondary-dialtone 9
directory entry 1 1001 name Arliss Michaels
directory entry 2 1002 name Cal Ripken
directory entry 3 3001 name Jerry Maquire
directory entry 4 3002 name Kobe Bryant
create cnf-files version-stamp 7960 May 28 2009 12:01:41
!
!
ephone-dn 1 octo-line
number 2020
name NY AdHoc
conference ad-hoc
!

Unity Connection-CUCME Lab 2 Wrap-up

Now that the three Ballplayers, LLC locations up with CUCME, the next labs will actually look at Unity Connection. The first lab will discuss the installation and initial configuration on a VMware ESX 3.5 server.

Unity Connection-CUCME Lab 2 – CUCME Setup

2009-05-29T15:34:00.004-04:00

Lab 2 will focus on setting up CUCME for Unity Connection. Since CUCME was covered in depth in the CUCME-CUE Labs, and the focus of these labs is Unity Connection, I will keep the CUCME side basic. Advanced CUCME calling feature will be kept to a minimum.

Unity Connection-CUCME System Setup Prerequisites

Prior to configuring the CUCME phone tasks, the router requires the specific CUCME files to be installed on the router flash. These labs will be based on CME 7.1 and IOS 12.4(22)YB1.

If this task hasn’t been previously completed, now is the time to so. There are a couple of ways to accomplish this prerequisite. The processes and procedures for installing the CUCME files on the router flash are described in the Installing and Upgrading Cisco Unified CME Software chapter of the Cisco Unified Communications Manager Express System Administrator Guide. A further discussion is covered in CUCME-CUE Lab 2 – Baltimore Basic CUCME System Setup and CUCME-CUE Lab 3 – New York Basic CUCME System Setup.

Lab 2.1 – Unity Connection-CUCME Setup Tasks

1. Configure CUCME on the Baltimore, Los Angeles, and New York routers based on the information provided in Unity Connection-CUCME Scenario Background. You may not use the CUCME setup utility or any sort of auto registration process.

2. Baltimore phones should be SCCP; Los Angeles and New York phones should be SIP Phones.

3. Each phone and should also be able to customize their ringtones beyond the default chirp ringtone.

4. Each user’s phone should also display his/her name and full E.164 number.

5. Each CUCME router should be configure to support the appropriate localization, time-zone, a 12 hour time format, and a Month-Day-Year format.

6. Enable the wideband codec by default for all phones.

7. Create an appropriate E.164 dial-pattern.

8. Configure VOIP between all three locations. Ensure that the default VOIP codec is the wideband codec.

9. Transfer between all locations should be supported.

10. Configure the PRI at each location to support only 4 channels (to conserve DSP resources).

11. In the event of a WAN failure, calls should use the PSTN, but without users having to dial more than four digits. Use only a single dial-peer with a single translation rule to accomplish this task. You may not use a prefix.

12. Enable transcoding to support G.711, G.722, and G.729.

13. Enable Conferencing and Transcoding resources for all three locations.

14. Provide an audible alert when someone joins or leaves a conference. The alerts should be different for joining and leaving.

15. Baltimore should support eight attendees at the conference bridge. Baltimore should support both Ad-hoc and Meet-Me conferencing.

16. Enable Music on Hold for both internal and external callers.

17. Create the appropriate GUI Administrator parameters.

Unity Connection-CUCME Lab 1 – Initial Configuration

2009-05-22T14:04:00.005-04:00

Unity Connection-CUCME Lab 1 Prerequisites

Prior to beginning the basic IP Setup for this series of Unity Connection-CUCME Labs, configure the Adtran Atlas 550 to support the simulated PSTN dial plan depicted in diagram in Unity Connection / CUCME Labs – Background. Please refer to VOIP Fundamentals Lab 1 - PSTN Setup on how to configure the Adtran for the dial plan depicted in CUCME-CUE Scenario Background.

The Unity Connection-CUCME labs also assume that you have the appropriate IOS files, CUCME files, and CUE files. These labs also assume that you have valid CCO access and licenses for any files that you may be downloading and installing on your lab equipment.

These labs will be based on CME 7.1 and IOS 12.4(22)YB1. If you need to upgrade the IOS refer to the Cisco Unified CME and Cisco IOS Software Version Compatibility Matrix. For now, my recommendation is not to install the CME files. I will cover that in a subsequent lab.

Lab 1.1 Unity Connection-CUCME– Initial IP Network Setup Tasks

1. Configure the IP addressing based on the diagram in Scenario Background.
2. Configure R7 to serve as the frame relay switch for WAN. Set the clocking to 512000.
3. Make sure you have an “external” NTP clocking source for your LAB. (Note, depending on your own lab, this may vary. I will discuss my configuration below.)
4. Configure the Frame Relay connections as a point-to-point interfaces.
5. Provide a loopback interface on each router.
6. Configure your LAN networks as depicted the Scenario Background posting.
7. On the Baltimore Router, the connection between the router and Ethernet Switch Module must be over a Layer 2 trunk.
8. Configure IP Services on each router to support IP Phones. Reserve the first 16 IP addresses accordingly.
9. Configure the LAN ports so that Phones receive their appropriate IP information and any PCs on those LAN ports receive their appropriate IP information.
10. Configure OSPF routing for the network. The WAN/Frame Cloud should use Area 0; Baltimore Area 1; New York Area 2; Los Angeles as Area 3.
11. The loopbacks should be placed into each area accordingly; these routes should be depicted in the route tables as /24 networks.
12. Configure the 10.1.1.0 network on each router as internet path. The subnet should not be routed via OSPF.
13. Verify that IP Phones at each location receive IP Addresses.
14. Test connectivity. Ping the DNS server from each subnet and each device. Ping phones from multiple locations to multiple locations. Etc.

Lab 1.2 Unity Connection-CUCME Verification

Although not exactly identical to the CUCME-CUE Lab 1 Setup, much of the configuration set up is very similar. Therefore, for the sake of brevity I will provide the configs below and highlight some differences.

1. Below is a snippet of router config on R7, which shows the configuration of the router as a Frame Relay switch. The router also synchronizes with an Internet NTP server.

ISP Router:
!
hostname ISP
!
ip host r1 2066 10.1.1.4
ip host r2 2067 10.1.1.4
ip host r3 2068 10.1.1.4
ip host r4 2069 10.1.1.4
ip host r5 2070 10.1.1.4
ip host r6 2071 10.1.1.4
ip host s1 2072 10.1.1.4
!
frame-relay switching
!
!
interface FastEthernet0/0
ip address 10.1.1.4 255.255.255.0
duplex auto
speed auto
ntp broadcast
!
!
interface Serial0/0/0
description frame-relay link to Baltimore
no ip address
encapsulation frame-relay
no fair-queue
clock rate 512000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 102 interface Serial0/0/1 201
!
interface Serial0/0/1
description frame-relay to New York
no ip address
encapsulation frame-relay
clock rate 512000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 201 interface Serial0/0/0 102
frame-relay route 203 interface Serial0/1/0 302
!
interface Serial0/1/0
description frame-relay link to Los Angeles
no ip address
encapsulation frame-relay
clock rate 512000
frame-relay lmi-type cisco
frame-relay intf-type dce
frame-relay route 302 interface Serial0/0/1 203
!
line 1/0 1/15
no exec
transport input all
!
ntp source FastEthernet0/0
ntp update-calendar
ntp server 198.82.1.201

2. The pertinent configuration parameters for the Baltimore CUCME router setup is below. Note, the Baltimore router has a EtherSwitch Service Module (NME-16ES-1G-P).

Baltimore CUCME Router:

baltimore#sh run
!
ip dhcp excluded-address 10.1.11.1 10.1.11.15
ip dhcp excluded-address 10.1.12.1 10.1.12.15
!
ip dhcp pool VOICE
network 10.1.12.0 255.255.255.0
update dns
default-router 10.1.12.1
option 150 ip 10.1.12.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
ip dhcp pool DATA
network 10.1.11.0 255.255.255.0
update dns
default-router 10.1.11.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip ospf network point-to-point
!
interface FastEthernet0/0
ip address 10.1.1.101 255.255.255.0
duplex auto
speed auto
!
!
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.102 point-to-point
ip address 172.16.1.1 255.255.255.252
ip ospf network point-to-point
snmp trap link-status
frame-relay interface-dlci 102
!
!
interface GigabitEthernet1/0
no ip address
!
interface GigabitEthernet1/0.10
description Baltimore Management
encapsulation dot1Q 10 native
ip address 10.1.10.1 255.255.255.0
!
interface GigabitEthernet1/0.11
description Baltimore Data
encapsulation dot1Q 11
ip address 10.1.11.1 255.255.255.0
!
interface GigabitEthernet1/0.12
description Baltimore Voice
encapsulation dot1Q 12
ip address 10.1.12.1 255.255.255.0
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.0 0.0.0.255 area 1
network 10.1.10.0 0.0.0.255 area 1
network 10.1.11.0 0.0.0.255 area 1
network 10.1.12.0 0.0.0.255 area 1
network 172.16.1.0 0.0.0.3 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
ntp source FastEthernet0/0
ntp update-calendar
ntp server 10.1.1.4
end

3. Configuring the EtherSwitch Service Module (NME-16ES-1G-P) via a Layer 2 trunk was described in CUCME-CUE Lab 1 – Initial Configuration. Below is the configuration.

Baltimore EtherSwitch Service Module:

baltimore-sw#sh run
!
!
vlan 10
name Baltimore-Management
!
vlan 11
name Baltimore-Data
!
vlan 12
name Baltimore-Voice
!
!
!
interface FastEthernet1/0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 11
switchport voice vlan 12
spanning-tree portfast
!
!omitted!
!
!
interface GigabitEthernet1/0/2
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 10-12
switchport mode trunk
spanning-tree portfast trunk
!
interface Vlan10
description Baltimore-Management
ip address 10.1.10.2 255.255.255.0
!
interface Vlan11
description Baltimore Data
ip address 10.1.11.2 255.255.255.0
!
interface Vlan12
description Baltimore Vlan
ip address 10.1.12.2 255.255.255.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.10.1
!
ntp source Vlan10
ntp server 10.1.1.4

4. The configuration for the New York City CUCME router, which is the “hub” site for Ballplayers, LLC, is as follows.

New York CUCME Router:

newyork#sh run
!
p dhcp excluded-address 10.1.21.1 10.1.21.15
ip dhcp excluded-address 10.1.22.1 10.1.22.15
!
ip dhcp pool VOICE
network 10.1.22.0 255.255.255.0
update dns
default-router 10.1.22.1
option 150 ip 10.1.22.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
ip dhcp pool DATA
network 10.1.21.0 255.255.255.0
update dns
default-router 10.1.21.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
ip ospf network point-to-point
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 1
ip address 10.1.1.102 255.255.255.0
!
interface FastEthernet0/0.20
encapsulation dot1Q 20 native
ip address 10.1.20.1 255.255.255.0
!
interface FastEthernet0/0.21
encapsulation dot1Q 21
ip address 10.1.21.1 255.255.255.0
!
interface FastEthernet0/0.22
encapsulation dot1Q 22
ip address 10.1.22.1 255.255.255.0
!
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.201 point-to-point
ip address 172.16.1.2 255.255.255.252
ip ospf network point-to-point
snmp trap link-status
frame-relay interface-dlci 201
!
interface Serial0/2/0.203 point-to-point
ip address 172.16.1.6 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 203
!
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 2
network 10.1.1.0 0.0.0.0 area 0
network 10.1.20.0 0.0.0.255 area 2
network 10.1.21.0 0.0.0.255 area 2
network 10.1.22.0 0.0.0.255 area 2
network 172.16.1.0 0.0.0.255 area 0
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
ntp source FastEthernet0/0.1
ntp update-calendar
ntp server 10.1.1.4

5. Configuration for Los Angeles shares similarities with both Baltimore and New York. At the moment, I am using the same 3750 switch to service both New York and Los Angeles. The LA router does have a four-port fast Ethernet HWIC. However, I do not have the upgrade power supply to provide POE on these ports. Once I obtain the new power supply, I will modify LA to support it phone locally.

Los Angeles CUCME Router:

losangeles#sh run
ip dhcp excluded-address 10.1.31.1 10.1.31.15
ip dhcp excluded-address 10.1.32.1 10.1.32.15
!
ip dhcp pool VOICE
network 10.1.32.0 255.255.255.0
update dns
default-router 10.1.32.1
option 150 ip 10.1.32.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
ip dhcp pool DATA
network 10.1.31.0 255.255.255.0
update dns
default-router 10.1.31.1
dns-server 10.1.20.10 4.2.2.1
domain-name corp.ballplayersllc.com
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
ip ospf network point-to-point
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 1
ip address 10.1.1.103 255.255.255.0
!
interface FastEthernet0/0.30
description LosAngeles Management
encapsulation dot1Q 30 native
ip address 10.1.30.1 255.255.255.0
!
interface FastEthernet0/0.31
description LosAngeles Data
encapsulation dot1Q 31
ip address 10.1.31.1 255.255.255.0
!
interface FastEthernet0/0.32
description LosAngeles Voice
encapsulation dot1Q 32
ip address 10.1.32.1 255.255.255.0
!
!
interface FastEthernet0/3/0
!
interface FastEthernet0/3/1
!
interface FastEthernet0/3/2
!
interface FastEthernet0/3/3
!
interface Serial0/2/0
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/2/0.302 point-to-point
ip address 172.16.1.5 255.255.255.252
ip ospf network point-to-point
snmp trap link-status
frame-relay interface-dlci 302
!
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.0 0.0.0.255 area 3
network 10.1.30.0 0.0.0.255 area 3
network 10.1.31.0 0.0.0.255 area 3
network 10.1.32.0 0.0.0.255 area 3
network 172.16.1.4 0.0.0.3 area 0
!
ip forward-protocol nd
!
ntp source FastEthernet0/0.1
ntp update-calendar
ntp server 10.1.1.4

6. As discussed above, I am sharing one 3750 switch for the LAN side of both New York and Los Angeles. The switch also provides internet access for my lab. As such, I have to configure the 3750 carefully so that I avoid using it to route traffic and bypassing the “WAN”.

First, I configure the appropriate VLANs and VLAN interfaces to support NY and LA.

!
interface Vlan1
ip address 10.1.1.3 255.255.255.0
!
interface Vlan20
ip address 10.1.20.2 255.255.255.0
!
interface Vlan21
ip address 10.1.21.2 255.255.255.0
!
interface Vlan22
ip address 10.1.22.2 255.255.255.0
!
interface Vlan30
ip address 10.1.30.2 255.255.255.0
!
interface Vlan31
ip address 10.1.31.2 255.255.255.0
!
interface Vlan32
ip address 10.1.32.2 255.255.255.0

Secondly, I configure the interfaces to support each router. Note the differences between the configuration to support Baltimore as compared to NY and LA.

!
interface FastEthernet1/0/1
description R1 FA0/0 (baltimore)
spanning-tree portfast
!
interface FastEthernet1/0/2
description R2 FA0/0 (newyork)
switchport trunk encapsulation dot1q
switchport trunk native vlan 20
switchport trunk allowed vlan 1,20-22
switchport mode trunk
spanning-tree portfast trunk
!
interface FastEthernet1/0/3
description R3 FA0/0 (losangeles)
switchport trunk encapsulation dot1q
switchport trunk native vlan 30
switchport trunk allowed vlan 1,30-32
switchport mode trunk
spanning-tree portfast trunk
!

The next step is to configure static routes that basically tells any IP traffic from hosts connected to the switch to use NY as the next hop. From NY, the traffic will be routed dynamically via OSPF.

ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip route 1.1.1.0 255.255.255.0 10.1.20.1
ip route 2.2.2.0 255.255.255.0 10.1.20.1
ip route 3.3.3.0 255.255.255.0 10.1.20.1
ip route 10.1.0.0 255.255.0.0 10.1.20.1
ip route 172.16.1.0 255.255.255.0 10.1.20.1

The switch ports for NY and LA phones are configured appropriately. Again, compare the differences between a port that supports LA phones versus a port that supports NY phones.

!
interface FastEthernet1/0/9
description LA PHONE PORT
switchport trunk encapsulation dot1q
switchport trunk native vlan 31
switchport voice vlan 32
spanning-tree portfast
!
!
interface FastEthernet1/0/13
description NY PHONE PORT
switchport trunk encapsulation dot1q
switchport trunk native vlan 21
switchport voice vlan 22
spanning-tree portfast
!

7. Finally, ping tests across the Lab setup verify end-to-end connectivity. The first ping test below demonstrates the ability to ping from the Baltimore EtherSwitch module to my Windows 2003 AD/DNS server (10.1.20.10).

baltimore-sw#ping 10.1.20.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.20.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms

Another test from Los Angeles verifies the ability to ping a phone on Baltimore’s EtherSwitch module.

losangeles#ping 10.1.12.16

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.16, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/20 ms

And finally, a ping test from New York to a phone associated with LA verifies connectivity. Note the delay, which suggests that the path between the two is via the WAN link. If the delay was between 1ms and 4ms, this would have suggested the path remained within the switch.

newyork#ping 10.1.32.20

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.32.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Unity Connection-CUCME Lab 1 Wrap Up

Not much in this lab relating to Unity or CUCME for that matter. The next lab will build out our CUCME configuration in anticipation of moving towards Unity Connection integration.

Unity Connection-CUCME Scenario Background

2009-05-22T13:50:00.007-04:00

Ballplayers, Inc. is a sports marketing firm with locations in New York City, NY and Baltimore, MD. The firm represents both current and retired athletes and their associated marketing ventures. After successfully pilot Cisco Unified Communications Manager Express and Cisco Unity Express between New York and Baltimore, the firm’s CIO Fuzzy Dunlop has given you the go ahead to expand the pilot. This new phase will add Los Angeles as third CUCME location. Finally, CUE will be replace with a centralized Cisco Unity Connection integrated messaging solution.

Below is a high-level design of the Cisco Unity Connection Pilot.

The table below describes the IP Adressing & PSTN configuration.

The first Lab will walk through the requirements to configure the routing between Baltimore, New York, and Los Angeles.

Unity Connection Labs Coming!

2009-05-05T23:11:00.007-04:00

It has been a while since my previous posts. I am in the planning stages of some Unity Connection 7.0 labs. While they are still very much on the drawing board, the basic concept will be to take three CUCME locations and provide a centralized Unity Connection solution.

For some future planning purposes, I am changing some of the dial plan and IP addressing. As a result, while the previous CUCME-CUE labs will be helpful for reference, these labs will deviate a bit from the structure in those previous labs.

I am probably a week or two out before I start posting. I need to finish building my LDAP/AD directory and test out installing Unity Connection in VMWare ESX. Below is a teaser of the topology that I am developing.

CUCME-CUE Lab 10 – CUCME-CUE Misc Items

2009-03-24T22:22:00.005-04:00

In this final CUCME-CUE Lab, Fuzzy Dunlop has asked you to fine tune the Baltimore and New York Unified Communications Express Solution.

CUCME-CUE Lab 10.1 –CUCME-CUE Misc Items Tasks

1. Nick Markakis has a new 7962 IP Phone. With all these line appearances, Nick has requested the ability to monitor the presence of Arliss Michaels, Cal Ripken, and Joe Flacco. Configure Baltimore to support this Presence mandate.

2. All users in both Baltimore and New York should be able to monitor phone presence status via the local directory. Users should also be able to remotely monitor presence status.

3. Eli Manning would like the ability to intercom Ari. However, he does not want Ari to intercom him.

4. Configure ext. 1000 as the Auto Attendant, using the system default AA. When a user requests the Operator via the AA, both Ari and Arliss should receive the call.

5. When an internal user dials “0”, calls should ring simultaneous at Ari and Arliss.

6. Ensure that when external caller dial each branch office’s main number, 410-555-1000 for Baltimore, and 212-555-2000, that the numbers are routed to the AA.

7. Ensure that both Arlis and Ari have administrative privileges on CUE and can modify the system via the TUI using extension 1990.

8. Fuzzy Dunlop has asked that you block any 900, 976, or 1010 calls.

CUCME-CUE Lab 10.2 –CUCME-CUE Misc Items Verification

1. Configuring Presence for SCCP phones in Baltimore is very similar to the process discussed for the SIP phones discussed in Lab 6. First, enable the appropriate presence parameter globally. Next, configure Nick Markakis to monitor Arliss Michaels, Cal Ripken, and Joe Flacco.

!
sip-ua
presence enable
!
presence
max-subscription 144
!
ephone-dn 1 dual-line
number 1001
label Cal Ripken 1001
allow watch
!
!repeat for ephone-dn 2-5!
!
ephone 2
device-security-mode none
description Nick Markakis
blf-speed-dial 2 1001 label "Cal Ripken" device
blf-speed-dial 3 1003 label "Joe Flacco" device
blf-speed-dial 4 1005 label "Arliss Michaels" device
blf-speed-dial 5 2005 label "Ari Gold" device

2. In order to allow all users to view presence status via the local directory, additional modifications are required on both the New York and Baltimore routers. First, there are some additional configuration parameters required under the global “presence” command. Secondly, the “presence call-list” command needs to be added to both the SCCP and SIP phone configuration.

Baltimore#sh run
!
presence
sccp blf-speed-dial retry-interval 90 limit 15
presence call-list
server 10.1.22.1
max-subscription 144
watcher all
allow subscribe
!
ephone 1
description Cal Ripken
presence call-list
!
! repeat for all SCCP phones !

NewYork#sh run
!
presence
sccp blf-speed-dial retry-interval 90 limit 15
presence call-list
server 10.1.12.1
max-subscription 144
watcher all
allow subscribe
!
!
voice register pool 1
presence call-list
description 212-555-2001
!
! repeat for all SIP Phones !

A comment/observation… It appears that only one SIP Presence Server can be added to the CUCME configuration. This effectively limits SIP Presence monitoring between only two CUCME location, unless of course a centralized Presence Server, such as CUPS, is integrated as part of the solution.

3. In an attempt to revisit SIP intercom, I believe that I may have come up with “hybrid” solution. The first part of the solution is to create a voice register dn that auto-answers.

!
voice register dn 6
number 2905
auto-answer
label Intercom from Eli
!

Next, this dn is associated with the Ari Gold SIP Phone.

!
voice register pool 5
number 1 dn 5
number 2 dn 1
number 3 dn 6
!

Finally, a speed dial button for Eli’s phone is created, which in essence creates the “intercom”.

!
voice register pool 3
number 1 dn 3
description 212-555-2003
speed-dial 1 2905 label "Intercom to Ari"
!

4. Meeting the requirements for the Auto Attendant described in tasks 4 – 6 require a number of configuration changes on both the Baltimore and New York CUCME routers and the CUE.

Under CUE, a group delivery mailbox needs to be created, as well mapping which number will ring the operator when a user presses “0” in the auto attendant. For purposes of the configuration, “0” for the operator will be mapped to extension 1100, which will later be associated with a hunt group in CUCME. As for the AA itself and purposes of this exercise, I’ve opted for the default AA in CUE.

baltimore-cue# sh run

groupname Operator create

groupname Operator member amichaels
groupname Operator member agold
groupname Operator phonenumber "1100"

ccn application autoattendant aa
description "autoattendant"
enabled
maxsessions 4
script "aa.aef"
parameter "busClosedPrompt" "AABusinessClosed.wav"
parameter "holidayPrompt" "AAHolidayPrompt.wav"
parameter "welcomePrompt" "AAWelcome.wav"
parameter "disconnectAfterMenu" "false"
parameter "dialByFirstName" "false"
parameter "allowExternalTransfers" "false"
parameter "MaxRetry" "3"
parameter "dialByExtnAnytime" "false"
parameter "busOpenPrompt" "AABusinessOpen.wav"
parameter "businessSchedule" "systemschedule"
parameter "dialByExtnAnytimeInputLength" "4"
parameter "operExtn" "1100"
end application

voicemail mailbox owner "Operator" size 720
description "Operator Mailbox"
zerooutnumber "1000"
end mailbox

Next, in Baltimore, create a parallel hunt group to ring both Ari and Arliss at the same time. Voice hunt-groups allow you to include SIP trunks, something that ephone-hunt groups do not allow. Note, the timeout needs to be tweaked so that the call is sent to the group mail box 1100 prior to being sent to either the Ari or Arliss mailbox.

Baltimore#sh run
!
voice hunt-group 2 parallel
final 1999
list 1005,2005
timeout 20
pilot 1100
!

Next, two additional voip dial-peers are added to Baltimore to allow access to the AA. Note, for external users, a translation profile must be associated with the inbound E.164 number from the PSTN. A modification to the existing voice translation rule is sufficient.

Baltimore#sh run
!
voice translation-rule 2
rule 1 /4105551999/ /1999/
rule 2 /4105551000/ /1000/
!
!
voice translation-profile to-cue
translate called 2
!
!
dial-peer voice 1997 voip
destination-pattern 1000
session protocol sipv2
session target ipv4:10.1.12.3
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 1996 voip
mailbox-selection orig-called-num
description VM-AA-PSTN
translation-profile outgoing to-cue
destination-pattern 4105551000
session protocol sipv2
session target ipv4:10.1.12.3
dtmf-relay rtp-nte
codec g711ulaw
no vad
!

For users in New York, the CUCME changes are similar. Two dial-peers are created, one with a destination-pattern of 1000 pointing to Baltimore and the other with a destination-pattern of 212-555-2000, with an associated translation-profile and also pointing to Baltimore.

NewYork#sh run
!
voice translation-rule 2
rule 1 /2125552000/ /1000/
!
!
voice translation-profile outgoing-to-cue
translate called 2
!
!
dial-peer voice 1997 voip
destination-pattern 1000
b2bua
session protocol sipv2
session target ipv4:10.1.12.3
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 1996 voip
mailbox-selection orig-called-num
description AA
translation-profile outgoing outgoing-to-cue
destination-pattern 2125552000
b2bua
session protocol sipv2
session target ipv4:10.1.12.3
dtmf-relay rtp-nte
codec g711ulaw
no vad
!

5. The process to enable users to dial “0” and have both Ari and Arliss ring is different for each router.

In Baltimore, we’ll modify the existing translation rule from lab 4, which enabled user who dial HELP to ring the analog security phone. In this instance, add a second rule to translate 0 to the 1100 pilot.

Baltimore#sh run
!
translation-rule 1
Rule 0 ^4357 1611
Rule 1 ^0 1100

In New York, since the phones are SIP, new voice translation rule and translation-profile are created. This translation profile is then applied to a new voip dial-peer pointing to Baltimore and the Baltimore hunt-group, which in-turn, rings both Ari and Arliss.

NewYork#sh run
!
voice translation-rule 3
rule 1 /0/ /1100/
!
!
voice translation-profile operator
translate called 3
!
!
dial-peer voice 1004 voip
translation-profile outgoing operator
destination-pattern 0
session protocol sipv2
session target ipv4:172.16.1.1
dtmf-relay rtp-nte
codec g722-64
no vad
!

6. Granting Arliss and Ari administrative privileges on CUE is as simple as adding each user to the Administrators group and adding a SIP phone number for prompt management.

groupname Administrators member amichaels
groupname Administrators member agold

ccn trigger sip phonenumber 1990
application "promptmgmt"
enabled
maxsessions 1
end trigger

7. The simplest way to restrict callers from dialing 976, 900, and 1010 number is to add a 24 x 7 call-blocking restriction to the telephony service on each router.

telephony-service
after-hours block pattern 1 9900 7-24
after-hours block pattern 2 9976 7-24
after-hours block pattern 3 91010 7-24

When testing this on both routers, I observed a difference in behavior between SCCP and SIP phones. On SCCP phones, once a pattern matched, such as 9-976, the user receives a fast busy tone. On SIP phones, rather than a receiving a fast-busy, the attempted call is simply dropped.

CUCME-CUE Lab 10.3 –CUCME-CUE Misc Items Wrap-up

This lab will likely conclude the CUCME-CUE labs, even though many Advanced CUE features such as IMAP, IVR, Live Record, and custom AA scripting were not covered. I am a bit torn on which topic to tackle next. My original intention was to continue to “build-out” Ballplayers, LLC as a true company might expand. Namely, I was going to stick with CUCME as the call processing, add a third CUCME site, and replace CUE with Unity Connection as a centralized integrated messaging solution. However, I am now gravitating toward jumping right to centralized call processing, Unified Communications Manager 7.0.

Each of these labs usually requires me a few days or even weeks of after-work-hours research and configuration. I will post the final configs for the Baltimore CUCME, New York CUCME, and Baltimore CUE in the coming days. Regardless of the direction that I ultimately decide upon, there will likely be a gap in posting for a few weeks. I am going to build a Microsoft 2003 Domain Controller with a simple AD to support which ever direction I take. I also plan to begin focusing a bit more on properly installing both Unity Connection and UCM in VMWare ESX 3.5, that way I am ready to roll in whichever direction I ultimately take.

References:
Cisco Systems. Cisco Unified Communications Manager Express System Administrator Guide. Available online.

Cisco Systems. Cisco Unity Express Voice-Mail and Auto-Attendant CLI Administrator Guide for 3.0 and Later Versions. Available online.

CUCME-CUE Lab 9 – New York City Messaging

2009-03-09T23:09:00.004-04:00

Users in New York also require voicemail features and functionality. The tasks in this lab pertain to extending access to the CUE in Baltimore to the users in New York.

CUCME-CUE Lab 9.1 – New York City Messaging Tasks

1. Configure users in New York with Cisco Unity Express voicemail.

2. Ensure that users in New York have their MWI lamp lit when a user leaves a voicemail.

3. Make sure that messages can be forwarded via either dial by name or by extension.

4. Ensure that in the event of a WAN failure, users can still access and retrieve voicemail.

5. Also ensure that external callers can leave messages for users in New York in the event of a WAN failure.

6. Users in off-net should be able to dial into the system to access their messages remotely.

7. Configure the mailboxes with the same size restrictions as described in Lab 8.1.

CUCME-CUE Lab 9.2 – New York City Messaging Task Verification
Please note, the tasks described in this lab “may or may not be” supported by Cisco. According to the Cisco datasheet for CUE:

“Cisco Unity Express (on NME-CUE only) can integrate with up to 10 Cisco Unified Communications Manager Express remote sites. This solution allows voicemail and Automated-Attendant features to be centralized for up to 10 sites when voicemail at each remote site is not essential and only a small number of users are at each site.”

Therefore, I do not officially endorse, nor would I advocate, this type of solution in a production environment on an AIM-CUE module, which I have used in my home lab. With that disclaimer, I based much of the configuration based on this document, along with some careful study of the Cisco Unity Express Voice-Mail and Auto-Attendant CLI Administrator Guide for 3.0 and Later Versions and some additional troubleshooting.

1. First, add the users to CUE in much the same way as was done in Lab 8. In the interest of space, I will omit a full description of the tasks; refer to Lab 8.2.

2. Next step is to add a dial-peer on the New York CUCME router pointing to the Baltimore-CUE module. Here is where I ran into my first series of problem. Originally, I used the Cisco Unified Communications Manager Express: SIP Implementation Guide as my reference, building out the CUE integration based on the “Configure connection to Cisco Unity Express” of this document. However, I encountered a few issues, namely DTMF relay and MWI issues, which I while address separately below.

3. DTMF Relay issue & resolution:

First problem was that while SIP phones could dial into the CUE at ext. 1999 when pressing the voicemail button, the system was not responding to any inputs on the keypad. My initial configuration under both the phones and the corresponding dial-peer used the suggested “dtmf-relay sip-notify” commands.

After a fair amount of troubleshooting, including changing and eliminating transcoding as a possible cause, I decided to opt with the “dtmf-relay rtp-nte” as referenced here. Note, I modified this configuration for all SIP phones, the voip dial-peers on the NYC CUCME, and voip dial-peers on the Baltimore CUCME. For example:

NewYork#sh run
!
voice register global
voicemail 1999
!
voice register pool 1
number 2001
call-forward b2bua busy 1999
call-forward b2bua mailbox 1999
call-forward b2bua noan 1999 timeout 20
dtmf-relay rtp-nte
!
!
dial-peer voice 1000 voip
description VOIP Peer to Baltimore
preference 1
destination-pattern 1...
session protocol sipv2
session target ipv4:172.16.1.1
dtmf-relay rtp-nte
codec g722-64
no vad
!
!
dial-peer voice 1999 voip
destination-pattern 1999
b2bua
session protocol sipv2
session target ipv4:10.1.12.3
dtmf-relay rtp-nte
codec g711ulaw
no vad
!

Finally, the change to “dtmf-relay rtp-nte” necessitated the following changes to the Baltimore CUE.

baltimore-cue# sh run
!
ccn subsystem sip
dtmf-relay sip-notify rtp-nte

With the changes and configurations described above, users in New York are now able to access their voicemail on the Baltimore CUE.

4. The next challenge was sending MWI to and from CUE in Baltimore to the phones in New York. Once again, the Cisco Unified Communications Manager Express: SIP Implementation Guide was used as reference, but the MWI lamps failed to light on the phones. The resolution was to configure MWI based on the Sub-Notify Notification described in the Cisco Unity Express Voice-Mail and Auto-Attendant CLI Administrator Guide for 3.0 and Later Versions combined with SIP: Configuring a Directory Number for MWI NOTIFY from the CUCME Admin Guide.

On the New York CUCME Router:

NewYork#sh run
!
voice register global
mwi stutter
mwi reg-e164
!
!
voice register dn 1
mwi
!
!
sip-ua
mwi-server ipv4:10.1.12.3 expires 3600 port 5060 transport udp

And on CUE in Baltimore:

baltimore-cue# sh run
!
ccn subsystem sip
mwi sip outcall sub-notify
!

5. Enabling callers to leave messages during a WAN failure requires some changes and modifications to various dial-peers. First, rather than create a new series of dial-peers out to the PSTN pointing to 410-555-1999 on the New York router, I chose to leverage the existing dial-peers and PSTN fallback capabilities described in Lab 4.0. However, those existing dial-peers used a destination-pattern of “10..”, which excludes “1999”. Therefore, changing the pattern to “1…”, as shown above in the DTMF discussion, takes care of this. The previously translation pattern will manipulate 1999 to 410-555-1999, resulting in the call routing out the PSTN to Baltimore.

6. However, inbound calls from the PSTN to 1999 will not reach CUE unless a new VOIP dial-peer is added, with in outgoing translation pattern (to CUE) for digit manipulation. Below provides the configuration changes required to allow inbound callers to reach the voicemail pilot point.

Baltimore#sh run
!
voice translation-rule 2
rule 1 /4105551999/ /1999/
!
!
voice translation-profile to-cue
translate called 2
!
!
dial-peer voice 1998 voip
mailbox-selection orig-called-num
description VM-AA-PSTN
translation-profile outgoing to-cue
destination-pattern 4105551999
session protocol sipv2
session target ipv4:10.1.12.3
dtmf-relay rtp-nte
codec g711ulaw
no vad
!

7. The easiest way to test the voicemail failover to the PSTN is to shut down the VOIP dial peers between the two CUCME locations and place a test call. In the example below, Nick Markakis at ext. 1002 is attempting to call Ari Gold at ext. 2005. First, you’ll notice the call being routed to Ari, who is not available to answer.

NewYork#
Mar 10 02:54:13.812: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Calling Number=2005, Called Number=2005, Peer Info Type=DIALPEER_INFO_SPEECH
Mar 10 02:54:13.812: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=2005
Mar 10 02:54:13.812: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Result=Success(0) after DP_MATCH_DEST
Mar 10 02:54:13.812: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=40005
Mar 10 02:54:13.816: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Calling Number=4105551002, Called Number=, Voice-Interface=0x0,
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH

Once the call-forward no answer timing is reached, CUCME attempts to forward the call to ext. 1999.

NewYork#
Mar 10 02:54:33.968: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Calling Number=2005, Called Number=, Voice-Interface=0x0,
Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
Peer Info Type=DIALPEER_INFO_SPEECH
Mar 10 02:54:33.968: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
Result=Success(0) after DP_MATCH_ORIGINATE; Incoming Dial-peer=40005
Mar 10 02:54:33.968: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Calling Number=, Called Number=1999, Peer Info Type=DIALPEER_INFO_SPEECH
Mar 10 02:54:33.968: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=1999
Mar 10 02:54:33.968: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Result=Success(0) after DP_MATCH_DEST
Mar 10 02:54:33.968: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=1001
2: Dial-peer Tag=1003
3: Dial-peer Tag=1002

Finally, you’ll notice the call now being forward out the PRI circuit in New York to the PSTN, back to CUE in Baltimore at 410-555-1999, where Nick can leave a message for his agent, Ari.

NewYork#

Mar 10 02:54:34.244: %ISDN-6-CONNECT: Interface Serial0/0/0:3 is now connected to 4105551999 N/A
Mar 10 02:54:34.244: %ISDN-6-CONNECT: Interface Serial0/0/0:3 is now connected to 4105551999 N/A

Mar 10 02:54:34.252: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Calling Number=, Called Number=4105551999, Peer Info Type=DIALPEER_INFO_SPEECH
Mar 10 02:54:34.252: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=4105551999

CUCME-CUE Lab 9.3 Wrap-up

Labs 8 and 9 represent just the tip of the iceberg when it comes to Unity Express. For a relatively inexpensive voicemail solution, it is very powerful with many robust features, including an IVR, Auto Attendant, Time Card application, and integrated messaging via IMAP. While I may explore a few more CUCME and CUE topics, I also want to begin moving on to the other core CCIE Voice topics.

References:
Cisco Systems. Cisco Unified Communications Manager Express: SIP Implementation Guide. Available online.

Cisco Systems. Cisco Unified Communications Manager Express System Administrator Guide. Available online.

Cisco Systems. Cisco Unity Express Voice-Mail and Auto-Attendant CLI Administrator Guide for 3.0 and Later Versions. Available online.

Cisco Systems. Failure to Set MWI on Phones Connected to the Remote CallManager Express. Available online.

CUCME-CUE Lab 8 – Initial CUE Setup & Baltimore Messaging

2009-02-28T12:11:00.003-05:00

Now that the CUCME systems for Baltimore and New York are functioning and employees can communicate with each other, Fuzzy Dunlop has given you the go ahead to implement voice messaging. However, due to the recession, funds are tight. As a result, Fuzzy has only given you the budget to purchase a single Cisco Unity Express AIM card to support both locations.

This lab will focus on the initial setup for CUE on the Baltimore 2811, as well as setting up basic voicemail for the Baltimore users. This lab and subsequent CUE labs are based on CUE 7.0. If you need to update you CUE image, excellent, well described instructions are outlined in the Cisco Unity Express 7.0 Installation and Upgrade Guide.

CUCME-CUE Lab 8.1 – Initial CUE Setup & Baltimore Messaging Tasks

1. Configure the Baltimore CUCME router to interface with CUE. Use extension 1999 as the voicemail pilot.

2. The IP Address for CUE should come from the voice subnet.

3. Use 8000 and 8001 for MWI.

4. Create voicemail users and mailboxes via the CUE CLI.

5. Mailboxes should be limited in size to accommodate up to 50 users on a AIM-CUE.

6. Make sure that messages can be forward via either dial by name or by extension.

7. Provision the system for GUI access.

CUCME-CUE Lab 8.2 – Initial CUE Setup & Baltimore Messaging Verification

1. Before you can begin configuring the CUE, you need to make some configuration modifications to the CUCME. A dial-peer needs to be created pointing to CUE. Next, the voicemail pilot needs to be added under the telephony-service. MWI is then created via an ephone-dn. Finally, call-forwarding needs to be provisioned for each user.

The details regarding the initial configuration parameters are covered in Configuring System Components chapter of the Cisco Unity Express Voice-Mail and Auto-Attendant CLI Administrator Guide for 3.0 and Later Versions.

Below are the configuration changes.

Baltimore#
!
dial-peer voice 1999 voip
destination-pattern 1999
session protocol sipv2
session target ipv4:10.1.12.3
dtmf-relay sip-notify
codec g711ulaw
!
telephony-service
voicemail 1999
!
!
ephone-dn 14
number 8000....
mwi on
!
!
ephone-dn 15
number 8001....
mwi off
!
ephone-dn 1 dual-line
call-forward busy 1999
call-forward noan 1999 timeout 4
!repeat for ephone-dns 2-5!
!
!
ephone 1
username "cripken" password null
!repeat for ephones 2-5!
!

2. Next step is to enable IP connectivity to the CUE. This requires some additional configuration on the CUCME side of the equation.

Baltimore#
!
interface Service-Engine0/0
ip unnumbered GigabitEthernet1/0.12
service-module ip address 10.1.12.3 255.255.255.0
service-module ip default-gateway 10.1.12.1
!

Once you’ve finished the above, you can session into the service-engine (CUE AIM).

Baltimore#service-module service-Engine 0/0 se
Baltimore#service-module service-Engine 0/0 session
Trying 10.1.12.1, 2194 ... Open
baltimore-cue#
baltimore-cue#

In the example above, I had previously logged into the CUE. If you haven’t yet done so, you will need to complete some basic CUE initialization tasks. Unfortunately, I was unable to find a concise document online that clearly articulates this initialization wizard. It is touched upon here. However, Chapter 11 of the IP Telephony Using CallManager Express Lab Portfolio covers it very well.

3. Now that there is connectivity between CUCME and CUE, users and mailboxes can now be created. Unfortunately, due to the way the CUE CLI functions, you have to create users in a somewhat disjointed fashion. The first step is to create the user and his/her phone numbers under configuration mode.

baltimore-cue(config)# username cripken create
baltimore-cue(config)# username cripken phonenumber 1001
baltimore-cue(config)# username cripken phonenumberE164 4105551001

Next, you need to create the mailbox for the use. However, per the requirement above, the configuration must support up to 50 users, thereby limiting the mailbox size to 720 seconds.

baltimore-cue(config)# voicemail mailbox owner "cripken" size 720
baltimore-cue(config-mailbox)#
baltimore-cue(config-mailbox)# description "cripken mailbox"
baltimore-cue(config-mailbox)# end mailbox

In order to facilitate the dial by name requirement, you must exit configuration mode and then modify the users their full first and last names.

baltimore-cue# username cripken fullname first Cal
baltimore-cue# username cripken fullname last Ripken

Finally, you can verify the user and the associate mailbox by issuing the “show user detail username NAME” and “show voicemail detail mailbox NAME” commands

baltimore-cue# show user detail username cripken
Username: cripken
Full Name: Cal Ripken
First Name: Cal
Last Name: Ripken
Nickname: Cal Ripken
Phone: 1001
Phone(E.164): 4105551001
Fax:
Email:
Epage:
Language: systemDefault
GroupMember:
GroupOwner:
Privileges:

baltimore-cue# show voicemail detail mailbox cripken
Owner: /sw/local/users/cripken
Type: Personal
Description: cripken mailbox
Busy state: idle
Enabled: true
Allow login without pin: no
Mailbox Size (seconds): 720
Message Size (seconds): 240
Play Tutorial: false
Fax Enabled: true
Space Used (seconds): 0
Total Message Count: 0
New Message Count: 0
Saved Message Count: 0
Future Message Count: 0
Deleted Message Count: 0
Fax Message Count: 0
Expiration (days): 30
Greeting: standard
Zero Out Number:
Created/Last Accessed: Feb 27 2009 17:47:37 EST

4. The final requirements on CUE involve configuration for communicating with CUCME and passing MWI. First, configure SIP to reach CUCME.

ccn subsystem sip
gateway address "10.1.12.1"
end subsystem

Next, the SIP trigger for the voicemail pilot, 1999, must be added to the system.

ccn trigger sip phonenumber 1999
application "voicemail"
enabled
maxsessions 4
end trigger

Finally, MWI must be enabled.

ccn application ciscomwiapplication aa
description "ciscomwiapplication"
parameter "strMWI_OFF_DN" "8001"
parameter "strMWI_ON_DN" "8000"

CUCME-CUE Lab 8.3 – Initial CUE Setup & Baltimore Wrap Up

CUCME and CUE has now been properly configured to interoperate. The best way to test the configuration is to place calls between phones and leave message. However, prior to this, each mailbox will require completion of the TUI setup wizard. Looking ahead, I will explore what it takes to have CUE support remote users, specifically the New York CUCME.

References:
Au, Danelle, et. al. (2005). Cisco IP Communications Express: CallManager Express with Cisco Unity Express. Indianapolis: Cisco Press.

Cisco Systems. Cisco Unity Express 7.0 Installation and Upgrade Guide. Available online.

Cisco Systems. Cisco Unity Express 7.0 Release Notes. Available online.

Cisco Systems. Cisco Unity Express Voice-Mail and Auto-Attendant CLI Administrator Guide for 3.0 and Later Versions. Available online.

Schmidt, Cheryl A., and Friend, Ernie (2007). IP Telephony Using CallManager Express Lab Portfolio. Indianapolis: Cisco Press.

CUCME-CUE Lab 7 – CUCME Conferencing & Transcoding

2009-02-23T22:29:00.004-05:00

Fuzzy Dunlop has asked for one final tweak to the CUCME solution. He would like to have the ability to support audio conferencing at each location as well as between locations. Finally, he would like some music for callers who are placed on hold.

CUCME-CUE Lab 7 – CUCME Conferencing & Transcoding Task
1. In Baltimore create Ad-Hoc & Meetme conferencing to support one session of eight conference participants.

2. Baltimore should use DN 1020 for Ad-Hoc and DN 1021 for Meetme.

3. MeetMe and AdHoc should be enabled using only on DN entry for each number conference bridge.

4. Provide an audible alert when someone joins or leaves a conference. The alerts should be different for joining and leaving.

5. Modify phone parameters to allow MeetMe, a list of Conference Attendees, and the ability to remove Conference Attendees.

6. Conference calls should be dropped once the initiator hangs-up, unless the remaining attendees are local participants.

7. Allow users with shared lines join to barge into the call using shared conference resources.

8. Enable Music on Hold for both internal and external callers.

9. Enable transcoding to support G.711, G.722, and G.729.

CUCME-CUE Lab 7 – CUCME Conferencing & Transcoding Verification

In order to configure and enable the Ad-Hoc and MeetMe conferencing described in tasks 1 – 6, there are a number of parameters that require configuration. I’ll walk through each below, but a detailed description of configuring conferencing on CUCME is available in the Configuring Conferencing of the Cisco Unified Communications Manager Express System Administrator Guide.

1. The first step in enabling hardware conferencing resources on CUCME is to enable DSP Farm Services on the router. Second, create the custom join and leave tones. Next, enable SCCP for CUCME, configure the DSP Farm, and then associate the DSP Farm with SCCP on the router.

Baltimore#
!
voice-card 0
dsp services dspfarm
!
!
voice class custom-cptone jointone
dualtone conference
frequency 1200 1200
cadence 150 50 150 50
!
voice class custom-cptone leavetone
dualtone conference
frequency 900 900
cadence 150 50 150 50
!
!
sccp local GigabitEthernet1/0.12
sccp ccm 10.1.12.1 identifier 1 priority 1 version 7.0
sccp
!
!
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
codec g722-64
maximum sessions 1
conference-join custom-cptone jointone
conference-leave custom-cptone leavetone
associate application SCCP
!
!
sccp ccm group 1
bind interface GigabitEthernet1/0.12
associate ccm 1 priority 1
associate profile 2 register transcode
associate profile 1 register conference
!

2. At the completion of the configuration above, you show see registration of the DSP farm with CUCME.

Baltimore#
Feb 23 03:54:33.452: %SYS-5-CONFIG_I: Configured from console by cisco123 on console
Feb 23 03:54:33.520: %DSPRM-5-UPDOWN: DSP 1 in slot 0, changed state to up
Baltimore#
Feb 23 03:54:33.528: %HWCONF-6-REGISTER: hwconf-1:conference IP:10.1.12.1 Socket:3 DeviceType:HW Conference has registered.
Baltimore#

3. The next piece of the puzzle is to enable the Ad-hoc and MeetMe components. First, associate the hardware conferencing resources with the telephony-service. Then, configure two ephone-dns, one for the Ad-hoc bridge and the other for the MeetMe bridge. Note the requirement to use only one ephone-dn for each conference bridge; this necessitates the use of octal dns.

!
telephony-service
sdspfarm units 5
sdspfarm tag 1 conference
!
!
ephone-dn 12 octo-line
number 1020
name Baltimore AdHoc
conference ad-hoc
!
!
ephone-dn 13 octo-line
number 1021
name Baltimore-MeetMe
conference meetme

4. The final step to enable MeetMe and AdHoc conferencing is to modify the ephone templates to enable the MeetMe, Conference Attendee List, and Remove features, followed by applying the template to each phone.

!
ephone-template 1
conference drop-mode local
conference admin
softkeys seized Endcall Redial Cfwdall Meetme Pickup Callback
softkeys connected Hold Endcall Park Confrn Trnsfer Select Join ConfList RmLstC Flash
!

5. While SIP Phones do not support hardware conferencing, AdHoc conference must be configured and enable in order to support cBarge functionality. Below is an example of the entire series of configuration parameters necessary to complete this task.

NewYork#
!
voice-card 0
dsp services dspfarm
!
!
voice class custom-cptone leavetone
dualtone conference
frequency 900 900
cadence 150 50 150 50
!
voice class custom-cptone jointone
dualtone conference
frequency 1200 1200
cadence 150 50 150 50
!
!
sccp local FastEthernet0/0.22
sccp ccm 10.1.22.1 identifier 1 priority 1 version 7.0
sccp
!
!
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
codec g722-64
maximum sessions 1
conference-join custom-cptone jointone
conference-leave custom-cptone leavetone
associate application SCCP
!
!
sccp ccm group 1
bind interface FastEthernet0/0.22
associate ccm 1 priority 1
associate profile 2 register transcode
!
!
telephony-service
sdspfarm units 5
sdspfarm tag 2 transcode
!
!
!
ephone-dn 2 octo-line
number 2020
name NY AdHoc
conference ad-hoc
!
!
voice register template 1
softkeys remote-in-use Barge cBarge Newcall

6. The configuration parameters for transcoding resources is very similar to configuring hardware conferencing resource. Since the DSP Farm was previously enabled for conference along with the proper SCCP configuration, the only additional configuration required is the creation of another dspfarm profile for transcoding. The additional profile is then associated with the sccp group, followed by enabling transcoding resources under the telephony service. Below is additional configuration for Baltimore; New York is identical.

NewYork#
!
dspfarm profile 2 transcode
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729br8
codec g722-64
maximum sessions 3
associate application SCCP
!
!
sccp ccm group 1
associate profile 2 register transcode
!
!
telephony-service
sdspfarm transcode sessions 3
sdspfarm tag 2 transcode

7. Besides the obvious verification through phone operation, we can use a variety of show commands to check proper configuration.

Below shows two calls on hold, with MOH streaming. Because MOH uses G.711 and the handsets are configured to use G.722, transcoding resources are required.

NewYork#sh dspfarm dsp all
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED

0 1 23.8.1 UP N/A FREE conf 1 - - -
0 2 23.8.1 UP 1 USED xcode 2 0x26 113 461
0 2 23.8.1 UP 1 USED xcode 2 0x27 455 0
0 2 23.8.1 UP N/A FREE xcode 2 - - -
0 2 23.8.1 UP N/A FREE xcode 2 - - -

Total number of DSPFARM DSP channel(s) 4

8. In the next example, Ari Gold uses Tom Seaver’s extension to initiate a call. Tom then decides to utilize cBarge, resulting in AdHoc hardware resource being used.

NewYork#sh dspfarm dsp all
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED

0 1 23.8.1 UP 1 USED conf 1 0x36 334 331
0 1 23.8.1 UP 1 USED conf 1 0x38 330 329
0 1 23.8.1 UP 1 USED conf 1 0x3A 326 326
0 2 23.8.1 UP N/A FREE xcode 2 - - -
0 2 23.8.1 UP N/A FREE xcode 2 - - -
0 2 23.8.1 UP N/A FREE xcode 2 - - -

Total number of DSPFARM DSP channel(s) 4

9. Finally, we demonstrate the use of the MeetMe conference available on the SCCP phones in Baltimore below.

Baltimore#sh ephone-dn conference
type active inactive numbers
=======================================
Ad-hoc 0 8 1020
DN tags: 12

Meetme 4 4 1021
DN tags: 13

Baltimore#

Baltimore#sh dspfarm dsp all
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED

0 1 23.8.1 UP 1 USED conf 2 0x1C 5854 5849
0 1 23.8.1 UP 1 USED conf 2 0x1E 5504 4295
0 1 23.8.1 UP 1 USED conf 2 0x20 5004 4998
0 1 23.8.1 UP 1 USED conf 2 0x23 154 148
0 2 23.8.1 UP N/A FREE xcode 1 - - -
0 2 23.8.1 UP N/A FREE xcode 1 - - -
0 2 23.8.1 UP N/A FREE xcode 1 - - -

Total number of DSPFARM DSP channel(s) 4

Baltimore#

CUCME-CUE Lab 7 Wrap-up
With the completion of conferencing and transcoding, the table is now set to explore Unity Express configuration in the next series of labs.

CUCME-CUE Lab 6 – More Advanced CUCME Call Features

2009-02-17T23:09:00.003-05:00

Now that the New York and Baltimore locations are running CUCME 7.1 (see CUCME-CUE Labs - 7.1 Update), Fuzzy Dunlop has asked you to add some additional CUCME features to Baltimore and New York. Some of these tasks absolutely require CUCME 7.1, so make sure you’ve updated your CUCME router IOS and CUCME files accordingly.

CUCME-CUE Lab 6 – More Advanced CUCME Call Features Task

1. Ari Gold and Arliss Michaels are the branch managers for New York and Baltimore, respectively. As such, they each require the ability to make and receive calls for Tom Seaver and Cal Ripken at their respective locations. Therefore, configure each location to support these shared lines.

2. In New York, create a directed call-park slot with extension 2800. Anyone who parks a call should be reminded every 30 seconds, up to 10 reminders. Use feature access code 50 to pick up the call.

3. Configure Joe Flacco’s phone so that he shares Arliss’s 1005 extension. However, Arliss should have the ability to mark a call as private on when using this line.

4. Arliss is constantly traveling to woo new clients and requires that he receives phone calls on multiple devices such as his iPhone. Configure mobility features to facilitate this function; use 410-555-9995 as his iPhone DN. Also configure his 7962 so that the ability to use this feature is displayed on this phone while idle or seized, without the need to press any addition keys.

5. Enable Presence features on Arliss’s phone so that he can monitor both Cal Ripken and Joe Flacco.

6. Enable Presence features on both Ari Gold and Tom Seaver so that they can monitor each other.

CUCME-CUE Lab 6 – More Advanced CUCME Call Features Task Verification

1. While SCCP shared lines is a long supported CUCME feature, SIP shared lines is a new CUCME 7.1 enhancement, fully described in the SIP: Creating Directory Numbers section of the Cisco Unified Communications Manager Express System Administrator Guide. Below are the configurations for both Baltimore and New York.

Baltimore#
!
ephone-dn 1 dual-line
number 1001
label Cal Ripken 1001
description 410-555-1001
name Cal Ripken
huntstop channel
translate called 1
!
ephone 5
description Arliss Michaels
button 1:5 2:1 3:8
!

NewYork#
!
voice register dn 1
number 2001
name Tom Seaver
shared-line
huntstop
label Tom Seaver 2001
!
!
voice register pool 5
type 7962
number 1 dn 5
number 2 dn 1
description 212-555-2005
!

2. Call Parking is also a new SIP enhancement in CUCME 7.1. A detailed discussion of the various configuration parameters and options is available in the Configuring Call Park chapter of the Cisco Unified Communications Manager Express System Administrator Guide. Below are the configuration parameters for New York based on the task requirements described above.

NewYork#sh run begin telephony-service
!
telephony-service
call-park system application
fac custom dpark-retrieval 50
!
ephone-dn 1
number 2800
park-slot directed timeout 30 limit 10

3. To enable the shared line appearance on Joe Flacco’s phone, simply add the dn associated with the second number on his phone. Secondly, disable privacy globally under telephony-service, and then add the privacy parameters under Arliss’s phone.

Baltimore#
!
ephone 3
description Joe Flacco
button 1:3 2:5
!
!
telephony-service
no privacy
!
!
ephone 5
privacy off
privacy-button
device-security-mode none
description Arliss Michaels

4. Single Number Reach is a new CUCME feature only available on SCCP. The configuration is pretty simple; you enable it under a DN and then modify the phone template to activate the softkey. However, note the requirement stating that the Mobility feature be available without having to press the “more” softkey; this mandates the “mobility” keyword early in the template configuration. Of course, do not forget to add “9” to the number in order to get offnet. For example:

Baltimore#sh run begin ephone-dn 5
!
ephone-dn 5 octo-line
name Arliss Michaels
mobility
snr 94105559995 delay 5 timeout 15
!
ephone-template 2
softkeys idle Redial Newcall Mobility Cfwdall Pickup
softkeys connected Hold Endcall Mobility Park Confrn Trnsfer Select Join ConfList RmLstC Flash
!
ephone 5
description Arliss Michaels
ephone-template 2

5. Since Ballplayers, LLC does not yet have an external Presence server, enabling the Presence capabilities on the phones is a fairly simple task. Configuration guidance is provided in the Configuring Presence Service chapter of the Cisco Unified Communications Manager Express System Administrator Guide. The configuration parameters for both Baltimore and New York are provided below.

Baltimore#
!
presence
presence call-list
max-subscription 144
!
sip-ua
presence enable
!
ephone-dn 1 dual-line
number 1001
label Cal Ripken 1001
allow watch
!
!
ephone-dn 3 dual-line
number 1003
label Joe Flacco 1003
allow watch
!
ephone 5
blf-speed-dial 1 1001 label "Cal Ripken" device
blf-speed-dial 2 1003 label "Joe Flacco" device

NewYork#
!
presence
presence call-list
max-subscription 144
!
sip-ua
presence enable
!
voice register dn 1
number 2001
allow watch
name Tom Seaver
!
!
voice register dn 5
number 2005
allow watch
name Ari Gold
!
!
voice register pool 1
description 212-555-2001
blf-speed-dial 1 2005 label "Ari Gold" device
!
!
voice register pool 5
description 212-555-2005
blf-speed-dial 1 2001 label "Tom Seaver" device

CUCME-CUE Lab 6 Wrap-up
While there are certainly many more Advanced CUCME features that could be added, the next series of labs will focus on conferencing and transcoding, which will then segue nicely to some Unity Express labs.

References:
Au, Danelle, et. al. (2005). Cisco IP Communications Express: CallManager Express with Cisco Unity Express. Indianapolis: Cisco Press.

Cisco Systems. Cisco Unified Communications Manager Express: SIP Implementation Guide. Available online.

CUCME-CUE Labs - CUCME Release 7.1 Update

2009-02-09T22:46:00.007-05:00

Before moving onto to the next series of labs, I've updated the router code to reflect the newest CUCME 7.1 update. Using the Cisco Unified CME 7.1 Supported Firmware, Platforms, Memory, and Voice Products, the updates consist of the following:

cme-124-22YB1.zip: contains all of the appropriate CUCME packages, except the actual IOS.
IOS 12.4(22)YB, c2800nm-adventerprisek9_ivs-mz.124-22.YB.bin, feature set "INT VOICE/VIDEO GK, IPIPGW, TDMIP GW AES"

For the upgrade, I completed the following procedures:

Booted the routers. I also back up the configs.
Cleaned up the existing flash, removing the existing IOS code, gui files, phones loads, so on. Note, on the NY router, I copied the modified ring lists and "Lets Go Mets Go" ringtone to the root directory on flash.
Uploaded the new IOS. Rebooted.
Uploaded the appropriate TAR files (gui, ringtones, phone loads)
Modified the existing configs to reflect the new phone loads, etc.
Began poking around...

During which should have been a straight forward update, I noticed the following pecularities:

The SIP phone loads for the 79xx phones are now bundled with the CUCME Zip package, which means that you no longer have to fish for these separately.

During the phone upgrade failed initially on the Baltimore SCCP router. Upon further investigation, the phones stated that the JAR files could not be located. After playing around with various commands, the router console barked that the "system" was not a valid location associated with the "load 7942 SCCP42.8-4-2S" command. I untuitively poked around under the "telephony-service" section and added the "cnf-file location flash:". Note, this was not required for the SIP router (NY).

The NY upgrade started off without any hitches. However, when I tried to test calls across the VOIP link to Baltimore, the phones in NY would just dial the number and sit idle, until eventually timing out with a fast busy. This proved to be a very time consuming troubleshooting process...

I began by looking at the VOIP (SIP) dial peers configured CUCME-CUE Lab 4 – CUCME POTS & VoIP Dial Peers. Everything looks correct. Hmm...
After spending an inordinate amount of time dwelling above, I modified the dial peers to H323. Vola! calls were working correctly across the VOIP link. So, I reset them back to SIP.
I started tweaking various parameters, such as the “destination-pattern” as well as the “dialplan patterns”. After some nerd-knob tuning, I was able to pass calls. Cool, or so I thought.
However, upon closer inspection, the calls were using the PSTN, not the VOIP link.
After beating my head against the wall for another 90 minutes or so, looking at various debug outputs, and consulting various documentation on CCO, the thought occurred to look elsewhere. This time I deactivated call fallback on one end. At this point, I was able to pass a call across the VOIP link. Ok, on to something.
I still not want to give up on call fallback. I consulted the Configuring SIP QoS Features chapter of the Cisco IOS SIP Configuration Guide, Release 12.4T. Upon my interpretation of this document, call fallback should be a fairly straight-forward and simple configuration. However, despite my efforts, I could not get call fall to work properly with the SIP dial peer.

The end result was to remove all the call fallback parameters discussed on CUCME-CUE Lab 4 – CUCME POTS & VoIP Dial Peers. I hesitate to call this a “bug” since in my personal experience most “bugs” = user misconfiguration. I’ll return to this at a later date, but for now I will move on without this command.

CUCME-CUE Lab 5 – Advanced CUCME Call Features

2009-02-03T23:59:00.005-05:00

Now that there is basic call connectivity between each location as well as to the PSTN, Fuzzy Dunlop is interested in implementing some advanced calling features.

Note, when I started researching and developing this lab, CUCME 7.1 had not yet been released. However, since that time, I have noticed CUCME 7.1 files are now posted on CCO, and the Cisco Unified Communications Manager Express System Administrator Guide reflects many of these new updates. Therefore, some tasks that did not work with SIP phones under CUCME 7.0 but are now supported under CUCME 7.1 shall be added in a later lab.

Lab 5.1 –Advanced CUCME Call Features Configuration Tasks
1. On each phone, modify the Phone Head Bar Display to reflect the phone’s E.164 phone number.

2. On each phone, modify the existing labels next to each line appearance to reflect the four-digit extension as well as the primary owner’s name.

3. Ensure that the name associated with each calling party’s extension when a call is ringing on another IP phone is properly displayed.

4. Ensure that the local directory include listings for the all users, including those at the remote location.

5. In Baltimore, configure a hunt-group that contains Arliss Michaels and Cal Ripken as members. However, Arliss should always be first person to receive a call. Assign extension 1050 to this hunt group.

6. In New York, configure a configure a hunt-group with extension number 2050. Ari Gold and Tom Seaver should be assigned to this hunt-group, and phones should ring in a round-robin fashion, based on the last phone that rang. However, Ari’s extension should appear first.

7. In Baltimore, create a call-park with extension 1800. Anyone who parks a call should be reminded every 30 seconds, up to 10 reminders. Joe Flacco should be prevented from parking calls using the transfer key.

8. Cal Ripken would like to be to have an intercom to Arliss, and vice versa. However, no one else in Ballplayers, LLC should be able to dial this set on intercoms. The intercom should be configured so that each party can talk to each other without any manual intervention. Each side should also have a visual display indicating the name of the individual on the other side of the intercom.

9. Cal Ripken and Nick Markakis should belong to a paging group called Orioles.

10. Joe Flacco and Ray Lewis should below to a paging group called Ravens.

11. Both groups should be combined into a paging group called All Baltimore Sports. Arliss should be included in this group.

12. Ensure the paging configuration can exceed 10 IP Phones in the future, if necessary.

Lab 5.2 –Advanced CUCME Call Features Verification
Many of the tasks described in this lab were based off of either Chapter 15 of the Cisco Press release, Cisco IP Communications Express: CallManager Express with Cisco Unity Express or from the Cisco Unified Communications Manager Express System Administrator Guide. I’ll do my best below to provide references where appropriate.

1. On the Baltimore (SCCP) CUCME, modifying the Phone Head Bar Display, the line appearance labels, and Caller-ID Name are performed under ephone-dn configuration. For example, Cal Ripken is configured as follows:

ephone-dn 1 dual-line
number 1001
label Cal Ripken 1001 #sets the line appearance #
description 410-555-1001 #sets the Phone Head Bar Display#
name Cal Ripken #sets Caller-ID Name#

2. For SIP Phones (NY CUCME), the configuration is slightly different. The Caller-ID Name and the line appearance labels are modified under the dn configuration, while the Phone Head Bar Display is modified under the phone itself. For example, Tom Seaver’s modifications are as follows:

voice register dn 1
number 2001
name Tom Seaver #sets Caller-ID Name#
label Tom Seaver 2001 #sets the line appearance #
!
!
voice register pool 1
id mac 0021.D8BA.2373
type 7942
number 1 dn 1
description 212-555-2001 #sets the Phone Head Bar Display#

3. To ensure that the Baltimore users have NY users in their local phone directories, and vice versa, you need to manually add those entries for the remote site. In Baltimore, to add the NY users, the configuration is as follows:

telephony-service
directory entry 1 2001 name Tom Seaver
directory entry 2 2002 name David Wright
directory entry 3 2003 name Eli Manning
directory entry 4 2004 name Brandon Jacobs
directory entry 5 2005 name Ari Gold

4. The Configuring Call-Coverage Features chapter covers the SCCP hunt group configuration options. The hunt group described for Baltimore is a sequential hunt group. The key is to make sure you address the multiple calls on a single line by adding the appropriate huntstop commands under the appropriate dns.

The first step is to configure ephone-hunt parameters. Secondly, you modify the ephone-dn huntstop parameters for the dns that are members of the hunt group. Note that since Arliss’s dn is an octo-line, you must explicitly state which channel the hunting should stop on.

ephone-hunt 1 sequential
pilot 1050 secondary 4105551050
list 1005, 1001
!
ephone-dn 1 dual-line
huntstop channel
!
ephone-dn 5 octo-line
huntstop channel 1

5. The hunt-group described for New York is a peer hunt group. Initially, I found the CUCME 7.0 documentation pertaining to SIP Hunt Groups to be “ambiguous”. The updated CUCME 7.1 chapter on Configuring Call-Coverage Features, and specifically the Configuring Voice Hunt Groups section is an improvement, but I still found the “Cisco Unified Communications Manager Express: SIP Implementation Guide” to be much clearer. Below are the configuration components for the NY CUCME SIP Hunt Group.

voice hunt-group 1 peer
list 2005,2001
timeout 180
pilot 2050
!
voice register dn 1
huntstop
!
voice register dn 5
huntstop

6. A common “CCIE gotchya” is to instruct you to configure something, and the candidate “over interprets” the task. For the call park task, the configuration seems pretty straight-forward, with the curve ball (pardon the pun) of preventing Joe Flacco from transferring a call to the park slot.

In the configuration below, an ephone-dn is created for park slot 1800. Joe Flacco’s phone is prevented from dialing 1800 to transfer to the park slot. However, the task does not explicitly state to remove this feature from the soft key template, so Joe can still park a call this way.

One final note, when I began developing this lab, SIP lines did not support call park. This is now supported under CUCME 7.1!

ephone-dn 6
number 1800
park-slot timeout 30 limit 10
!
ephone 3
transfer-park blocked
description Joe Flacco

7. Intercom configuration for SCCP phones is described in the Configuring Intercom Lines chapter of the Cisco Unified Communications Manager Express System Administrator Guide. The chapter also covers Intercom configuration for SIP, which I could not get to work properly based on the example provided. If anyone else has manager to get SIP Intercom working, I’d love to hear your feedback and suggestion.

Note the requirement that the Intercom numbers between Cal Ripken and Arliss Michaels be private; prepending the dn with a letter adresses this requirement.

ephone-dn 7
number A9990
label Intercom to Arliss
intercom A9991 no-mute label "Arliss"
!
!
ephone-dn 8
number A9991
label Intercom to Cal Ripken
intercom A9990 no-mute label "Cal"
!
ephone 1
description Cal Ripken
button 1:1 2:7
!
ephone 5
description Arliss Michaels
button 1:5 2:8

8. Finally, the paging group feature is seemingly a straight-forward configuration task, with a hidden gotchya. Recall the task stating “the paging configuration can exceed 10 IP Phones in the future.” A careful read of the Configuring Paging chapter of the Cisco Unified Communications Manager Express System Administrator Guide would reveal that if multicast paging is not implemented, the maximum number of unicast transmission is limited to 10 IP Phones. This is another example where if a candidate does not carefully read the task, he could easily loose all the points associated with this sub-section of the actual lab!

ephone-dn 9
number 1500
name Orioles
paging ip 239.0.1.9 port 2000
!
!
ephone-dn 10
number 1600
name Ravens
paging ip 239.0.1.10 port 2000
!
!
ephone-dn 11
number 1700
name All Baltimore Sports
paging ip 239.0.1.11 port 2000
paging group 9,10
!
ephone 1
description Cal Ripken
paging-dn 9
!
ephone 2
description Nick Markakis
paging-dn 9
!
ephone 3
description Joe Flacco
paging-dn 10
!
ephone 4
description Todd Heap
paging-dn 10
!
ephone 5
description Arliss Michaels
paging-dn 11
!

CUCME-CUE Lab 5 Wrap-up
With the release of CUCME 7.1, I will try to address additional line-side features in the next lab. I’ll also plan to cover transcoding, in order to position for later CUE labs.

References:
Au, Danelle, et. al. (2005). Cisco IP Communications Express: CallManager Express with Cisco Unity Express. Indianapolis: Cisco Press.

Cisco Systems. Cisco Unified Communications Manager Express: SIP Implementation Guide. Available online.

Cisco Systems. Cisco Unified Communications Manager Express System Administrator Guide. Available online.

CUCME-CUE Lab 4 – CUCME POTS & VoIP Dial Peers

2009-01-15T09:42:00.005-05:00

So far, Fuzzy Dunlop is impressed with the Cisco Unified Communications Express pilot in the Baltimore and New York offices. However, he has now instructed you to configure the two CUCME routers to interface with the PSTN as well as providing VoIP calls between the two locations over the frame relay link. Your tasks are as follows below.

Lab 4.1 – CUCME POTS and VoIP Dial Peer Tasks
1. Fuzzy is a cheap CIO – he has only provisioned the PRI for twelve channels. Configure an inbound POTS dial peer to support this.
2. Both Arliss Michaels and Ari Gold require a special inbound POTS line on top of their DID number associated with the PRI circuit. In Baltimore, make sure 410-555-5001 is routed to Arliss’s phone and 212-555-6001 is routed to Ari’s phone in New York. Ensure that Arliss and Ari always know who is calling inbound on these numbers.
3. Internal users must dial “9” to place and outside call. When dialing “9”, a different dial tone should be heard on the internal phones.
4. The PRI circuits at both locations should take precedence over the POTS connections for outbound calls.
5. Outbound destination patterns should be configured in such a way to allow outbound calls to be placed as quickly as possible, without any unnecessary delay.
6. Create appropriate inbound dialing for support the DID range and dial plans depicted in the diagram in Lab 3.1.
7. The security phones depicted in the diagram in Lab 3.1 should be mapped appropriately 410-555-5002 and 212-555-6002.
8. Internal users should be able to dial “H-E-L-P” on their IP Phones, which will ring the analog security phones at each location.
9. Configure an appropriate VOIP dial peer to allow four-digit dialing over the Frame Relay link. Maintain the G.722 codec (we’ll cover transcoding in a subsequent lab).
10. Configure each CUCME to route internal four-digit dial calls out the PSTN in the event of a WAN failure. Make sure the IP path is preferred first; the PRI circuit second; the POTS lines third.
11. You may not use any sort of digit translation on the Baltimore router to achieve task #10.
12. You must use digit translation on the NY router to achieve task #10.
13. Verify calling, including routing calls to the PSTN during a WAN failure.

Lab 4.2 – CUCME POTS and VoIP Dial Peer Task Verification
Most of the tasks in the lab are fundamentally similar, and in some instances, the same, as some of the VOIP and POTS dial peer tasks in the VOIP Fundamentals Labs. Therefore, rather than repeating myself, I will cover the tasks that are either new or different from the previous VOIP Fundamentals labs.

1. When configuring the MFT on the CUCME routers, I only configure twelve (12) B-Channels. The main reason is simply to conserve DSP resources for later configuration tasks, such as transcoding and conferencing.

!
controller T1 0/0/0
cablelength short 110
pri-group timeslots 1-12,24
!

2. To accomplish the task of routing one of the inbound POTS (FXO) lines directly to either Arliss or Ari, simply configure those FXO ports as a plar obx connection. You’ll also do the same for the security phone at each location.

!
voice-port 0/1/0
connection plar opx 2005
description inbound 212-555-6001
caller-id enable
!

3. To allow secondary dial-tone for external calls, simply add the “secondary-dialtone” command under the telelphony service. However, I could not get secondary dial-tone to work on the SIP CUCME router. The CUCME Administration Guide is extremely vague as to whether SIP CUCME supports this. There is no “secondary-dialtone” equivalent command under voice register global mode.

telephony-service
secondary-dialtone 9

User error (me) perhaps? Anyone else out there get secondary dial-tone to work on their SIP CUCME router?

4. There are at least two ways to configure the “H-E-L-P” requirement. One fairly simple approached is to configure another POTS dial-peer for destination-pattern 4357 (HELP), mapping it to the FXS with the attached analog device.

A second possibility is to create a translation rule, and then map this rule to each ephone-dn. For example:

!
translation-rule 1
Rule 0 ^4357 1611
!
!
ephone-dn 1 dual-line
translate called 1

5. I added the call fallback to each router. This significantly speeds up the process of falling back to a PSTN dial-peer in the event of a VOIP/WAN link failure. Below is an output of a call being routed over the PSTN (PRI) during a WAN failure.

##Shutting down the Frame Relay link##

Baltimore(config)#int s0/2/0
Baltimore(config-if)#shut

NewYork#sh call fallback cache

Fallback Mode : Active

Type Id IP Address Codec Delay Loss ICPIF Reject Accept
---- ----- ---------- ----- ----- ---- ----- ------ ------
ICMP 1 172.16.1.1 No Codec N/A 100 N/A 0 0

1 active probes

##placing a call from 2005 to 1005##

NewYork#
Jan 15 05:03:04.578: %ISDN-6-CONNECT: Interface Serial0/0/0:11 is now connected to 4105551005 N/A
Jan 15 05:03:04.578: %ISDN-6-CONNECT: Interface Serial0/0/0:11 is now connected to 4105551005 N/A
NewYork#

6. One additional comment/observation before providing the pertinent “show run” edits for each CUCME router. I was having no luck getting the SIP phones to display their local directory numbers (NYC Router). After reviewing the various SIP XML and systems files, and comparing them against their SEP counterparts, something caught my attention.

I noticed that that the while the SEP XML and systems files where telling the SCCP phones to point to the router’s local director via HTTP, I did not observe this on the SIP CUCME router SIP XML and systems files. Therefore, under voice register global, I add a URL for the directory on the local router. This seems to have rectified the issue.

voice register global
url directory http://10.1.22.1:80/localdirectory

7. Below are the pertinent “show run” edits for the Baltimore and New York CUCME routers.

Baltimore CUCME

Baltimore#sh run
!
card type t1 0 0
!
network-clock-participate wic 0
!
isdn switch-type primary-ni
!
controller T1 0/0/0
cablelength short 110
pri-group timeslots 1-12,24
!
!
translation-rule 1
Rule 0 ^4357 1611
!
!
ip sla responder ##for the call fallback##
!
!
call fallback active
!
!
voice-port 0/0/0:23
description PRI ciruit to PSTN
!
voice-port 0/1/0
connection plar opx 1005
description inbound 410-555-5001
caller-id enable
!
voice-port 0/1/1
connection plar opx 1611
description inbound 410-555-5002
caller-id enable
!
voice-port 0/3/0
description Baltimore-Security
caller-id enable
!
voice-port 0/3/1
caller-id enable
!
!
dial-peer voice 1 pots
description outbound via pri
preference 1
destination-pattern 9[2-9].........
port 0/0/0:23
!
dial-peer voice 2 pots
description outbound via 410-555-5001
preference 2
destination-pattern 9[2-9].........
port 0/1/0
!
dial-peer voice 3 pots
description outbound via 410-555-5002
preference 2
destination-pattern 9[2-9].........
port 0/1/1
!
dial-peer voice 4 pots
description inbound PRI dial-peer
incoming called-number .
direct-inward-dial
port 0/0/0:23
!
dial-peer voice 1611 pots
description Baltimore-Security
destination-pattern 1611
port 0/3/0
!
dial-peer voice 2000 voip
description VOIP Peer to NYC
preference 1
destination-pattern 20..
monitor probe icmp-ping 172.16.1.2
session protocol sipv2
session target ipv4:172.16.1.2
dtmf-relay rtp-nte
codec g722-64
!
dial-peer voice 2001 pots
preference 2
destination-pattern 20..
port 0/0/0:23
forward-digits all
prefix 212555
!
dial-peer voice 2002 pots
preference 3
destination-pattern 20..
port 0/1/0
forward-digits all
prefix 212555
!
dial-peer voice 2003 pots
preference 3
destination-pattern 20..
port 0/1/1
forward-digits all
prefix 212555
!
!
ephone-dn 1 dual-line
number 1001
label Cal Ripken 1001
description 410-555-1001
name Cal Ripken
translate called 1
!

New York CUCME

NewYork#sh run
!
card type t1 0 0
!
network-clock-participate wic 0
!
isdn switch-type primary-ni
!
!
voice register global
url directory http://10.1.22.1:80/localdirectory
!
voice translation-rule 1
rule 1 /\(10..\)/ /410555\1/ ##for the PSTN fallback translation##
!
!
voice translation-profile prefix
translate called 1 ##for the PSTN fallback translation##
!
!
controller T1 0/0/0
cablelength short 110
pri-group timeslots 1-12,24
!
!
ip sla responder
!
call fallback active
!
!
voice-port 0/0/0:23
description PRI ciruit to PSTN
!
voice-port 0/1/0
connection plar opx 2005
description inbound 212-555-6001
caller-id enable
!
voice-port 0/1/1
connection plar opx 2611
description inbound 212-555-6002
caller-id enable
!
voice-port 0/3/0
description NewYork-Security
caller-id enable
!
voice-port 0/3/1
caller-id enable
!
ccm-manager fax protocol cisco
!
mgcp fax t38 ecm
!
!
!
dial-peer voice 1 pots
description outbound via pri
preference 1
destination-pattern 9[2-9].........
port 0/0/0:23
!
dial-peer voice 2 pots
description outbound via 212-555-6001
preference 2
destination-pattern 9[2-9].........
port 0/1/0
!
dial-peer voice 3 pots
description outbound via 212-555-6002
preference 2
destination-pattern 9[2-9].........
port 0/1/1
!
dial-peer voice 4 pots
description inbound PRI dial-peer
incoming called-number .
direct-inward-dial
port 0/0/0:23
!
dial-peer voice 2611 pots
description NewYork-Security
destination-pattern 2611
port 0/3/0
!
dial-peer voice 1000 voip
description VOIP Peer to Baltimore
preference 1
destination-pattern 10..
monitor probe icmp-ping 172.16.1.1
session protocol sipv2
session target ipv4:172.16.1.1
dtmf-relay rtp-nte
codec g722-64
!
dial-peer voice 1001 pots
translation-profile outgoing prefix
preference 2
destination-pattern 10..
port 0/0/0:23
forward-digits all
!
dial-peer voice 1002 pots
translation-profile outgoing prefix
preference 3
destination-pattern 10..
port 0/1/0
forward-digits all
!
dial-peer voice 1003 pots
translation-profile outgoing prefix
preference 3
destination-pattern 10..
port 0/1/1
forward-digits all
!
dial-peer voice 4357 pots
description NewYork-Security
destination-pattern 4357
port 0/3/0
!