Transfer Directly To VM - CME and CUE

Unanswered Question

I'm attempting to setup my CME to allow an attendant to directly transfer calls to VM. I followed Cisco's document ( ) exactly, but something is going wrong. I added the following lines to my config:

ephone-dn 22

number 459..

description DN to transfer directly to CUE

call-forward all 7000

and the dial-peer to the VM extension already existed as it needed to. Every user has the E.164 defined as 459xx [where xx is the last two numbers of their extension]. What debug logs could I provide to the forum so that you might help me figure out what is wrong?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Brandon Buffin Tue, 12/18/2007 - 13:27

Do you get anything when you dial 459XX? Turn on "debug voip dialpeer", dial the number and paste the results here.


From what I can tell, that's a different issue. That bug deals with the case of Call Forward No Answer when forwarding to the VM pilot, but being a complete novice at this stuff, I may be incorrect about that. I don't think I have the ability to configure this at this point in time. I'll keep reading material and see what I can find.

One last question, what is the best way to learn to understand debug logs and know which debug logs should be viewed to troubleshoot a problem?


rob.huffman Tue, 12/18/2007 - 16:38

Hi Paul,

Did you configure the E.164 number in CUE?

Configure the chosen transfer extension ("459..") as an E.164 address in Cisco Unity Express with the CLI.

Note: In order to use the GUI to define the E.164 address click here.

As mentioned earlier, in Cisco Unity Express you must define these "459.." extensions as E.164 addresses. Use the CLI in order to accomplish this. In order to see a user list, issue the show users command:

vnt-nm-Cisco Unity Express> show users




marschneIn order to get more details about a particular user, issue the show user detail username command:

vnt-nm-Cisco Unity Express> show user detail username marschne

Full Name: marschne

First Name: Markus

Last Name: Schneider

Nickname: marschne

Phone: 201


Language: en_USConfigure the E.164 addresses.

In order to configure an E.164 address, you must enter the configuration mode and issue the user phonenumberE164 command:

vnt-nm-Cisco Unity Express> conf t

!--- Enter configuration commands, one per line. End with CNTL/Z.

vnt-nm-Cisco Unity Express(config)> user marschne phonenumberE164 3201 (45988 for you)

When finished, issue the write memory command in order to save your configuration and exit configuration mode.

Hope this helps!


davetucker Wed, 12/19/2007 - 09:38


Looks like this is the bug that was described earlier. The dialplan-pattern will try and change the calling party number to an E.164 number.

So in your case, 7000 becomes 3129487000.

There is no dial-peer associated with this number hence the fast busy signal.

You have 2 options.

1) Configure a second dial-peer to the CUE module with a destination pattern of 3129487000.

2) Avoid the use of dial-plan patterns numbering completely by using Translation Rules. I find this approach easier to manage.

Let me know how you get on.

Good Luck



OK, I can't let this die. I'm too close to getting it.

My current configuration works when calling internally and transferring, but when I call from an external line it the attendant that is transferring the call is the one who ends up in the voicemail box.

I added the following 3 lines to my configuration to get it working internally,

ephone-dn 22

number 459..

call-forward all 5994

and this is the dial-peer for 5994,

dial-peer voice 5994 voip

mailbox-selection orig-called-num

description VM Pilot

translation-profile outgoing CUE

destination-pattern 3129485994

voice-class sip outbound-proxy ipv4:

session protocol sipv2

session target ipv4:

dtmf-relay sip-notify

codec g711ulaw

no vad

davetucker Thu, 12/20/2007 - 01:21


Can you attach two debugs?

One for a working internal transfer to VM,

One for an external transfer to VM?

This should shed some light on the problem.



davetucker Thu, 12/20/2007 - 17:21


Looks like at some point the call is trying to make its way back to the originating number. To make this work you will need to prefix the CLID with the access digit for all incoming calls to the system. This has other benefits as you don't need to EditDial from the Missed/Received calls directory.

Try adding the following (or a variation of)...

voice translation-rule 9

rule 1 /\(.*\)/ /9\1/



voice translation-profile CLID

translate calling 9



dial-peer voice 1 voip

incoming called-number .


translation-profile incoming CLID

session target ipv4:




This Discussion