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

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


Lab 6.1 – Unity Connection & Los Angeles CUCME Integration Tasks

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

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

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

4. Use extension 2999 as the voicemail pilot.

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

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

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

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


Lab 6.2 – Unity Connection & Los Angeles CUCME Integration Verification

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

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

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

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

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



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

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

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

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

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

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

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

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