Wired Intelligent Edge

Has anyone had an issue with users not being able to access VM and then the ports locking up with the users extension that tried to access thier Voice Mail? I have 2 systems out of 6 at the same district doing that. We have to re-boot the software to release the ports. This problem occured at 6.0.53 and continued to 6.5.18. I have isolated the system to just a stand alone switch the NBX and a single phone with the same results. Any suggestions?

Sometimes Analog lines will not hang up and cause the vmail port to stay online . Also , IMAP can cause a similar issue whereby it tries to use a vmail port and send msg's via smtp . Try checking this to see if they may be related . Check Offsite Notification as well as vpim or any other voicemail app that you may be using .

I have not heard of any voicemail issues for quite a while as to ports locking up . If you cnanot find it I would suggest opening up a case or put some more info in here and we can try and assist .

Thank you for answering my post. We are not using IMAP or EMailing messages. The ports are locking up when the users are checking thier VoiceMails. Once they get logged into thier box there is only dead air and the system does not acknowledge any buttons pressed or disconnect from the VoiceMail when the user hangs up. The ports show inuse with the users extension when checked. I can not reset the ports with the web interface and have to re-boot the software to get the ports to release.

How many users ?

What voicemail options are being used :

Offsite Notification ?

voicemail only ?

Did you change the codecs in 6.5 ?

6.5 nip mode uses adpcm and in sip it uses either G711 or G729

Anything else ?



You may need to preform a network trace and open a case up as we need to see the very first event that starts this issue . I know of no open voicemail lock up bugs . Plus we may need more logging as well so quickest route is to open up a case .

This message was edited by merlin on 6-22-09 @ 1:14 PM

Thank you for the feedback. We currently have 50 users on the system. We are running 6.5.18 and just upgraded from 6.0.63. The issue was occuring in 6.0.63 as well as 6.5.18. We are not running in sip mode and the codac is at the default setting for normal system operation. The customer is not using off site notification. The voice mail is being used in its very basic function. This system is installed in a school and is part of a district that has 4 other systems deployed at other schools and the district office. Thank you

I'm having the same problem.

I'm using 6.5.18 and I'm upgrading to 6.5.20 right now to see if it fix it.



Tkz!

Has anyone came across the fix for this issue? I am not finding much information in the knowledgebase except for this thread. I have a V3000 running R6.0.63 and the Voicemail ports are getting "hung". Sometimes you can just check the port and click "reset", but on other occasions you have to reboot the entire system in order to free them up.

Sounds like the exact same issues I was having. We had it happen at 2 locations. We belive they were network related both systems were on the same WAN. When we used a true layer 3 switch the issues went away. I got no real solutions from 3COM.

To me , this is a new issue that I have not heard about . If you open a case , then we can resolve by getting some details . Something does not sound right as the true layer 3 switch resolves this issue ? Something else may be going on , ie , set up on the switch , network etc as you mention .....

DO NOT run R6.5.18 , as R6.5.22 is now out replacing that version . If this occurred in R6.0.63 code then I would suggest a case and maybe some traces and logs to see if we can find out whats happening .

This message was edited by merlin on 10-28-09 @ 6:58 AM

Unfortunately opening a case with 3COM is not an option as that requires the customer to have a maintenance contract and I'm not sure if you are aware of this, but 3COM has recently increased their price for Partner Express by 300%. We are trying to work something out now, but until we do the contracts are expired or expiring...I was hoping that someone here may have been aware of a patch of some sort or know the cause behind it.



The "In Use (Seconds)" is showing around 136,000 on one of them, 97,000 on another, 36,000, and lastly unlucky #13,000. It kind of appears that once one goes out, the others are soon to follow. A reset of the port or a reboot of the system always resolves the issue. It only happens every couple months so it's not a huge inconvenience, but nevertheless something we'd like to get resolved.



Thanks for the comments and if anyone comes across a solution for someone with a similar issue to this one that does have a maintenance contract with 3COM, I would be interested in knowing what the solution is or cause behind it.

keym00, I see in the 6.5.18 release notes "VM port lockup. users cannot access mailboxes" and is fixed in 6.5.18. you should upgrade to 6.5.22 and see if that fixes your issue. I also see that someone has a similar problem and is not fixed in 6.5.18 but it may be same symptom, different root cause.

I was not aware of the increae in contracts . I will post your question internally and see if I can get another answer for you ....

From one of our other folks :



If you can see this info from the voicemail ports access info screen , What is the last thing the user does when the system hangs the ports? Since the port shows the user who was accessing it when it hung, they should be able to say exactly what they were doing, and how it hung on them, unless they can say that they exited normally which could also be helpful. Is it always the same few users locking the ports? Maybe some of them are trying to forward a corrupt message - I know we had an issue where acting on a voicemail message that was corrupted, or had an invalid caller ID because it came from a Cisco router line into the NBX caused the VM to lock when the user listened to the message - one port at a time. This way find out if they were listening to a message when it hung, and see if you can re-create - if after the system is rebooted they try to listen to that same message again, etc

Thank you for the continued support on this. Unfortunately I will need to wait till the problem happens again, but the system does show the user who accessed the port last .. thus I should be able to ask them what they did last. I do remember that the receptionist appears to show up quite often. She may be able to provide more ensite as to what she was doing at the time as normally she is the one to report the problem.



Thank you again for the troubleshooting steps, I'll definitely report back after gathering some more information.

Will do ...



Good Luck !

Yes you are 1000% correct. I sell 4 manufactures equipment and only have to pay 3COM to support their equipment or take a re-qualification exams ever year or two. When we started selling and installing 3COM this was not an issue, I had support and free re-cert exams. But I digress... We did up grade to 6.5.18 and despite the notes it DID NOT resolve our issue as noted in my 6-19-09 post. The resolution was installing a 5000 series switch. That was the last thing we did. One thing that does sound different is that there were 4 different users that seem to always be locking up the VM ports at each site, at first; I thought that it must be something that they were doing? But then I decided that there were to many of them doing it and started looking at the network. That is where we found the problem, not sure what it was, becouse we diden't have a service contract for the customer I could not open a case.

The problem has returned sooner than expected and I have spoken to the individuals who were shown last accessing the port at the time of the "hang". Every user reported that they noticed nothing out of the ordinary when checking messages and no said that they were forwarding messages.



However, it appears as if the phones are also getting hung the same day as the voicemail ports. The receptionist explained to me that she would be on a phone call and then all of a sudden neither party could hear each other. She would hang up, but the phone would still act as if it was still on a call (the timer was still counting up she said). She stated that she has to unplug the phone and then re-plug it back up in order to get it working again. She had to do this about 2-3 times on the day the ports got hung.



It does sound somewhat feasible that a switching problem could be occurring due to the fact that the phones appear to be losing communication with the NBX. I have asked that the receptionist contact us the next time the phones lock up so that I can check the status of the voicemail ports. I did find this interesting and relevant to the problem though.



I was also going to contact the Director of Technology and see about putting the NBX in a different switch just to see if that makes a difference as that appears to be the resolution for EDY..



If this new information triggers any other thoughts from anyone, please let me know.

I just wanted to make mention, as we had a customer who was experiencing voicemail port lockups, they were running R6.5.18 and in SIP mode.  They experienced the anomoly of calls transferred through Auto Attendant, to an extension, then forward-no-answer for that extension SHOULD have gone to the extension's mailbox, but did not, because of the bug.

Well, in testing, I tried 3 times in a row, at night,  to dial this one user's extension from Auto Attendant, and experienced the failed FNA to voicemail; then next morning checked the VM Status, and it showed THAT USER locked up 3 of the 4 VM ports, for x thousands of seconds.  He wasn't even at his desk, it was just that his extension was involved in the (failed) FNA to VM; so it isn't always what the 'user' did last to lock up the ports, but sometimes what was done 'to' or 'involving' the user's extension.

We now have upgraded them to R6.5.22, and now calls through Auto Attendant, DO forward-no-answer to users' mailboxes.

Everyone should be running at least R6.5.22 . Too many issues in R6.5.18 . I would suggest you read the release notes , especially in sip mode .

We are running 6_5_22 and have started having these same issues.  We rebuilt the database from scratch with a new ext numbers system and still have the issue.  A user presses the blue button and when prompted they enter their VM password, then nothing.  The entire NBX locks up.  Phones stop working, web interface stops working. I do use the consol to do a Cntl-R to do a soft reboot, this corrects the issue until someone tries to access their VM.  87 users

 

we have the same problems our system has R6_0_63 and we have a third party contract with HP but they dont know how to help us

Sorry the contract is by a reseller of HP

I see this is an old thread but I was hoping because it's an old thread that someone found a solution to this VM lock out problem or at least a cause. If anyone has found a solution or a cause for this problem, please post a reply.

#_Lock_Outs
#_3Com
#_VoiceMail
#V3000