cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1223
Views
0
Helpful
10
Replies

CME/CUE weird voicemail problem

jelzein
Level 1
Level 1

I have completed an installation of CME 4.1 / CUE 2.3 and have everything running just the way I want it (almost) -- then I noticed all incoming voicemails that are left on a user's mailbox say they are from that same extension. For example, a caller from 111-222-3333 leaves a user at x4444. When the user checks voicemail, Unity says "new message from <user> at extension 4444. Don't know why this is happening, but probably related to how CME is transfering calls to CUE.

Any idea?

Thanks,

Jad

10 Replies 10

Rob Huffman
Hall of Fame
Hall of Fame

Hi Jad,

I beleive this only works for direct calls;

Configuring Caller ID for Incoming Messages

Cisco Unity Express supports caller ID information for incoming voice-mail messages.

When receiving an incoming voice-mail message from an external caller, the system attempts to match the associated caller ID information with an entry in the local directory. If a match is not found and the system is configured to play caller ID information, the system plays the sender's telephone number in the message envelope when the recipient listens to that message. If the system is not configured to play caller ID information, the system plays "Unknown Caller" in the message envelope.

Cisco Unity Express does not verify that the caller ID information is valid. That function is dependent on the central office (CO) and the incoming trunk setup. Additionally, the local system plays caller ID information for Cisco Unified CallManager Express or Cisco Unified CallManager extensions that are not configured in the local Cisco Unity Express directory.

***The default caller ID status is disabled. Use the GUI Defaults > Voice Mail option or the CLI command described below to enable or disable playing of caller ID information.

--------------------------------------------------------------------------------

Note An external call is any telephone number that is not listed in the Cisco Unity Express subscriber directory. Possible sources of external calls are the local telephone company, an IP telephone, or an H.323 gateway. These sources must be configured to present caller ID information to the Cisco Unity Express system.

Use the following Cisco Unity Express configuration mode command to enable the playing of caller ID information in the message envelope of incoming external calls.

voicemail callerid

The following example illustrates enabling caller ID information on local system:

se-10-0-0-0# config t

se-10-0-0-0(config)# voicemail callerid

se-10-0-0-0(config)# exit

From this doc;

http://www.cisco.com/en/US/products/sw/voicesw/ps5520/products_administration_guide_chapter09186a008067796b.html#wp1081772

Hope this helps!

Rob

Markus Schneider
Cisco Employee
Cisco Employee

Sounds like there's some translation pattern or something on CME changing the calling number. You could do a 'debug ccsip mess' and see what the calling number/from field shows up as in the INVITE message. Are you sure 4444 is simply forwarding the call to voicemail? or is it somehow answering it and then transferring the call to its own mailbox?

Thanks both for your responses. The command "voicemail callerid" is in CUE as expected.

This may be caused by the OTHER "little" problem i'm having with incoming caller id information, or lack thereof. The system doesn't disply any incoming caller id information for external calls. I've been working with the local telco to ensure they're passing it, but they insist it's my config. All incoming calls show "unknown". A debug shows blank caller and "unkown" being forwarded CUE.

I attached to config (the relevant info).

Thanks,

Jad

sorry -- the attachment.

Might want to try removing

translation-profile outgoing PSTN_CallForwarding

from the dial-peers. Doesn't seem like it should matter, but maybe something strange is going on there. Or it could have something weird to do with the 'call-forward system redirecting-expanded' configuration. Not sure what that does if there's no dialplan pattern.

I removed both of those with no change. I think i'll leave them out since they don't need to exist.

Right now i've managed to get Unity to say "Message 1 from unknown caller". This is better than stating the local extension. This was accomplished by adding an isdn map to the se0/1/0:23 interface --

"isdn map address .* plan isdn type national"

My concentration right now is trying get incoming caller id to work. I haven't had any luck with it so far. Telco swears they're passing it. Debugs show all incoming calls as unknown.

Any ideas?

Many thanks,

Jad

Have you tried some different switch types?

This link outlines some of the available options:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/multisdn.htm#xtocid126968

I'm sure that you have confirmed with the provider that yours is ni, but sometimes, depending on the personnel you talk to, they may not be fully informed.

Until you are seeing the actual Caller-ID number in the q931 debugs, it won't do much good to try and manipulate the digits

Just an idea...

Thanks for the response. I have tried several different switch types with no luck. Telco's switch is a 5e using NI configuration/compatibility...so I tried both and some others. They're side is identical to several other clients running voip, which is why they are so certain it's not their doing.

I'm wondering if I should give up and open a TAC case.

jeffhubel
Level 1
Level 1

Jad -

I just happened accross your message and I had the same problem several weeks ago. I upgraded my IOS to 12.4(11)XW2 and the problem resolved. You will notice that on your system currently, when you transfer a call, the caller ID is not passed until after the call is answered by the receiving party, whereas it is supposed to be passed when the tranferer presses "transfer" for the 2nd time. The XW2 IOS resolves this issue, which is the root of your issue.

techreg
Level 1
Level 1

I also had the same problem with 12.4(15). I removed ?calling-number local? from ?telephony-service" and that fixed it.