"Line busy. Returned to previous activity"?? 2

[MichiganRon]

I am experiencing a problem with my PBX/Audix system. The problem occurs when all incoming lines on a voice terminal are tied up.

When a caller calls from an outside line, our PBX routes to an auto-attendant on an Intuity Audix box. This works fine normally. But, when all incoming lines are tied up on a voice terminal and a caller tries to reach that extension trough the auto-attendant, they are unable and receive the following message from Audry: "Line busy. Returned to previous activity."

Our system consists of:
Intuity Audix v. 5.1
Definity G3si v. 11

Has anyone ever experienced this problem? Any help would be GREATLY appreciated.

-Ron

 

[Subtech]

We had some strange things like that happen to our Audix. I called Avaya and the suggest that Audix be rebooted. I rebooted it and that seem to clear the problem.

Bob (Subtech)

 

[Phoneman2]

You might want to look at adding another 6 lines to your voice mail. If your going to have that much traffic going to your voice mail. You just upgraded the phone switch, upgrade the voice mail. Wisdom is Knowledge
that is Shared

Thanks All Phoneman2

 

[MichiganRon]

Thanks for the suggestions. Actually, we upgraded our Audix at the same time as the PBX (a couple weeks ago). And, it doesn't appear to be a matter of too much traffic either. We have twelve channels on a relatively small system. Before the upgrade we only had eight and never had this problem.

I've discovered that one of the channels between the PBX and Audix (on the Audix side) is out of service. I released it and ran loop back tests on it. I even tried re-punching down the wiring and swapping tip & ring. No luck, still out of service. I just got off the phone with Avaya. They are going to send a tech out with a new card.

When I found that the one channel was bad I removed that extension from the Audix hunt group on the PBX. If the problem was caused by that one bad channel, then removing it from the hunt group should solve the problem, right? It didn't. Oh well, when the tech arrives, he'll have to bring down Audix to replace the card. Perhaps that (reboot) will solve the problem if the new card doesn't.

Thanks again.
-Ron

 

[randyb19]

"Line busy. Returned to previous activity."; usually that means that audix cannot GET to the the extension it is trying to dial. Now whether that is due to full channels, incorrect UDP, etc. you would have to check that out.

 

[nknook]

Hello Ron,

Does the terminal you're referring to have a coverage-path? If not, Audix will get a busy tone, and report that with a line-busy message. Add more call-apearances to the terminal or a coverage-path.
If it has a coverage-path, maybe there's a setting in the auto-attd not allowing the transferred call to follow the destination's CP. Maybe it got defaulted again after the upgrade..

Cheers,
Nico

 

[netcon1]

On the Intuity, check the system features form and make sure the transfer parameters are set to "enhanced cover 0", not "nhance no cover 0"

Second, check the coverage path of the phones in question. You may find that the busy criteria is set to "no" instead of "yes" which will cause the Audix to respond like this.

Third, in a DCS or multi-switch environment, make sure the switch ID in the voice mail box is set to the correct switch. eg 1, 2. This will also cause this problem to happen.

Netcon 1

 

[MichiganRon]

Ahhh, the saga continues. Avaya was here to replace one of the channel cards (because my last channel was out of service) and found that the people who upgraded our systems had used one standard "analog phone" two pair cable to connect to the PBX to the Audix. A four pair cable is required and as a result, the channel that was requiring the extra pair wasn't working. We didn't need to replace the card after all.

They also went into the main coverage path that most extensions use and changed the "Busy" "Inside Calls" to "Y". This solved the original problem of outside callers not being transferred to voicemail when a line was busy.

Something is not right though. As you may have noticed, the "Inside Calls" setting was changed, not the "Outside Calls". Thus, it shouldn't effect calls coming in from the outside. If I change the "Busy" "Outside Calls" setting to "N", I should get a busy signal or some kind of error when I try to dial an extension that is busy from an outside line. It doesn't do it though. If follows the coverage path when it shouldn't. It's almost as if the system doesn't know that it is a call from the outside. Is there a setting somewhere in either my PBX or Audix that isn't set properly? Remember, when a call comes in though our main trunk group, the call is automatically routed to an Intuity Audix auto-attendant where the caller enters the appropriate (tranfer) extension.

Ugh!
-Ron

P.S. Thanks for all your great suggestions above. I tried all of them.

 

[nknook]

I think the "internal/external" issue excists because Audix is transferring the call (using an inside line, the voicechannel), causing the coverage-path to "think" it's an inside call.

There's is a field (I believe it's in the coverage-forwarding parameters form in Definity) where you can choose to treat transferred external calls as external calls (External Coverage Treatment for Transferred Incoming Calls?). If it is set to n (No), change it to yes, and see if that solves it.

Cheers,
Nico

 

[MichiganRon]

Thank you! Thank you! Thank you!

That did it! The "External Coverage Treatment for Transferred Incoming Trunk Calls" was set to "N". I changed it to "Y" and the problem has been solved!

What a GREAT message board. Even the Avaya tech couldn't figure that one out!

Thank you!
-Ron

 

[Phoneman2]

I think nknook should get a star for that one...don't you Darkshadeau?? Wisdom is Knowledge
that is Shared

Thanks All Phoneman2

 

[MichiganRon]

Oops. I was so happy that I finally got it fixed that I forgot the star. Thanks for reminding me!

-Ron

 

[nknook]

Thanks guys!



Nico

 

[europe]

And for your information NKNOOK is one of the better avaya techies arround....
So at the end of it all it was still a Avaya techie that helped solve the prob. Please let me know if the information that was provided is helpfull.
Edwin Plat
A.K.A. Europe