Unity Connection-CUCME Lab 1 – Initial Configuration

Unity Connection-CUCME Lab 1 Prerequisites

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

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

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


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

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


Lab 1.2 Unity Connection-CUCME Verification

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

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

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

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

Baltimore CUCME Router:

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

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

Baltimore EtherSwitch Service Module:

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

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

New York CUCME Router:

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

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

Los Angeles CUCME Router:

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


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

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

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

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

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

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

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

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

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

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

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

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

losangeles#ping 10.1.12.16

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

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

newyork#ping 10.1.32.20

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


Unity Connection-CUCME Lab 1 Wrap Up

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

Unity Connection-CUCME Scenario Background

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

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

The table below describes the IP Adressing & PSTN configuration.

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

Unity Connection Labs Coming!

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


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


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

CUCME-CUE Lab 10 – CUCME-CUE Misc Items

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.