Archive

Posts Tagged ‘CUE’

No Voicemailbox association on CUE

January 17, 2013 2 comments

I’ve recently encountered an issue on CUE as it pertains to user mailboxes. Whenever someone tried to leave a message for a particular user, they were told by the AutoAttendant that there was no mailbox associated with the user’s extension. Before we go any further, let’s get some more information on how the environment is currently setup.

CME is configured to use SIP Trunking  back to the ISP in order to make calls. Each user has Direct Inward Dial (DID) extensions. Here’s a sample config of what the Ephone-DN on CME and the Voicemailbox on CUE looks like.

CME Ephone-DN config for User
ephone-dn 1 dual-line
  number 7890 secondary 1234567890 no-reg both
  label John
  description 123-456-7890
  name John Doe
  call-forward busy 1000
  call-forward noan 1000 timeout 20
CUE config for User
username John create


username John phonenumber “7890”


voicemail mailbox owner “John” size 1772
description “John mailbox”
end mailbox


voicemail notification owner John enable

Reviewing the configuration above you would think that your voicemail mailbox configuration for this user is correct, right? Wrong! If you placed a call to this user from an internal phone to their primary extension of 1234, you’d be able to leave a message however, if an external user placed a call to the DID number of 1234567890, they would be told that there is no mailbox associated with the number. The reason for this, is that when an external user places a call to the DID number, the AutoAttendant forwards the entire DID number and tries to find a mailbox associated with this number. Because the primary number associated with the mailbox is 7890 and not 1234567890, the mailbox lookup fails. To correct this issue we would need to change the phone number associated with the mailbox in CUE to the DID number of 1234567890.

username John phonenumber “1234567890”

I was able to verify this by enabling call forwarding to voicemail on the user’s phone, enabling the “debug voice dialpeer” command and then placing a call to that user’s DID number.

Advertisements
Categories: Cisco Tags: , , , , ,

Cisco Unity Express and Loopback0

August 9, 2011 7 comments

I’m currently working on a VOIP project consisting of a pair of UC560s and some SPA508G Phones. Configuration for the project is pretty straight forward as no  fancy or complex translation rules need to be created. The client is basically replacing their current antique Nortel system with a modern Cisco solution.

The steps required for me to get the system up to a basic state to perform tests were as follows:

  1. Configure a DHCP Pool for all IP Phones.
  2. Copy tftp files for the SPA508G phones to flash.
  3. Configured UC560 to serve up the files so that the phones are able to download their configuration.
  4. Basic ephone-dn and ephone configurations to test phones.
  5. Create and assign IP to loopback interface.
  6. Configure Service-Engine interface to use loopback interface
  7. Configure IP address and default-gateway of CUE
  8. Test connectivity to CUE by pinging interface and also establishing connection.
  9. Configure user accounts in CUE and assign Voicemail mailboxes to users.
  10. Perform Tests.

As you can see from the list, this truly is a simple deploy.

All configurations were proceeding just fine until I arrived at step 8. At this stage I should be able to both establish a connection to CUE and also receive replies from pings. However this wasn’t so. For some reason all my ping tests were failing. I checked, rechecked, checked again, then checked again to make sure my configs were correct.

Here’s an example of what the configuration would look like.

!Loopback interface created to use with our Service Engine interface. 
(Cisco's recommended way of configuring it)

interface Loopback0
ip address 192.168.1.1 255.255.255.0

!Service Engine interface used to communicate with the Cisco Unity Express.

interface Integrated-Service-Engine0/0
 description Loopback interface used to manage integrated application module
 ip unnumbered Loopback0
 service-module ip address 192.168.1.2 255.255.255.0
 service-module ip default-gateway 192.168.1.1

Did I miss anything? From the configuration we see that the IP Address of the CUE is 192.168.1.2 and the IP address used to communicate with the CUE is 192.168.1.1 which is the IP of the Loopback interface.

For reasons unknowing to me, this configuration was not working. I was able to successfully establish a session to the CUE, logged in using the same credentials used to login to the UC560 and I was able to proceed with further configurations tasks. I was able to create user accounts, assign them mailboxes, assign Voicemail number so that the application is activated whenever that number is dialed etc. Unfortunately ping tests were still failing and as such when I made a test call to Voicemail, it did not work. There is one step I forgot to include in the list above, and that was to create a dial-peer so that whenever users dialed the Voicemail number it would use that particular dial-peer to transfer the call to the correct destination thereby activating the Voicemail system. This was also completed and the configuration for this can be seen below.

dial-peer voice 2 voip
destination-pattern 600
session protocol sipv2
session target ipv4:192.168.1.2
dtmf-relay sip-notify
codec g711ulaw
no vad

I spent hours researching Cisco’s documentation and reading through different forums. Eventually I saw a user on IPexpert’s OSL was having the same issue. He was able to access and ping CUE whenever he used a physical interface or a SVI as opposed to using a Loopback interface. I decided to test this out for myself by using an SVI, Vlan1 and changed the configuration on the Service Engine to use Vlan1 instead of Loopback0. Of course this worked flawlessly! I was able to ping the CUE IP which enabled me to proceed with my further configuration and testing.

I found the whole thing really interesting, as no where on Cisco’s site mentioned there being instances where the Loopback interface wouldn’t work. Have any of you VOICE folks out there experienced this problem before? Did I miss something with my configs? And please don’t tell me that I needed to reboot/reload/reset CUE as I did this so many times till at one point I had to do a complete factory reset to get basic communication again. 🙂