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

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.3 – Basic CUCM Phone and User Configuration

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.

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

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 4 – Unity Connection & CUCME New York Integration

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.

CUCME-CUE Lab 10 – CUCME-CUE Misc Items

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 7 – CUCME Conferencing & Transcoding

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

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

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:

1. Booted the routers. I also back up the configs.
2. 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.
3. Uploaded the new IOS. Rebooted.
4. Uploaded the appropriate TAR files (gui, ringtones, phone loads)
5. Modified the existing configs to reflect the new phone loads, etc.
6. 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...

1. I began by looking at the VOIP (SIP) dial peers configured CUCME-CUE Lab 4 – CUCME POTS & VoIP Dial Peers. Everything looks correct. Hmm...
2. 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.
3. 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.
4. However, upon closer inspection, the calls were using the PSTN, not the VOIP link.
5. 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.
6. 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

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

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
!