|
Joined: Aug 2006
Posts: 19
Member
|
Member
Joined: Aug 2006
Posts: 19 |
Yes - 16 channels of PRI in Slot 13 - not even in the same cabinet. My replacement power supply did no good, as I witnessed the "sleeping" twice - very strange - as it was happening I placed test calls to the vm group - ports were either not answering or delay answering and the port status lights were not in synch with the call - meaning I was hearing the voicemail, but none of the port lights were flashing. I also had the ports in monitor mode and as I was placing calls and getting the above response, I could see the raw data stop from the monitor window - then start up again! The status light was also dimmed considerably as it flashed - which alerted me to the inevitable crash. The error log saw the event again as a "watchdog timeout"! To address the bad hard drive thought - I checked the manufacture date on the 2 R2.5's and saw they were within 2 months of each other... There is now a freshly programmed R4 in there now and I'm hoping for the best.
|
|
|
|
Joined: Jul 2001
Posts: 3,347 Likes: 10
Moderator-Avaya-Lucent, Antique Tele
|
Moderator-Avaya-Lucent, Antique Tele
Joined: Jul 2001
Posts: 3,347 Likes: 10 |
I think Paul (Dexman) is on the right track by asking you if you have a PRI. Try making a call into the Auto Attendant, while blocking your caller ID (dial *67 before the phone number). See if that causes the voice mail to reboot.
|
|
|
|
Joined: Aug 2006
Posts: 19
Member
|
Member
Joined: Aug 2006
Posts: 19 |
Tom - Your advise was both enlightening and frightening! Blocking the call ID completely locked up the port - I didn't get any voice prompt and after a while once I had locked up enough ports, the voicemail rebooted. So - what's causing it? Is it the emulated 5E I'm getting the PRI from? I've called my office (which has a Magix R3 w/R2.5 v-mail and this doesn't happen - is there some signaling that's hosing the voicemail? I know sending Caller ID name will ruin these switches - this seems just as bad - what can I do?
|
|
|
|
Joined: Aug 2006
Posts: 19
Member
|
Member
Joined: Aug 2006
Posts: 19 |
UPDATE - Seems there is a major problem with the Telepacific "Smart Voice" PRI product regarding issues with the onsite Adtran router (this is a fractional PRI w/16 voice channels + Data) What is happening that Paul and Tom figured out (that's why you guys have 5 star ratings)is when certain LEC's or cell phone providers (so far Verizon & AT&T)either automatically or manually block the inbound Caller ID, the Adran is inserting a Calling Party Name in the "Calling Party Nbr" field and when ANY call covers to voicemail, the port goes off hook and won't initally answer for quite a long time, which starts to generate errors in the voicemail "Watchdog Timeouts" and when enough ports go into this state, the voicemail reboots to clear the ports. I have the maintenance monitor trace to prove this is happening. Typically, when there is blocked or no Caller ID sent, the first line item in the trace is the trunk ID followed by "incoming call". Next comes the call setup info. The ID name is not acknowledged. Now, when the ID is sent, the line after the initial "incoming call" alert again shows the line ID with "Calling Party Nbr" followed by the Caller ID. Perfect right? In THIS case (again only with certain phone providers)when the Caller ID is blocked, the Calling Party Nbr reads "anonymous", which I believe when answered directly via the voicemail, causes it to freeze as it expects to be seeing digits in the Caller ID field, but instead gets the alpha characters instead. If you have such a product PLEASE REFERENCE THIS. At the time of this post, the brightest minds at Telepacific have yet to figure this out since early am?!? If anyone can help with this, I know I'll hear from you. Either that, or we'll need to go to a different product for their voice services...
|
|
|
Forums84
Topics94,518
Posts639,974
Members49,849
|
Most Online5,661 May 23rd, 2018
|
|
|
|