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 9 – New York City Messaging

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

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

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
!

CUCME-CUE Lab 3 – New York Basic CUCME System Setup

Ballplayers, LLC’s CIO, Fuzzy Dunlop, is interested in learning more about standards-based Unified Communications protocols. Since Baltimore’s CUCME configuration was based on proprietary Cisco SCCP protocol, he has instructed you to configure the New York CUCME using SIP.

New York Basic CUCME System Setup Prerequisites
If you haven’t already done so, you will need to load the appropriate CUCME files on the New York router. The tasks and options associated with this were described in CUCME-CUE Lab 2, Baltimore Basic CUCME System Setup Prerequisites.

One note, the SIP phone loads are not included in the cme-124-22T2.zip. Therefore, you will need to download these separate from CCO, place them on your FTP or TFTP server, and load them onto your router appropriately. Please refer to the Cisco Unified CME 7.0(1) Supported Firmware, Platforms, Memory, and Voice Products for the compatible SIP phone loads.

For this lab, I’ve downloaded “cmterm-7942_7962-sip.8-3-3SR2.zip”. However, since I’ve previously created a hierarchical file structure for the SCCP 7942-7962 phone loads on flash, I placed the SIP phone loads in the root of flash. Finally, since the SIP phone loads are not a TAR file, you’ll likely need to copy each file individually, rather than using the “archive tar /xtract” command.

Lab 3.1 – New York Basic CUCME Setup Tasks
1. Setup the CUCME System Parameters on the New York router. You may not use the CUCME setup utility or any sort of auto registration process.
2. Configure the New York Phones to update their SIP phone loads.
3. Configure the phone extensions based on the diagram depicted in CUCME-CUE Labs – Background.
4. Ari Gold is a huge fan of the 1986 New York Mets. Therefore, create a custom ringtone for New York based on the "hit" 1986 song, “Lets Go Mets Go”. (ah, the 1980s... - LOL)
5. Each phone and should also be able to customize their ringtones beyond the default chirp ringtone.
6. The CUCME service should be configure to support the appropriate localization, time-zone, a 12 hour time format, and a Month-Day-Year format.
7. Create an appropriate E.164 dial-pattern.
8. Anticipate the need to transfer calls between Baltimore and New York in the future.
9. Enable the wideband codec by default for all phones.
10. Create the appropriate GUI Administrator parameters
11. Create GUI access for Fuzzy Dunlop with parameters separate from the Administrator.
12. Each user’s phone should also display his/her name and full E.164 number.
13. Eliminate the possibility of “clipping” of voice between pauses in conversations.

Lab 3.2 – New York Basic CUCME Setup Verification
In my opinion, the configuration of CUCME for SIP phones is more complicated than a SCCP setup. Furthermore, a SIP CUCME configuration has far fewer features and functionality than a SCCP configuration. However, SIP is the “emerging” UC standard. And CUCME 7.1, which I was able to beta test at the Cisco Partner UCVT in October 2008, should incorporate some new SIP features to bring closer feature parity with SCCP phones & features.

Before I discuss the specific tasks, an additional note…. Unlike SCCP phones, SIP phones do not maintain a keepalive with CUCME. Additionally, you have to reissue the “create profile” command under voice register global every time you make a change to either the phone (voice register pool), the dial number (voice register dn), and/or under the voice global register. Therefore, my recommendation is while you make your initial SIP configurations:

- Either shut down the voice vlan and/or remove the phones from the CUCME switch.
- Configure all of your SIP parameters.
- Issue the necessary “upgrade” and “create profile” commands under voice register global.
- Reattach your phones and/or turn up your voice vlan.
- Reset and/or troubleshoot phones as necessary.

1. Updating the SIP Phone loads was the first challenge, thanks to inaccurate information in some Cisco documentation. First, the correct configuration to update the SIP phone images is below.

tftp-server flash:apps42.8-3-3ES2.sbn
tftp-server flash:cnu42.8-3-3ES2.sbn
tftp-server flash:cvm42sip.8-3-3ES2.sbn
tftp-server flash:dsp42.8-3-3ES2.sbn
tftp-server flash:jar42sip.8-3-3ES2.sbn
tftp-server flash:SIP42.8-3-3SR2S.loads
tftp-server flash:term42.default.loads
tftp-server flash:term62.default.loads
!
voice register global
mode cme
load 7962 SIP42.8-3-3SR2S
load 7942 SIP42.8-3-3SR2S
upgrade
create profile

Now, I’ll point out the inaccuracy, also keeping in mind that I configured much of the other SIP related parameters when I encountered this issue…

The Cisco Unified CME 7.0(1) Supported Firmware, Platforms, Memory, and Voice Products contains “Important Information about Configuring Cisco Unified IP Phone Support”, specifically, the following:

“In Cisco Unified CME 7.0(1) and later versions, use the complete filename, including the file suffix, when you configure the load command for phone firmware versions later than version 8-2-2 for all phone types.”

So, initially in the above load commands, I included the .loads suffix. However, when the phone attempted to download the SIP loads, they encountered an error attempting to load SIP42.8-3-3SR2S.loads.

After a bit of troubleshooting, I decided to remove the .loads suffix, re-issue the upgrade and create profile, and reset the phones. Unfortunately, while the phones did obtain their proper DHCP, TFTP, and CUCME information from the router, they still would not upgrade their SCCP to SIP load. After some additionally frustrating troubleshooting, I decided to reboot the router. Once the router reloaded and phone obtained the proper DHCP information, they were able to update their phone loads and register accordingly.

2. There are a few steps involved in creating a custom ringtone that is not include by default in the ringtone.tar. The first step was to find a .wav recording to “Lets Go Mets Go”, which surprisingly wasn’t too difficult. The second step is to convert the .wav to a PCM .raw format and upload it to the ringtones directory in the router. Next, you have to modify both the DistinctiveRingList.xml and the RingList.xml files. Finally, you have to remove the existing versions of these on the router, and upload these modified versions. You can find a very good posting on the proper procedures here.

3. In a nutshell, configuring CUCME to support SIP involves the following steps:

- Enabling SIP Calls in Your VoIP Network
- SIP: Setting Up Cisco Unified CME
- SIP: Creating Directory Numbers
- SIP: Assigning Directory Numbers to Phones

4. Configuring the SIP phones to uses the G.722 Wideband Codec can be a bit confusing, since it isn't very well documented on CCO in one place. Essentially, there are two components. First, you have to modify the global codec under telephony-service, the same as it was done in Baltimore. Second, you need to configure each phone (voice register pool) to use G.722 as the default codec (SIP phones default to G.729).

5. The following show commands are helpful in verifying and troubleshooting your configuration:

show voice register global (verifies the voice register global parameters)
show voice register tftp-bind (verifies the creation of the voice profiles and their tftp binding)
show voice register statistics (verifies SIP phone registration with CUCME)

6. Below is the output of the appropriate router configuration, truncated for brevity.

NewYork#sh run
!
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
sip
registrar server expires max 600 min 300
!
!
voice register global
mode cme
source-address 10.1.22.1 port 5060
load 7962 SIP42.8-3-3SR2S
load 7942 SIP42.8-3-3SR2S
timezone 12
dialplan-pattern 1 2125552... extension-length 4
create profile sync 000371836563317A
ntp-server 10.1.1.4 mode directedbroadcast
!
voice register dn 1
number 2001
name Tom Seaver
label Tom Seaver
!
voice register dn 2
number 2002
name David Wright
label David Wright
!
voice register dn 3
number 2003
name Eli Manning
label Eli Manning
!
voice register dn 4
number 2004
name Brandon Jacobs
label Brandon Jacobs
!
voice register dn 5
number 2005
name Ari Gold
label Ari Gold
!
voice register pool 1
id mac 0021.D8BA.2373
type 7942
number 1 dn 1
dtmf-relay sip-notify
description 212-555-2001
codec g722-64
no vad
!
voice register pool 2
id mac 0212.0555.2002
type 7942
number 1 dn 2
dtmf-relay sip-notify
description 212-555-2002
codec g722-64
no vad
!
voice register pool 3
id mac 0212.0555.2003
type 7942
number 1 dn 3
dtmf-relay sip-notify
description 212-555-2003
codec g722-64
no vad
!
voice register pool 4
id mac 0212.0555.2004
type 7942
number 1 dn 4
dtmf-relay sip-notify
description 212-555-2004
codec g722-64
no vad
!
voice register pool 5
id mac 0021.D8B9.BC72
type 7962
number 1 dn 5
dtmf-relay sip-notify
description 212-555-2005
codec g722-64
no vad
!
telephony-service
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
system message Ballplayers, LLC New York
max-conferences 8 gain -6
web admin system name Cisco123 password Cisco123
web admin customer name Fuzzy password Dunlop
transfer-system full-consult
transfer-pattern 1...
transfer-pattern 2...
create cnf-files version-stamp 7960 Jan 07 2009 16:21:39
!

CUCME-CUE Lab 3 Wrap-up
As I stated earlier, configuring CUCME for SIP is more complicated, with comparatively fewer features. The feature differences will become more apparent in future labs, although CUCME 7.1 may address some of the SIP phone feature loss. For example, you cannot configure a System Message on SIP phones, and the CUCME GUI is basically worthless for SIP phones.

Editorially, I found it confusing to have to configure some parameters under “voice register global” and others under “telephony-service” in order to have a working SIP CUCME router. There is probably some programming reason in IOS for having to work under two different areas, but it certainly would be nice to have all the parameters configured under one global section.

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.

UC500.com: Cisco Communication Manager Express, UC520, SMB VOIP reference and community. Creating Custom Ring Tones for CallManager Express. Available online.