12-18-2007 12:48 PM - edited 03-15-2019 07:51 AM
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.
12-18-2007 01:27 PM
Do you get anything when you dial 459XX? Turn on "debug voip dialpeer", dial the number and paste the results here.
Brandon
12-18-2007 01:37 PM
12-18-2007 01:44 PM
Do you hear anything when you dial 45988? Can you attach your config?
Brandon
12-18-2007 01:59 PM
12-18-2007 02:01 PM
12-18-2007 02:18 PM
config file
12-19-2007 08:22 AM
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
12-19-2007 08:51 AM
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.
12-18-2007 04:38 PM
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
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
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
12-19-2007 07:31 AM
Yes, I'd configured the E.164 number in CUE exactly as stated in this document. There must be something else tripping it up.
12-19-2007 09:38 AM
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
12-19-2007 12:50 PM
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.
12-19-2007 01:09 PM
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
12-20-2007 01:21 AM
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
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: