Partner dropping incoming calls

[bryanfarrish]

I have a band new Avaya Parnter ACS R6 with Partner VMS R6, and 34D keysets, and on a Verizon CO in California. Very intermittently, when a call comes in and gets routed through the VM, exactly 5 seconds after a user answers it, it gets dropped. At that exact instance, the user who answered the inbound call hears a two-tone signal, similar to a french police siren (the outside caller hears nothing, however, just a dead line.) It's the same tone that you get if you leave a Partner line or intercom engaged and unattended for a minute or so. The tone is not coming from the CO, it's definately from the Partner, since you can generate same tone even if you are not connected to the CO (again, by leaving a line or intercom engaged and unattended).

The drop happens about every 10 or 20 incoming calls. It can happen on any line, any extension, and while any number of people are using the system. One interesting point... it always happens 5 seconds after a user answers an incoming call, NO MATTER how long the caller had been listening to a prompt before choosing an extension. And, amazingly enough, if a call is connected normally (not dropped), but the user puts the call on hold, then when the call is returned to it can still happen, again, exactly 5 seconds after returning to the call. And it's ONLY on incoming calls.

The local vendor has double checked the wiring and programming, and we've had the lines tested and re-tested by Verizon. Any help appreciated.

Bryan

 

[Dexman]

Most likely, the ACS module is causing the problem. Try replacing it with a brand new module.

It also can't hurt to check the line loop current to make sure Verizon is delivering enough current to prevent calls from dropping off. Too little current can cause calls to drop and/or low audio levels while too much current can cause processor failure and/or crosstalk.

 

[skip555]

if it where either the acs or the loop current wouldnt the problem also be there on outgoing calls ?

I still think its a transfer sequence problem

( I am assuning that you aent having outgoing calls droped )

 

[Dexman]

Point well taken Skip. Loop current would affect both incoming and outgoing calls. Bryan did say that the problem is only with oncoming calls. My bad .

I would try to isolate the voicemail system by bypassing it and making a series of incoming calls that are answered directly. (Can be done after hours). If the problem is not duplicated, I'd be suspicious of the voicemail. If you can duplicate the problem with the voicemail system bypassed, then I'd be suspicious of the ACS mod.

All of this assumes that the programing is correct.

 

[itpphoneguy]

Hi bryanfarrish,
One thing a Partner doesn't do often is drop calls. Since the problem is erratic, have a look in the diagnostics using the PC administration. Dial into the switch and download the diagnostics. Look for no loop current errors and a high number of warm boots and errors.
Alternatively, hang a butt set on a CO and wait to see if a call drops while on it. Listen for a "Click". You shouldn't lose the call if the butt set is off hook. (after hours). Sounds tedious.
-Chris

 

[bryanfarrish]

Well, the ACS is probably next in line to be checked. Verizon, however, has checked the lines several times, saying they were "clear and strong". They sound clear and strong too.

 

[skip555]

I would suggest you get users to start keeping a log

call dropped :

line that dropped

where the call was coming from

what extension had it drop

if you can get some data you may see a pattern


I rember having a similar problem a few years back finally found out the "dropped calls" where all coming form one guy on a cell phone.

I suggested maybe it was his cell phone and not my equipment he changed carriers

bam problem fixed.

you need data

 

[itpphoneguy]

Basically, yes, you need data. Verizon may have a strong signal, but there may be interuptions in loop current. You may have a problem at the source of the call handing off to Verizon also.
I suggested to check the logs in the switch to see if there was anything there to worry about. You could hook up the SMDR output of the ACS to a server that's on all the time. Just open a hyperterminal session to the com port & capture data. That may help you quite a bit. This will log all calls so you can check the data. It will tell you CO and station, also the caller ID if available.
-Chris

 

[hbiss]

The tone is not coming from the CO, it's definately from the Partner, since you can generate same tone even if you are not connected to the CO (again, by leaving a line or intercom engaged and unattended).

Just because the tone is the same as what Partner uses for off hook warning doesn't mean that that's where it is coming from. That tone is pretty universal. I'll assume that you are hearing this through the handset when the call is dropped. It would be very unlikely for the ACS to be doing this but stranger things have happened.

I would suggest that you stop beating your head against the wall with this. Quick and easy way to find out is to swap out the ACS processor with another temporarily. Your vendor should have no problem doing this and I don't know why he hasn't done it already. You have a warranty right? If the problem still occurs with another processor I can guarantee you it is a TELCO problem. If it does go away then you know what the problem is.
-Hal

 

[bryanfarrish]

Data... yes I've been logging every disconnect. Calls are coming from all different places, under all user combinations/extensions/times/etc. Only common thread: it's incoming only, and it's exactly 5 seconds after pickup, whether the user is picking up a new call, or picking up a call on hold.

And we already have the SMDR printer hooked up... one thought was to check the asterisk (*) next to the incoming phone number, to see if the drop was being initiated by our office, or by the CO. (I think the asterisk lets you know).

I'll see if the vendor has another ACS to try.

 

[skip555]

did you buy this from the vendor or is this something you bought elsewhere and are having him service ?

 

[bryanfarrish]

Brand new out of box from independent vendor

 

[bryanfarrish]

The vendor noted that since it only happens on inbound calls, then voltage drops from the CO are ruled out, since the drops would occur both in and outbound.

Next: We just set the Transer Return Ext. to the same port as the VM port (i.e., one VM port is 34, so we set the TRE for that port to ext. 34; and we set the TRE for VM port 35 to ext. 35). Both VM ports were originally set to TRE to ext. 10.

The vendor thinks it's just a setting that is mis-configured in the transfer sequence.

 

[itpphoneguy]

Hi bryanfarrish,
I have a TON of systems that have the transfer return extension at default, ext 10. I've not had any problems at all with any. Could be a flakey problem, but this part of the program is not at fault. You may have some funny faults with your current setup. If ext 35 is busy, you can't transfer a call to it. It can't answer!
-Chris

 

[skip555]

The vendor thinks it's just a setting that is mis-configured in the transfer sequence.

maybe I'm missing something here but isn't that the vendors job to find and fix this. at no charge since I would think its a warranty issue.

I dont think its a acs problem per se replacing the acs may fix it simply becouse whatever programming error is ther will probably not be duplicated .

BTW I agree it most likley is a transfer sequence problem
(like I said in my first post )

 

[ttech]

Did you deafult thr processor prior to your initial Programming? The rule of thumb is to do a #989 to every system before installing and programming.

It has also been reccomended on the board to default all partner mail pc card voice mails too before initial programming.

 

[hbiss]

Certainly something to try. Default the processor (#98925327). Reprogram manually, NOT from any backup. Don't get fancy, do just what's required to get the VM working, time & date, # of lines, then ringing, line appearances etc. as necessary. Now see if the problem isstill there. If it is change the processor. If not, finish any programming. If the problem returns then look at what you did very carefully.

-Hal

 

[itpphoneguy]

Yup, if it starts working, you can restore if you want and just look at the programming very carefully.
My sugestion would be to reprogram everything from scratch if you can get it working due to possible program corruption.
-Chris

 

[bryanfarrish]

Yup, it was corrupted. Defaulting fixed everying. Thanks much......

Bryan