Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.
During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.
We apologize for the inconvenience while we perform important updates to the Community.
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:
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 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. >>
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.
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?
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
vnt-nm-Cisco Unity Express> show user detail username marschne
Full Name: marschne
First Name: Markus
Last Name: Schneider
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!
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.
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,
call-forward all 5994
and this is the dial-peer for 5994,
dial-peer voice 5994 voip
description VM Pilot
translation-profile outgoing CUE
voice-class sip outbound-proxy ipv4:192.168.100.252
session protocol sipv2
session target ipv4:192.168.100.252
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.
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:192.168.100.253