cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1233
Views
0
Helpful
17
Replies

Transfer Directly To VM - CME and CUE

pkluss
Level 1
Level 1

I'm attempting to setup my CME to allow an attendant to directly transfer calls to VM. I followed Cisco's document ( http://www.cisco.com/en/US/products/sw/voicesw/ps5520/products_tech_note09186a00802ab979.shtml ) 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?

Thanks.

17 Replies 17

Brandon Buffin
VIP Alumni
VIP Alumni

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

Brandon

I hope this means something to you. Log is attached.

Thanks.

Do you hear anything when you dial 45988? Can you attach your config?

Brandon

I hear a busy signal and it shows that it is trying transfer to my own extension on the softphone. I've attached a .jpeg of what I'm describing. The config file is also attached.

<< EDIT: I forgot to attach the config. It will be the next message in the thread. >>

Thanks.

config file

config file

It looks like you're running into a known issue with CUE when using the dialplan pattern command. Take a look at the following link.

http://www.cisco.com/en/US/products/sw/voicesw/ps5520/products_field_notice09186a008023cfe2.shtml

Brandon

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?

Thanks.

Rob Huffman
Hall of Fame
Hall of Fame

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

administrator

jdoe

jsmith

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

Phone(E.164):

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!

Rob

Yes, I'd configured the E.164 number in CUE exactly as stated in this document. There must be something else tripping it up.

Paul,

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

Regards,

Dave

I don't believe I have the skill to undertake either of these options at this point. I'm reading everything I can on the subject and hopefully I'll feel comfortable attempting it on my own very soon, but for now I think it's out of my reach. Thanks for the ideas, they did spur quite a bit of reading on my end.

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:192.168.100.252

session protocol sipv2

session target ipv4:192.168.100.252

dtmf-relay sip-notify

codec g711ulaw

no vad

Paul,

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.

Regards,

Dave

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: