Solved: Re: Cannot Retrieve Unity Connection Voicemail Messages - Page 3

rferriolo · ‎11-07-2013

Hi All:

When I leave a voicemail message on a 7962 phone, there is an MWI and an Envelope icon in the upper right corner of the phone display, however when I push the Messages button, Unity asks to spell the Last and First name then press # instead of asking for a password to retrieve the message. I cannot find the missing configuration to allow message retrieval.

Any assistance would be greatly appreciatedl

thanks,

Ron

rferriolo · ‎11-10-2013

Hi Carlo:

I created the new voicemail profile and added 8888 in the mask. When I disabled the original voicemail profile, it rang the phone then I received a fast busy when it attempted to go to voicemail. When I had both profiles assiciated to the DN, It reverted to the original issue.

I have to find a way to get the Remote Port Status Monitor working..

Thanks,

Carlo Poggiarelli · ‎11-10-2013

Hi Ron.
What do you mean with "both profiles associated"?
On DN configuration page, you can associate only one voicemail profile.
Please let me know.

Regards

Carlo

Sent from Cisco Technical Support iPhone App

Please rate all helpful posts "The more you help the more you learn"

rferriolo · ‎11-10-2013

Hi Carlo:

OK, so I got the DN of the phone associated to the new profile. Please see the following:

==================================================================================

WITH NEW TEST PROFILE AND MASK 8888 ASSOCIATED TO THE DN THAT CALLED THE VOICEMAIL PILOT 1850

PRESSED THE MESSAGE BUTTON

09:41:33, New Call, CalledId=1850, RedirectingId=, Origin=16, Reason=1, CallGuid=090DB89AE3E345FEBBD3868842152E41, CallerName=Ben Linus, LastRedirectingId=, LastRedirectingReason=1024, PortDisplayName=PhoneSystem-1-001,[Origin=Unknown],[Reason=Direct]

09:41:33, AD

09:41:33, Entering Name Lookup Handler: System Directory Handler

09:41:33, State - AD.cde!TurnOffNameAdded

09:41:33, Event is [NULL]

09:41:33, State - AD.cde!AddrSearcher

09:41:33, -->ADAddrSearchConv

09:41:33, State - ADAddrSearchConv.cde!PlayAllNames

09:41:33, Event is [NULL]

09:41:33, State - ADAddrSearchConv.cde!AskForInput

PRESSED THE * BUTTON AFTER MESSAGE BEGINS PLAYING

09:41:43, Event is [TrueEvent]

09:41:43, State - ADAddrSearchConv.cde!EvalInput

09:41:43, Event is [TTStarEvent]

09:41:43, <--ADAddrSearchConv

09:41:43, Event is [TTStarEvent]

09:41:43, State - AD.cde!RouteDbLCall

09:41:43, Event is [NULL]

09:41:43, PHTransfer

09:41:43, State - PHTransfer.cde!LoadInfo

09:41:43, Event is [TrueEvent]

09:41:43, PHGreeting

09:41:43, State - PHGreeting.cde!PlayGreeting

09:41:43, Call answered if needed

09:41:43, Playing greeting for Call Handler: Opening Greeting

09:41:49, DTMF received [2]

09:41:53, DTMF added [001]

09:41:53, Event is [NULL]

09:41:53, PHTransfer

09:41:53, State - PHTransfer.cde!LoadInfo

09:41:53, Event is [TrueEvent]

09:41:53, PHGreeting

09:41:53, State - PHGreeting.cde!PlayGreeting

09:41:53, Call answered if needed

09:41:53, Playing greeting for Subscriber: Ben Linus

09:41:57, Event is [HangupEvent]

09:41:57, State - PHGreeting.cde!DoHangup

09:41:57, Event is [HangupEvent]

09:41:57, Idle

davrojas · ‎11-10-2013

Hello Ron,

Based on the Remote Port Status Monitor that you provided it looks like the call is being forwarded to the connection ports rather than calling them directly therefore the Forward Routing Rules would apply instead.

Normal behaviour seen in the Remote Port Status Monitor when pressing the message button or dialing it's VM pilot equivalent should not show a redirecting or last redirecting id as in Rob's output:

07:48:52, New Call, CalledId=8700, RedirectingId=, Origin=16, Reason=1, CallGuid=9EDBB075B3C54C419BDC523736238400, CallerName=Rob Huffman, LastRedirectingId=,

If your CSS (Calling Search Spaces) allows from your phone to dial the extension from the voice mail ports directly i would try that to rule out any misbehaviour on how the call reaches the vm port and to confirm output on the rPSM.

Also i see that the greeting is played for the user named Bob, so to built up the story a little bit more it would be interesting to know how is it that we are finally reaching that user. Checking under the call handlers> edit> greetings and see which one (if any) is configured on the After Greeting to send the call to this user and rule out if it is the Opening Greeting (which is configured on the Routing Rules) or another handler and then keep troubleshooting from that perspective.

Hope it makes sense : )

-Dav

rferriolo · ‎11-11-2013

Hi Carlo:

OK, so I got the DN of the phone associated to the new profile. Please see the following:

==================================================================================

WITH NEW TEST PROFILE AND MASK 8888 ASSOCIATED TO THE DN THAT CALLED THE VOICEMAIL PILOT 1850

There is no ATTEMPT SIGN-IN.....

PRESSED THE MESSAGE BUTTON

09:41:33, New Call, CalledId=1850, RedirectingId=, Origin=16, Reason=1, CallGuid=090DB89AE3E345FEBBD3868842152E41, CallerName=Ben Linus, LastRedirectingId=, LastRedirectingReason=1024, PortDisplayName=PhoneSystem-1-001,[Origin=Unknown],[Reason=Direct]

09:41:33, AD

09:41:33, Entering Name Lookup Handler: System Directory Handler

09:41:33, State - AD.cde!TurnOffNameAdded

09:41:33, Event is [NULL]

09:41:33, State - AD.cde!AddrSearcher

09:41:33, -->ADAddrSearchConv

09:41:33, State - ADAddrSearchConv.cde!PlayAllNames

09:41:33, Event is [NULL]

09:41:33, State - ADAddrSearchConv.cde!AskForInput

PRESSED THE * BUTTON AFTER MESSAGE BEGINS PLAYING

09:41:43, Event is [TrueEvent]

09:41:43, State - ADAddrSearchConv.cde!EvalInput

09:41:43, Event is [TTStarEvent]

09:41:43, <--ADAddrSearchConv

09:41:43, Event is [TTStarEvent]

09:41:43, State - AD.cde!RouteDbLCall

09:41:43, Event is [NULL]

09:41:43, PHTransfer

09:41:43, State - PHTransfer.cde!LoadInfo

09:41:43, Event is [TrueEvent]

09:41:43, PHGreeting

09:41:43, State - PHGreeting.cde!PlayGreeting

09:41:43, Call answered if needed

09:41:43, Playing greeting for Call Handler: Opening Greeting

09:41:49, DTMF received [2]

09:41:53, DTMF added [001]

09:41:53, Event is [NULL]

09:41:53, PHTransfer

09:41:53, State - PHTransfer.cde!LoadInfo

09:41:53, Event is [TrueEvent]

09:41:53, PHGreeting

09:41:53, State - PHGreeting.cde!PlayGreeting

09:41:53, Call answered if needed

09:41:53, Playing greeting for Subscriber: Ben Linus

09:41:57, Event is [HangupEvent]

09:41:57, State - PHGreeting.cde!DoHangup

09:41:57, Event is [HangupEvent]

09:41:57, Idle

davrojas · ‎11-12-2013

Good Morning Ron,

Based on that rPSM output it's clearly going to the System Directory Handler, it looks as if there was a Direct Routing Rule taking precedence over 1. Attempt Sign in and 2. Opening Greeting.

Post a screen shot with the list of Direct Routing Rules you have, if there is an additional rule that is first in the order even though 'not being in use' this will match all Direct calls mirroring the behaviour you have, because it works in a Top Down order. Below is an example of the issue:

-Dave

rferriolo · ‎11-12-2013

Hi David:

Please see below. VIP Client is listed before Attempt Sign In. When I disabled VIP Client (Inactive), everything worked. Now it immediately asks for the PIN. I didn't know these Routing Rules worked Top Down. Also, I don't know what VIP Client is. I can't find it anywhere on the internet. You can also see the side-by-side comparison between the two Direct Routing Rules Attempt Sign In & VIP Client (One Attempts Sign In and the other Attemps Forward).

Great job. This was a pain in the neck.

Thank you David and thank you to everyone who contributed to the isolation of this issue especially all of the hard work from Carlo... You guys are the best...

Ron