Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Avaya Needs To Be Rebooted 1

Status
Not open for further replies.

AvayaTechTip

IS-IT--Management
Jan 9, 2019
12
US
New with this PBX, so please bear with me. Still gathering facts but wanted to post as the situation is urgent.

PRI using Avaya IP Office. We have 5 controllers but only 1 is having an issue. We are alerted to the symptom of no calls in or out. When I log into System Status and click on trunks, the first set shows “Out Of Service”. I reboot the PBX and they return to “In Service”. Calls immeadiately start working and all is resolved. This happened twice now and I have been told that it hasn’t happened for 2+ years. How would I troubleshoot this? Carrier reports all lines are clean.

Thanks!
 
I would call in an experienced Avaya Business Partner. Troubleshooting PRI can be cumbersome. I would rule out the Hardware....


 
My money is on the clocking.

Refer to the IP Office Installation Manual for full details. This option sets whether the system should try to take its clock source for call synchronization and signalling from this line. Preference should always be given to using the clock source from a central office exchange if available by setting at least one exchange line to Network.

If multiple lines are set as Network, the order in which those lines are used is described in the IP Office Installation Manual. If additional lines are available, Fallback can be used to specify a clock source to use should the Network source not be available.

Lines from which the clock source should not be taken should be set as Unsuitable.

If no clock source is available, the system uses its own internal 8KHz clock source.

In scenarios where several systems are network via digital trunk lines, care must be taken to ensure that all the systems use the same clock source. The current source being used by a system is reported within the System Status Application.


Depending on the URI configuration the ICR can be completely ignored.

If your URI is configured to use internal data then the IP Office will look into the user's SIP tab and if you have *'s it will look into ICR.

A madman with a taste for speed.
 
Clocking maybe so check the above.

What other changes have been made recently?

If all 5 system's are with the same provider, play spot the difference in settings between a working and non-working system configuration.

Has the problem system been moved - PRI can be very sensitive to the cable between the system and the line providers socket (and whilst it may look like just a LAN cable it is not carrying Ethernet LAN signalling).

Have they been fiddling with the CLI they send? Some line providers automatically take a line out of service if they receive calls with a CLI that doesn't match any number registered to the line in their records.

And of course talk to the line provider. They almost always say it isn't them in the first instance. But you're paying them for a service you suspect you may not be receiving.

Stuck in a never ending cycle of file copying.
 
Thanks for your help, all!

HoldMusic, I believe you are on the right path. The PRI having issues has a clock setting that is different from the other PRIs. Per sizbut, I compared the clock setting to all other PRIs. My notes are below:

Controller having issue:
***PRI having issue*** PRI line 5 - Clock set to Unsuitable
PRI line 13 - Clock set to Network

Other controllers -
620 - PRI line 13 - Clock set to Network
630 - PRI line 1 - Clock set to Network
640 - PRI line 5 - Clock set to Network

I also see 29 occurrences of "8Hz clock source changed. Previous source was Internal." on the controller having the issue.

Should I change Unsuitable to Network? Any way that I can confirm this is the issue before making the change?

Thanks
 
Normaly you would have one PRI set to Network & all others set to fallback

This can cause problems if one of the Pri Circuits is not correctly synced by the network provider, getting them to resolve this requires good deal of patience & self control


Do things on the cheap & it will cost you dear
 
After pointing out the several clocking errors, my vendor replied with:

The 610 Avaya PBX has two PRI cards in it. There is only one PRI at the site and so only one of the ports is being used. Once upon a time, this was line 5, however it was switched to line 13 a few years back. I have verified the clocking is setup correct on the PBX. We are clocking off of the service provider. The IPO will spit out a "Clock Source was Changed" error every time the PRI makes a successful connection. Since the PRI has been going up and down, this is the reason for these clocking errors.

To me, he is pointing back at the provider. Does this seem feasible? We can rule out Avaya equipment, right? If we can rule out that, I can rule out having to being charged for an on site visit at 160/hr.

Thanks
 
Most PRI circuits have a Adtran or some type of card they interface to the Avaya with. Next time it happens, I would reset the Adtran or the card that is provided by the carrier. Sometimes resetting the Avaya results in actually resetting the carrier circuit, so you end up chasing the wrong source of the problem.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top