Calls going straight to voice mail

[incomminc]

I have a client with a 200 ICP running 3.1.0.22. They have a local PRI for incomming and local callin and a L/D PRI for L/D calls. They also have 10, 800 #'s. Eight of them ring into ACD paths and the other two point to their main number. The problem they are having is that a few times during the day incomming calls to the 800 #'s go straight to voicemail. The calls to the ACD paths go straight to the interflow point which is a mailbox, and the other calls go straight to the general mailbox.

ACD agents are logged in and available when this occurs.
The customer swears up and down that the recept is not putting the system in night service. Is there any way to report on when the system is put into night and back into day service? I know in the 3300 the night service switching show up in the maint logs.

The customer has also said that on two occasions users were at their desk and their message light came on. They checked their voice mail and the message was left while they were sitting there. Has anyone had any issues with the embedded voicemail doing this?

Thanks for your help



Dan Schollian

http://www.incomminc.com

 

[pandabear1]

do you have allow overflow to interflow before timeout enabled?
Also one way to confirm what the agents are saying is to look at the ACD reports.

 

[TheMitelGuy]

For the voice mail issues, callers that get to the auto attendant, can press # + EXT# and leave a message. I.e. if you dial #, the system will ask for the mailbox number, and if you enter that, you are dropped right into the users mailbox.

As for your ACD issues... are your agents in Make Busy? Your voice mail, is it set to go into day/night based on system hours (automatic) or based on system mode (manual)?

Although much more diagnostic is required here, the chance of something being buggy with the ACD components is extremely rare. The ACD code is ages old, but very good. Award winning in fact.

 

[incomminc]

I have checked with the customer and the ACD agents are not in a make busy. Also the calls that go straight to voicemail do just that. The caller goes straight to the users mailbox when calling the users DID.

I started a trap on the PRI circuit to see if the carrier is sending unusual or corrupted data. Here are a couple of weird things that showed up.

IN : 06/07/17 10:25:39 3019460882 @ 6262316321 bad allocation units :


>>> OUT: 06/07/17 10:26:12 2024526262 @ 6737385676 @ 540070
available bytes


>>>

<<< IN : 06/07/17 10:26:50 3015092175 @ 6262 @ 79309 @ 12027526161

<<<

<<< IN : 06/07/17 10:28:07 4123674945 @ 79292202022 1,1398 @ 8043

>>>

>>> OUT: 06/07/17 10:28:10 2024526262 @ 6737203 CP STAT: CP60M-OUT 23 CP60M-IN 35 [cp.cpp @ 9


<<< IN : 06/07/17 10:29:48 2024342277 @ 80210982980096262 @ 3014

I don't know if this could be causing the issue, but the carrier denies any issue on their side.

Thanks


Dan Schollian

http://www.incomminc.com

 

[pandabear1]

The caller goes straight to the users mailbox when calling the users DID".
I am confused, is the above statement correct or are they calling the ACD path?

 

[incomminc]

The problem is occurring with both users and ACD paths.

On about four or five occasions users were sitting at their desks when their message light began flashing. They checked the message, which had just arrived however their phone never rang.

The ACD agents also experienced the same problem. They were logged in and idle. The phones were not in a make busy state. All of a sudden the message waiting light for the group mailbox lights up. (the interflow for all of the groups goes to a general mailbox that appears on all of the agents phones) One of the agents checks the mailbox and a new message is in there.

They have also verified that the system was in day service when this has happened.


Dan Schollian

http://www.incomminc.com

 

[pandabear1]

can you capture the path programing info form 41 and include?

 

[pandabear1]

the traces you included, did a trouble happen at that time?
Just an idea, if you turn on smdr and have a way of capturing that and compare the data in there to the time stamp of a message that went direct to mail might give us a clue.

 

[incomminc]

I am going out to the site tomorrow and will print out one of the path's programming.


Dan Schollian

http://www.incomminc.com

 

[MitelInMyBlood]

Dunno how this works on a 200, but I would think if an ACD AGENT is logged into the queue and actively on an ACD call that a concurrent call to his DID number that goes straight to his voice mail would be a normal and expected event. Are you sure that's not what's happening?

Also could it possibly be a help desk type operation where some of the individual agents' prime (DID) numbers have either been given out or discovered by callers? Rather than call the help desk they may be calling the agent direct. If the agent is busy, those calls are going to go to VM.

We had a similar problem with an ACD2000 system on an old SG. To discourage this we first changed all the DID numbers of the agents and programmed the new numbers as private numbers. We also gave the logged-in agents a different COS than a logged out user. The "user" when logged out could forward his phone BZ/NA only (could not user-fwd always) and could not put his phone in DND. When logged in the agent took on a special agent-only COS and lost all of his fwd'g privledges but gained the ability to use all the Agent privledges (MB, DND, etc) but no user fwd'g.

Likely a site visit will make it a little clearer as to what's actually happening.

 

[pandabear1]

Calls would go to voicemail if on the phone but as reported the agents were sitting at there desks and not on the phone apparently. Confusing, I think there is an interflow programing problem. I would hope if the smdr can be captured and compared to the time stamp of the voicemail some info can be derived from that.
Of course the smdr if capturing now would have to capture all i/c info.
This is an interesting challenge.

 

[dnsincomminc]

There are non-ACD users that experiencing the problem. I may have not made that clear originally.

The first issue involves not ACD calls. Standard user is sitting in their office and the phone is idle. Message light comes on and there is a new message in their mailbox. However their phone never rang. This has happened to two or three different users on different days, at different times, and by different incoming callers. It has also happened to one user three times. It just so happens she is the vice president of the company and complains louder each time it happens.

The second issue involves ACD agents, logged in and idle. A call comes into the group and goes straight to the interflow mailbox. This has happened on four or five occasions in the past three weeks.

I am curious in errant data may be being sent from the carrier confusing the switch into sending the call straight to the mailbox.

I will go through the entire PRI trap and turn on smdr and get an smdr trap tomorrow.

Thanks


Dan Schollian

http://www.incomminc.com

 

[TheMitelGuy]

Pls post form 19 (all of it). Thanks. Also, are you using XXXX to XXXX matching (i.e. DID to DN matching) or are you using the DID Reroute Table?

 

[pandabear1]

the issue of the lamps coming on when the person is sitting there idle is interesting as I am having at one of my sites the lite coming on three days after the message was dumped into the mailbox or in other words late message waiting notification. Release 3.0.2.5

 

[TheMitelGuy]

I have never had a problem with message waiting lamps on Mitel (using Mitel IP-PBX and EMEM).

INCOMMIC: Pls post form 19 and we will take a peak.

Also, are you using a NSU or MMC T1?

 

[jsaxe]

I once experienced this problem on a newly installed SX2000 which had been in service for a few weeks, turned out to be due to the installer forgetting to enable programmed reboots.

jsaxe

Mundus Vult Decipi

 

[TheMitelGuy]

Programmed reboots is not a requirement for either ICP. Both system should work without rebooting, period. I hate it when someone tells me "it needs to be rebooted." "NO, it needs to just work properly.

 

[kwbMitel]

I would check the following.

Make sure System Option for cancel message waiting 24hr is turned off.

COS option 604 for the voicemail ports should be off (contrary to manual)

In form 9 for the voicemail ports expand set and set line preference to manual.

Is the time on the voicemail synchronized?

Is it possible the calls are transfered (from other users or VM)?

If you have access to SMDR data (prairiefyre?) it would be useful.

Do they have DND keys or CFWD All on their phones?

How about headsets, is it possible they're not on the phone but actually off hook unintentionally?

Assume nothing, take the info from the customer for what it is worth, a starting point.

 

[MitelInMyBlood]

We used to get frequent complaints of delayed MWI and MWI lit but no messages in the MB. After reviewing the sequence of events I discovered the seating assignment at the site was fairly dynamic and the admin was in the habit of performing frequent early morning (7AM) move/swaps without refreshing the MWI indicators afterwards. Of course MWI status does not follow with a M/S so VM thought the lamp was already on when it wasn't (or vice-versa), hence on subsequent messages it made no attempt to refresh until the flwg morning 5AM, then the client comes in at 8A and finds several msgs from the previous day. (This was on a 2K with Octel Overture 350 VM)

 

[tundranugget]

MitelInMyBlood wrote:

"We used to get frequent complaints of delayed MWI and MWI lit but no messages in the MB. After reviewing the sequence of events I discovered the seating assignment at the site was fairly dynamic and the admin was in the habit of performing frequent early morning (7AM) move/swaps without refreshing the MWI indicators afterwards. Of course MWI status does not follow with a M/S so VM thought the lamp was already on when it wasn't (or vice-versa), hence on subsequent messages it made no attempt to refresh until the flwg morning 5AM, then the client comes in at 8A and finds several msgs from the previous day. (This was on a 2K with Octel Overture 350 VM)"

This is the problem we are having right now, most likely caused by M/S with MWI on. We have tried everything to clear the MWI indicators. How can we stop the MW light flashing on the 4025s? We have SX2000 and NuPoint Messenger (unsure of versions).